One of the key security requirements for RTP is confidentiality, ensuring that only the intended receivers can decode your RTP packets. RTP content is kept confidential by encryption, either at the application levelencrypting either the entire RTP packet or just the payload sectionor at the IP layer.
Application-level encryption has advantages for RTP, but also some disadvantages. The key advantage is that it allows header compression. If only the RTP payload is encrypted, then header compression will work normally, which is essential for some applications (for example, wireless telephony using RTP). If the RTP header is encrypted too, the operation of header compression is disrupted to some extent, but it is still possible to compress the UDP/IP headers.
The other advantage of application-level encryption is that it is simple to implement and deploy, requiring no changes to host operating systems or routers. Unfortunately, this is also a potential
Another potential disadvantage of application-level encryption is that it
As an alternative, encryption can be performed at the IP layerfor example, using the IP security (IPsec) protocols. This approach has the advantage of being transparent to RTP, and of providing a singlepresumably well-
Confidentiality Features in the RTP Specification
The RTP specification provides support for encryption of both RTP data packets (including headers) and RTCP packets.
All octets of RTP data packetsincluding the RTP header and the payload dataare encrypted.
Figure 13.1. Standard RTP Encryption of a Data Packet
When RTCP packets are encrypted, a 32-bit random number is inserted before the first packet, as shown in Figure 13.2. This is done to prevent known plain-text attacks. RTCP packets have a standard format with many fixed octets; knowledge that these fixed octets exist makes a wily cracker's work easier because he
Figure 13.2. Standard RTP Encryption of a Control Packet
The insertion of the prefix provides initialization for the cipher, which effectively
In some cases it is desirable to encrypt only part of the RTCP packets while sending other parts in the clear. The typical example would be to encrypt the SDES items, but leave
Figure 13.3. Using Standard RTP Encryption to Partially Encrypt a Control Packet
The default encryption algorithm is the Data Encryption Standard (DES) in cipher block chaining mode. 56 When RTP was designed, DES provided an appropriate level of security. However, advances in processing capacity have rendered it weak, so it is recommended that implementations choose a stronger encryption algorithm where possible. Suitable strong encryption algorithms include Triple DES 57 and the Advanced Encryption Standard (AES). 58 To maximize interoperability, all implementations that support encryption should support DES, despite its weakness.
The presence of encryption and the use of the correct key are confirmed by the receiver through header or payload validity checks, such as those described in the Packet Validation sections of Chapter 4, RTP Data Transfer Protocol, and Chapter 5, RTP Control Protocol.
The RTP specification does not define any mechanism for the exchange of encryption keys. Nevertheless, key exchange is an essential part of any system, and it must be performed during session initiation. Call setup protocols such as SIP 28 and RTSP 14 are expected to provide key exchange, in a form suitable for RTP.
Confidentiality Using the Secure RTP Profile
An alternative to the mechanisms in the RTP specification is provided by the Secure RTP (SRTP) profile.
This new profile, designed with the needs of wireless telephony in mind, provides confidentiality and authentication suitable for use with links that may have relatively high loss rate, and that require header compression for efficient operation. SRTP is a work in progress, with the details of the protocol still evolving at the time of this writing. After the specification is complete, readers should
SRTP provides confidentiality of RTP data packets by encrypting just the payload section of the packet, as shown in Figure 13.4.
Figure 13.4. Secure RTP Encryption of a Data Packet
The RTP header, as well as any header extension, is sent without encryption. If the RTP payload format uses a payload header within the payload section of the RTP packet, that payload header will be encrypted along with the payload data. The authentication header is described in the section titled Authentication Using the Secure RTP Profile later in this chapter. The optional master key identifier may be used by the key management protocol, for the purpose of rekeying and identifying a particular master key within the cryptographic context.
When using SRTP, the sender and receiver are required to maintain a cryptographic context, comprising the encryption algorithm, the master and salting keys, a 32-bit rollover counter (which records how many times the 16-bit RTP sequence number has wrapped around), and the session key derivation rate. The receiver is also expected to maintain a record of the sequence number of the last packet received, as well as a replay list (when using authentication). The transport address of the RTP session, together with the SSRC, is used to determine which cryptographic context is used to encrypt or decrypt each packet.
The default encryption algorithm is the Advanced Encryption Standard in either counter mode or f8 mode, 58 , 59 with counter mode being mandatory to implement. Other algorithms may be defined in the future.
The encryption process consists of two steps:
In both steps, the packet index is the 32-bit extended RTP sequence number. The details of how the key stream is generated depend on the encryption algorithm and mode of operation.
If AES in counter mode is used, the key stream is generated in this way: A 128-bit integer is calculated as
Figure 13.5. Key-Stream Generation for SRTP: AES in Counter Mode
When implementing AES in counter mode, you
ensure that each packet is encrypted with a unique key stream (the presence of the packet index and SSRC in the key stream derivation function ensures this). If you
If AES in f8 mode is used, the key stream is generated in this way: The XOR of the session key and a salting key is generated, and it is used to encrypt the initialization vector. If the salting key is less than 128 bits in length, it is padded with alternating zeros and ones (0x555...) to 128 bits. The result is known as the internal initialization vector . The first block of the key stream is generated as the XOR of the internal initialization vector and a 128-bit variable ( j = 0), and the result is encrypted with the session key. The variable j is incremented, and the second block of the key stream is generated as the XOR of the internal initialization vector, the variable j , and the previous block of the key stream. The process repeats, with j incrementing each time, until the key stream is at least as long as the payload section of the packet to be encrypted. Figure 13.6 shows this key-stream generation process.
Figure 13.6. Key-Stream Generation for SRTP: AES in f8 Mode
The default encryption algorithm and mode is AES in counter mode; use of AES f8 mode can be negotiated during session initiation.
SRTP also provides confidentiality of RTP control packets. The entire RTCP packet is encrypted, excluding the initial common header (the first 64 bits of the packet) and several additional fields that are added to the end of each RTCP packet, as shown in Figure 13.7. The additional fields are an SRTCP (Secure RTCP) index, a bit to
Figure 13.7. Secure RTP Encryption of a Control Packet
Encryption of RTCP packets proceeds in much the same way as encryption of RTP data packets does, but using the SRTCP index in place of the extended RTP sequence number.
The encryption prefix applied during standard RTCP encryption is not used with SRTP (the differences in encryption algorithm mean that the prefix offers no benefit). It is legal to split RTCP packets into encrypted and unencrypted packets, as can be done with standard RTCP encryption, indicated by the E bit in the SRTCP packet.
As with the RTP specification, the SRTP profile defines no mechanism for exchange of encryption keys. Keys must be exchanged via non-RTP meansfor example, within SIP or RTSP. The master key identifier may be used to synchronize changes of master keys.
Confidentiality Using IP Security
In addition to the application-level security provided by standard RTP and Secure RTP, it is possible to use IP-level security 17 , 110 with RTP. IPsec is implemented as part of the operating system network stack or in a gateway, not by applications. It provides security for all communications from a host, and it is not RTP-specific.
IP security (IPsec) has two modes of operation: transport mode and tunnel mode.
Figure 13.8. Transport Mode versus Tunnel Mode IPsec (Shaded Data Is Protected)
Both tunnel mode and transport mode support confidentiality and authentication of packets. Confidentiality is provided by a protocol known as the Encapsulating Security Payload (ESP). 21 ESP comprises an additional header and trailer added to each packet. The header includes a security parameter index and sequence number; the trailer contains padding and an indication of the type of the encapsulated data (TCP or UDP if transport mode is used, IP-in-IP if tunnel mode is used). Encapsulated between the header and trailer is the protected data, including the remaining headers. Figure 13.9 shows the encapsulation process, header, and trailer.
Figure 13.9. An Encapsulating Security Payload Packet
The security parameter index (SPI) and sequence number are 32-bit fields. The SPI is used to select the cryptographic context, and hence the decryption key to be used. The sequence number
Following the payload data is padding, if required, and a "
ESP encrypts the protected data section of the packet, using a symmetric algorithm (DES is mandatory to implement; other algorithms may be negotiated). If ESP is used with RTP, the entire RTP header and payload will be encrypted, along with the UDP headersand IP headers if tunnel mode is used.
It is not possible to use header compression with IP security in transport mode. If tunnel mode is used, the inner IP/UDP/RTP headers may be compressed before encryption and encapsulation. Doing so largely
IP security may also cause difficulty with some firewalls and Network Address Translation (NAT) devices. In particular, IP security hides the TCP or UDP headers, replacing them with an ESP header. Firewalls are typically configured to block all unrecognized traffic, in many cases including IPsec (the firewall has to be configured to allow ESP [IP protocol 50], in addition to TCP and UDP). Related problems occur with NAT because translation of TCP or UDP port
The IP security protocol suite includes an extensive signaling protocol, the Internet Key Exchange (IKE), used to set up the necessary parameters and encryption keys. The details of IKE are beyond the scope of this book.
Several RTP payload formats provide coupling between packetsfor example, when interleaving or forward error correction is being used. Coupling between packets may affect the operation of encryption, restricting the times when it is possible to change the encryption key. Figure 13.10 shows an example of interleaving that illustrates this problem.
Figure 13.10. Interactions between Encryption and Interleaving
The confidentiality mechanisms available for RTP can use a range of encryption algorithms, but they define a "must implement" algorithm to ensure interoperability. In many cases the mandatory algorithm is the Data Encryption Standard (DES). Advances in computational power have made DES seem relatively weakrecent systems have demonstrated brute-force cracking of DES in less than 24 hoursso it is appropriate to negotiate a stronger algorithm if possible. Triple DES 57 and the recently announced Advanced Encryption Standard (AES) 58 are suitable possibilities.
The use of end-to-end encryption to ensure confidentiality in RTP is effective at preventing unauthorized access to content, whether that content is pay-per-view TV or private telephone conversations. This protection is
Video Over IP, Second Edition: IPTV, Internet Video, H.264, P2P, Web TV, and Streaming: A Complete Guide to Understanding the Technology (Focal Press Media Technology Professional Series)
The H.264 Advanced Video Compression Standard
Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol (Networking Council)
SIP: Understanding the Session Initiation Protocol (Artech House Telecommunications)