S 5.135 Secure media transport using SRTP

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Head of IT, Administrator

The real-time transport protocol (RTP) is used for transmitting the media data for IP telephony and the real-time streaming protocol (RTSP) is used to control the transmission. Neither of the protocols offers any internal protection mechanisms against eavesdropping or against manipulations to IP telephone calls. Extensions of RTP/RTCP include SRTP/SRTCP providing protection mechanisms for transmission. When using VoIP, the use of SRTP/SRTCP should be considered to protect the user data. The decision made must be documented.

Overview

SRTP can be used in VoIP communications to maintain the confidentiality and authenticity of the media transmissions as well as to protect them from replay attacks (the replaying of messages) using RTP. It permits secure unicast and broadcast transmission. The RTP/RTCP packets are embedded in SRTP/SRTCP packets for transmission.

Key management

The SRTP protocol defines one master key as well as one session key for encryption and authentication for each session. SRTP does not contain any mechanisms for generating and managing the master keys, which are at least 128 bits long. This must be implemented using other standards, for example multimedia internet keying (MIKEY).

If SRTP is used, the change interval for the master key and the session keys must be specified.

Encryption

When using SRTP in the context of VoIP, the symmetric encryption method AES-CTR (Advanced Encryption Standard - Counter Mode) should be enabled as a rule. This method is suitable for end-to-end encryption as well as for encryption by segment (hop-by-hop).

Authenticity and integrity

The authenticity and integrity of RTP messages can be ensured in SRTP using the HMAC-SHA1 function in combination with a corresponding session key. The recommended length of the checksum transmitted is 80 bits in this case. Accordingly, the 160 bit long checksum from HMAC-SHA1 must be reduced to 80 bits. This change reduces the size of the SRTP packets transmitted, but also weakens the protection of the integrity of the messages. For this reason, this change should only be made in exceptional cases. Functions based on other recognised hash algorithms can also be used as an alternative. When making the selection, it must be taken into consideration that cryptographic vulnerabilities have been discovered in several widely used hash algorithms (see also S 2.164 Selection of a suitable cryptographic procedure). The reasons for selecting the hash function must be provided and documented.

The same security mechanism can also be used with SRTCP.

SRTP allows weaker authentication (e.g. 32 bits) or even no authentication at all of messages for those applications where it is improbable that an attacker will be able to manipulate an encrypted message in such a way that it can actually be read when decrypted later. If possible, this weaker authentication should not be used for RTP packets. If higher security requirements must be met by RTCP, the protection method using HMAC-SHA1 checksums described above should be enabled.

Protection against replay attacks (the replaying of messages)

SRTP offers protection against replay attacks, within the framework of which an attacker stores intercepted RTP or RTCP packets and resends them later in order to perform denial-of-service attacks, amongst other things. To be able to prevent the messages from being replayed, integrity protection and message authentication must be available. The recipient of the SRTP packets in this case maintains a replay list containing the codes of the authentic packets already received.

The maximum number of codes that can be stored in the list must be specified beforehand. When receiving a new packet, the list is checked for matches, and the repeated packets are rejected. On IP telephones that do not have much memory space, the length of the replay list is a security parameter that should be taken into consideration when the security requirements are higher. The largest possible size should be selected for the replay list, and the decision must be documented.

Key management with MIKEY

Multimedia Internet KEYing (MIKEY) describes key management for real-time multimedia communication and allows the parties involved to exchange keys as well as additional security parameters. MIKEY can be used to exchange the master key and additional security parameters in VoIP to enable secure SRTP transmission between the terminal devices.

MIKEY is independent of the underlying signalling protocol, for example H.323 or SIP. In addition, MIKEY supports the parallel exchange of keys and security parameters for different communication sessions and communication protocols. It is therefore possible to secure RTP and RTCP connections separately. When the communication session bundling concept is applied, MIKEY is able to use one shared master key for several parallel sessions. This means that VoIP conferences can be secured more efficiently, for example.

If the VoIP usage is to be secured with the help of cryptographic mechanisms, the key exchange methods supported by the VoIP systems must be determined. One suitable method must be selected from these methods and the method selected must be documented.

Review questions:

© Federal Office for Information Security. All rights reserved.