The Secure Real Time Transport Protocol (SRTP) aka Secure RTP, is used in a wide variety of VoIP, video and multimedia applications. Many umbrella specifications and SIP profiles, such as Assured Services SIP (AS-SIP), specified by the DoD in AS-SIP 2013 , and WebRTC ,mandate it’s use. SRTP is very suitable for VoIP applications, especially those that involve low-bitrate voice codecs (i.e. G.729, iLBC, MELP, etc.) since secure RTP can be used with header compression and has no significant impact on Quality of Service. SRTP can also be used with video coding specifications such as ITU Recommendation H.264 and MPEG-4 to stream video securely in multimedia applications.
VOCAL’s SRTP library is coded in optimized C and assembly for leading DSP architectures from TI, ADI, Intel, ARM and other vendors. Our SRTP library is available standalone, or as part of one of our many VoIP communication packages. It can also be included as part of the SDK/ BSP package for our VoIP hardware or reference designs. VOCAL’s SRTP SDK library is highly optimized, contains a wider variety of crypto support than others, and is actively supported by VOCAL engineers – the people who developed it. New features and crypto algorithms continue to be added. If you cannot find answers for your SRTP crypto library needs, contact us to discuss your requirements with our engineering staff – we have your solution.
SRTP Protocol Features
- Fully compliant with RFC 3711 “The Secure Real-time Transport Protocol (SRTP)”
- Optional support for RFC 6188 “The Use of AES-192 and AES-256 in Secure RTP”
- Optional support for RFC 8269 “The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)”
- Optional support for RFC 7714 “AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)”
- Various encryption libraries available
- SRTP/SRTCP payloads
- Ensure integrity of RTP/RTCP payloads
- Protect against replayed packet attack
- Low bandwidth implementation
- Low computational cost and small footprint
- Independent of network and physical layers
- Secure RTCP packets (SRTCP)
Secure Real Time Transport Protocol
RFC 3711 “The Secure Real-time Transport Protocol (SRTP)” defines a framework which provides confidentiality, message authentication, and replay protection for both unicast and multicast RTP and RTCP streams. Secure RTP can achieve high throughput and low packet expansion even in environments which are a mixture of wired and wireless networks.
SRTP is the security layer which resides between the RTP/RTCP application layer and the transport layer, generating Secure RTP packets from the RTP/RTCP stream and forwarding these to the receiver. Similarly, it also transforms incoming Secure RTP packets to RTP/RTCP packets and passes these up the stack. The cryptographic state information associated with each Secure RTP stream is termed the cryptographic context. It must be maintained by both the sender and receiver of these streams. If there are several Secure RTP streams present within a given RTP session, separate cryptographic contexts must be maintained for each. A cryptographic context includes any session key (a key directly in encryption/message authentication) and the master key (a securely exchanged random bit string used to derive session keys), as well as other working session parameters.
While Secure RTP does not define a precise mechanism to implement key exchange (which may be done using SDES), it does provide for several features which make key management easier and heighten overall key security. The single master key is used to provide keying material for a key derivation function. This can generate the initial session keys, as well as provide new session keys periodically to ensure that there will be a limited amount of ciphertext produced by any given encryption key. Salting keys are used to provide protection against various assaults such as pre-computation and time-memory attacks.
SDP and RTP Profile for SRTP
RFC 3711 adds a new profile to RTP – “RTP/SAVP”, as well as registering the SDP attribute “crypto”. When used in a SDP offer/answer negotiation this indicates that the RTP stream will be secured using the SRTP standard. RFC 4568 “Session Description Protocol (SDP) Security Descriptions for Media Streams” describes how to negotiate or advertise an SRTP stream using SDP, and defines these names for the default SRTP suites in RFC3711:
AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_32
F8_128_HMAC_SHA1_80
The third option F8, is an Output Feedback Mode (OFB), block cipher algorithm, used mostly in UMTS 3G networks – the AES CM modes being the dominant SRTP suites for use on the Internet and other communications networks. VOCAL’s SRTP libraries come standard with both AEC CM 128 HMAC modes, and can optionally support of a number of additional crypto suites.
Support for AES-192 and AES-256
While Secure RTP using AES 128 is considered secure by today’s standards, RFC 6188 was introduced to allow the use of AES-192 and AES-256 in Secure RTP, for those with a “highly conservative security strategy”. For instance, the NSA’s Suite B Cryptography profile requires AES-256 for TOP SECRET information. AES-256 is also considered possibly secure against a variation of possible future quantum computer based attacks.
RFC 6188 introduces 4 new SDES “crypto suites”:
AES_192_CM_HMAC_SHA1_80
AES_192_CM_HMAC_SHA1_32
AES_256_CM_HMAC_SHA1_80
AES_256_CM_HMAC_SHA1_32
Each of these suites operates in counter mode, and uses HMAC authentication just like base SRTP. The only difference being the use of 192bit or 256bit AES keys. VOCAL’s libraries can offer support for these modes for customers who need that extra level of security. Contact us to find out more.
Support for AES-GCM Authenticated Encryption
RFC 7714 “AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)” uses Authenticated Encryption (See RFC 5116 “An Interface and Algorithms for Authenticated Encryption”) for SRTP. This form of encryption has the authentication and encryption combined, and so a separate authentication tag, such the HMAC tag used in the default cipher suites is not used. This form of SRTP encryption defined in RFC 7714 is called out in a number of specifications, notably 3GPP TS 33.328 “IP Multimedia Subsystem (IMS) media plane security”, for use in VoLTE communications within the 4G and 5G networks. In turn TS 33.328 is referenced by a number of GSMA specifications, including N2020.1 “VoLTE Service Description and Implementation Guidelines (Version 1.0)” and GSMA IR.92 “IMS Profile for Voice and SMS”.
RFC 7714 defines 2 new cipher suites (SDES “crypto suites”) for use with SRTP:
AEAD_AES_128_GCM AES-128
AEAD_AES_256_GCM AES-256
Both of these AEAD suites (Authenticated Encryption with Associated Data) operates in the Galois/Counter Mode of operation (GCM) , unlike the default ciphers for SRTP. The only difference between the 2 modes being the use of 128bit or 256bit AES keys. GCM mode is defined in NIST Special Publication 800-38D November, 2007 Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. AHEAD algorithms allow a portion of the unencrypted data to be authenticated along with the unencrypted portion. In this case, the unencrypted but authenticated data is the RTP header and the RTCP index portion of an RTCP packet. VOCAL can offer support for these modes of operation. Contact us to find out more.
Support for ARIA Block Cipher Algorithm
RFC 8269 “The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)” adds ARIA crypto suites to SRTP. This algorithm was developed by Korean cryptographers in 2003, and became a Korean standard block cipher in 2004. The algorithm is described in RFC 5794 “A Description of the ARIA Encryption Algorithm”. The specification defines new SDES “crypto suites” for 6 modes of operation – 4 variations of counter-mode with HMAC, and 2 of AEAD_GCM:
SRTP_ARIA_128_CTR_HMAC_SHA1_80
SRTP_ARIA_128_CTR_HMAC_SHA1_32
SRTP_ARIA_256_CTR_HMAC_SHA1_80
SRTP_ARIA_256_CTR_HMAC_SHA1_32
SRTP_AEAD_ARIA_128_GCM
SRTP_AEAD_ARIA_256_GCM
VOCAL implements the ARIA cipher as well as the SRTP handling, as standalone algorithms or as part of larger libraries, such as in our SIP based VoIP offerings. Contact us to find out more.
SRTP Terminology
- cryptographic context – the cryptographic state information associated with each SRTP stream, which also includes the master key and session keys. This must be maintained by both the sender and receiver of each stream.
- session key – a key directly used in encryption or message authentication
- master key – a securely exchanged random bit string used to derive session keys
- Confidentiality – a security service that ensures data is available to only those intended (provided by Encryption)
- Authentication – use of cryptographic algorithms to check plaintext integrity and authenticity
- MAC – Message Authentication Code, the data used to convey Authentication information
Related Specifications
- SRTP – RFC 3711 The Secure Real-time Transport Protocol (SRTP)
- RFC 6188 The Use of AES-192 and AES-256 in Secure RTP
- RFC 8269 The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)
- RFC 5794 A Description of the ARIA Encryption Algorithm
- RFC 7714 – AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)
- RFC 5116 An Interface and Algorithms for Authenticated Encryption
- RTP – RFC 3550 RTP: A Transport Protocol for Real-Time Applications
- RTCP- RFC 3550 RTP: A Transport Protocol for Real-Time Applications
- H.264 – Advanced video coding for generic audiovisual services
- MPEG-4 – rfc3016 RTP Payload Format for MPEG-4 Audio/Visual Streams
VOCAL’s solution is available for the above platforms. Please contact us for specific supported platforms.