Besides signaling when projecting and deploying Unified Communications system, we might also be interested in encrypting the media transferred between devices.
There are three popular RTP encryption modes:
- SRTP MIKEY / SDES (requires TLS encryption of signaling)
- SRTP DTLS
- ZRTP
SRTP
The Secure Real-Time Transport Protocol (or SRTP) defines a profile of RTP (Real-Time Transport Protocol) intended to provide encryption, message authentication and integrity, and replay protection to the RTP data in both unicast and multicast applications. It was first published by the IETF in March 2004 as RFC 3711.
Since its inception, it has been adopted by many vendors, with the most supported encryption standard being based on AES 128 encryption.
Since keys are exchanged in plain text inside SIP messages, encryption of signaling is mandatory. A security drawback of this approach is that the SIP Proxy in the middle knows all the information necessary to decode the audio exchanged. This configuration is advantageous in corporate environments where we want to ensure privacy from entities outside the organization, but, at the same time, enable features such as call recording.
SRTP DTLS
SRTP using Datagram Transport Layer Security (DTLS) offers point-to-point (device-to-device) security between endpoints in a communication. It is a channel security protocol based on TLS. The encryption keys are exchanged over the same port, which is then used for RTP by using a DTLS protocol.
When using DTLS-SRTP:
- Application data is protected using SRTP.
- The DTLS handshake is used to establish keying material, algorithms, and parameters for SRTP.
- A DTLS extension is used to negotiate SRTP algorithms.
- Other DTLS record-layer content types are protected using the ordinary DTLS record format.
In other words, it is essential to ensure security on the point-to-point (device-to-device) level and to not rely on the security of signaling (for example, SIP).
SRTP-DTLS is currently supported by WebRTC-powered browsers, and it is the mandatory RTP encryption mode of the WebRTC project / specification. It replaces SRTP SDES, which had been initially considered and added in the Chrome WebRTC implementation. It has been selected over SRTP SDES because it ensures better confidentiality in point-to-point communications.
ZRTP
Also ZRTP offers point to point encryption protocol, but it is not widely supported.
In order to create a point to point encryption a shared secret and other security parameters are exchanged, relying on Diffie-Hellman Key Exchange Protocol. Mutual authentication can use a Short Authentication String (SAS), so it doesn’t require support from a PKI (Public Key Infrastructure). The ZRTP exchange takes place over the same port numbers used by the multimedia session for the RTP traffic (as opposed to the signaling path).
The authentication, and later encrypted media exchange, is performed over a single port as indicated in the SDP. ZRTP prevents eavesdropping, but it introduces problems if call recording must be performed.
Nowadays, ZRTP is implemented mainly in SIP softphones. Most clients usually fall back to the standard RTP if ZRTP is not supported by the remote endpoint.
Conclusions
Media encryption is an important topic, and each UC system should implement it for calls over public data networks.
We should remember that when calls are routed over traditional PSTN networks, they are subject to tapping by law enforcement and operators. If confidentiality is important in all scenarios, we must inform users and require them to communicate over pure VoIP connections.
In conclusion, using WebRTC and VoIP telephony offers a more convenient and secure way to foster communication between team members and customers.
