LAPPEENRANNAN UNIVERSITY OF TECHNOLOGY
Department of Information Technology
SECURED REAL TIME TRANSPORT PROTOCOL (SRTP)
Lappeenranta, Dec. 1, 2007
Santosh Kumar Kalwar 0331927
Mubeen Khan 0331969
ABSTRACT
Lappeenranta University of Technology
Department of Information Technology
Santosh Kumar Kalwar
Mubeen Khan
Secured Real Time Transport Protocol
2007
16 pages, 3 figures, 1 table
Examiner: Pekka Jappinen
Keywords: SRTP, seminar, report
This seminar was carried out, in context of Secured Real time transport protocol, the default encryption algorithm used in SRTP is Advanced Encryption Standard. There were many questions that arose during this seminar, now a day SRTP has been standard protocol to provide a protection of media streams. At present, SRTP is not considered a standard in VOIP implementations. May be there is lack in expertise to deploy SRTP in VoIP enterprise environments by corporations. However, we thought that, SRTP can be used in providing the security for real time multimedia information in future.
ABBREVIATIONS
AES Advanced Encryption Standard
RTP Real time Transport Protocol
RTCP Real time Transmission Control Protocol
IP Internet Protocol
UDP User Datagram Protocol
AES-CM Advanced Encryption Standard- Counter Mode
MKI Master Key Identifier
ROC Roll over Counter
VoIP Voice over IP
SRTP Secured Real time transport protocol
SRTCP Secured Real time transmission control protocol
SIP Session Initiation Protocol
NAT Network Address Translation
IETF Internet Engineering Task Force
MAC Medium Access Control
PSTN Public Switch Telephone Network
SDP Session Description Protocol
MIKEY Multimedia Internet Keying
TABLE OF CONTENTS
1.INTRODUCTION 4
2. Theoretical Background 7
2.1 Format of SRTP 7
2.3. SRTP Key Management 11
2.4 Key Derivation 12
2.6 Strength 14
2.7 Weakness 15
3. Conclusion 15
REFERENCES
INTRODUCTION
Which security protocol will you use for real time multimedia communication? Any multimedia application—such as video, voice, or gaming—uses a distinct set of protocols to set up sessions between end points (for example, SIP, H.323) and a distinct protocol to transmit the media streams. The standard protocol used to exchange media streams is RTP (Real Time Protocol), which is defined in RFC 3550. [2] RTP streams can be intercepted and manipulated in order to perform various attacks. Although IPSec can be used to protect RTP, its limitations require a more scalable and versatile solution that alleviates the NAT traversal issue, dynamic allocation of sessions, and the need for a PKI. This has led to the development of SRTP (Secure Real Time Protocol). The use of SRTP requires a mechanism to exchange cryptographic keys before sending any media. Therefore, key management protocols such as MIKEY and SDescriptions have been proposed to provide the necessary keying material and management mechanisms to maintain the security of multimedia sessions. Currently, there is not a single key-exchange mechanism considered to be the industry standard because each has strengths and weaknesses.SRTP is a secure real time transport protocol published in 2004; it protects data in both unicast and multicast. (RTP, IETF RFC 3550) to provide confidentiality, integrity and authentication to media streams and is defined in the IETF RFC 3711. [1] SRTP is one of the ways for protecting real time devices such as voice and video in multimedia applications. It protects the RTP and RTCP packets. It was designed for providing the protection in media streams. It also supports the wired and wireless network with limited bandwidths.SRTP provides a framework for encryption and message authentication of RTP and RTCP streams SRTP can achieve high throughput and low packet expansion. SRTP proves to be a suitable protection for heterogeneous environments (mix of wired and wireless networks). To get such features, default transforms are described, based on an additive stream cipher for encryption, a keyed-hash based function for message authentication, and an "implicit" index for sequencing/synchronization based on the RTP sequence number for SRTP and an index number for Secure RTCP (SRTCP).
-
Properties of SRTP
The important properties of SRTP are, it can have cryptographic transforms. It has maintained low bandwidth and less computation cost. It can be easily deployed in small size application; it has very less implementation codes. It is independent of transport, network and physical layer and is prone to reordering and packet loss. [1] The property makes it easier for implementing this protocol in mobile devices with limited memory. The application that implements SRTP first of all has to covert RTP packets to SRTP packet before sending it across network also to decrypt the SRTP message it has to be converted to RTP message. The process of doing this is shown below in the diagram:
Fig 1: SRTP encoding and decoding.
In the diagram above, the application captures the input from ad device such as microphone or camera or some media. [5] It encodes the signal using default encoding standards such as H.729 or H.264 and creates the RTP payload. Now the RTP payload is encrypted using AES (Advanced Encryption Standard) in counter mode using 128-bit key length. Counter mode, and null mode (it can be used in case where confidentiality is not desired) is mandatory for implementations. The null cipher of SRTP is used when authentication is desired without encryption. AES Counter Mode is the default cipher is SRTP because it requires zero packet expansion, it process non-sequential data blocks efficiently, allows processing of data blocks in parallel, and it allows pre-computation of the key stream. AES helps for processing the packet even if the packets are received out of order. Some other properties of SRTP are that, the ability to incorporate new cryptographic transforms. Maintain low bandwidth and computational cost. It is also Conservative in the size of implementation code. This is useful for devices with limited memory (for example, cell phones). Underlying transport independence, including network and physical layers that may be used, and perhaps prone to reordering and packet loss. These properties make the implementation of SRTP feasible even for mobile devices that have limited memory and processing capabilities. Similar design properties are found in MIKEY (Multimedia Internet Keying). Therefore, the use of MIKEY for key exchange and SRTP for media protection is one combination of mechanisms to provide adequate security for Internet multimedia applications, including VoIP, video, and conferencing. The application that implements SRTP has to convert RTP packets to SRTP packets before sending them across the network. The same process is used in reverse to decrypt SRTP packets and convert them to RTP packets
2. Theoretical Background
2.1 Format of SRTP
In addition to provide data encryption, the SRTP also supports message authentication and integrity of the RTP packet. The default message authentication algorithm for SRTP is SHA-1 which uses 160-bit key length. The MAC is produced by computing hash of RTP message. The diagram illustrates the phenomenon:
Fig 2: Format for SRTP
From the diagram 2 it is seen that SRTP message resembles the format of an RTP message with the two additional headers first one is Master Key Identifier and Authentication tag. The MKI can be used for identifying the master key from which the session keys were derived to use by the application to decrypt or verify authenticity of SRTP payload. And the second one is Authentication tag which is very important to provide protection against message-replay attacks [3] Note that the message headers are not encrypted. There is limitation where an attacker can perform traffic analysis by collecting information from the RTP headers and extensions along with information from transport layers example IP, UDP [6].
2.2 How SRTP Works?
Figure 3 shows an example of an application using SDescriptions (Security Descriptions) to transmit a cryptographic key for use with SRTP. The key is transmitted within the SDP portion of a SIP message. The SDP media attribute crypto defines the type of algorithm, the encryption mode, and the key length (AES_CM_128), along with the message digest algorithm and its length (SHA1_32).
Fig 3: Example of Application using SDECRIPTION.
The "inline" method indicates that the actual keying material is captured in the key-info field of the header. The syntax of the header is defined as follows:
a=crypto: []
Identifies the encryption and authentication algorithms (in this case, AES in counter mode using a 128-bit key length and SHA-1). The next attribute is, where
Key-params = ":"
In this case the is inline= UlrbLlfNTNw3blKHQVLGze6oHsyFdjGj3NheKoYx
After the keys have been negotiated, the application encrypts the RTP payload and sends the SRTP packets to the remote end. Figure 6.5 shows an example of the SRTP packet.
Fig 4: Content of SRTP
All headers in the RTP packet are sent in the clear except for the payload, which is encrypted. Because SRTP uses AES by default, it provides protection against DoS attacks that aim to corrupt the encrypted media content. Typically, stream ciphers that rely on previous blocks to decrypt the next block (cipher block chaining) can be attacked by corrupting the data of one block and thus crippling the ability to successfully reassemble and produce the original content. AES does not suffer from this limitation because it can decrypt each block without requiring knowledge of previous blocks. The use of authentication and integrity in SRTP messages is an important way to protect against attacks, including message replay and disruption of communications. For example, an attacker may modify the SRTP messages to corrupt the audio or video streams and thus cause service disruption. Another attack can be performed by sending bogus SRTP messages to a participant's device, thus forcing the device to attempt and decrypt the bogus messages. This attack forces the device application to impact the legitimate session by diverting resources to process the bogus messages. In cases where applications do not maintain session state, these attacks might not be as effective compared to stateful applications.
2.3. SRTP Key Management
Some of the attacks that can be dangerous in SRTP For example, an attacker may modify the SRTP messages to corrupt the audio or video steams and thus causes service disruption. Another attack can be performed by sending bogus SRTP message to a participant’s device, thus forcing the device to attempt and decrypt the bogus messages. These attacks are very effective in state applications. [5] Therefore, it is recommended that VoIP implementations use SRTP using SHA-1 with a 160-bit key length (and producing an 80-bit authentication tag) for message authentication and integrity to protect against such attacks. The table 1 below lists the parameters and corresponding values associates with key management in SRTP [6].
Table 1 SRTP Key Management
Parameter
|
Mandatory to Support
|
Default
|
SRTP/SRTCP cryptographic transforms
|
AES_CM, NULL
|
AES_CM, AES_F8 for UMTS
|
SRTP/SRTCP authentication transforms
|
HMAC_SHA1
|
HMAC_SHA1
|
SRTP/SRTCP authentication parameters
|
80-bit authentication tag
|
80-bit authentication tag
|
Key derivation Pseudo Random Function
|
AES_CM
|
AES_CM
|
Session encryption key length
|
128 bit
|
128 bit
|
Session authentication key length
|
160 bit
|
160 bit
|
Session salt value length
|
112 bit
|
112 bit
|
Key derivation rate
|
0
|
0
|
SRTP packets max key-lifetime
|
248
|
248
|
SRTCP packets max key-lifetime
|
231
|
231
|
MKI indicator
|
0
|
0
|
MKI length
|
0
|
0
|
In addition, some parameters are included in the crypto context for each session such as SSRC value Roll Over Counter(ROC), SEQ (RTP sequence), SRTCP index, transport address and port number.
2.4 Key Derivation
Although implementations may use a variety of key management mechanism to manage keys, the SRTP standard requires that a native derivation algorithm be used to generate session keys. This derivation algorithm is mandatory for initial session keys.
M Key
Ses. Key
External Key Management Mechanism
(E.g. MIKEY)
SRTP
Key Derivation
Algorithm
Ency.Key
M Salt
Auth.Key
Salt Key
Fig 3 Key derivation algorithm
From the figure 3 we can see that, the ability to derive keys through SRTP instead of using an external mechanism reduces additional computing cycles for key establishment. Typically, each session participant maintains a set of cryptographic context, there is at least one encryption, one salt and one authentication key for SRTP. [15]It can request only one master key and one salt value when required to derive necessary session keys. So for e.g. an attacker can collect large amounts of session data and attempt to perform cryptanalysis. If the same key is used for entire data, when that key is discovered all data can be recovered. If multiple keys are used only respective key can be recovered. Therefore, multiple session keys can support perfect forward secrecy.
MKI, Master Key Identifier. Variable length.
This field is defined, signaled and used by key management. MKI identifies the master key from which the session key(s) were derived that authenticate and/or encrypt the particular packet. Note that the MKI should identify the SRTP cryptographic context. The MKI may be used by key management for the purposes of re-keying, identifying a particular master key within the cryptographic context [1]
2.5 Seminar Questions and Answers
1. How big is an SRTP context?
In software, each AES-128 key takes about 160 bytes of information (that's the expanded key, 128 bits times ten rounds). The HMAC-SHA1 context will take up at least 20 bytes, but perhaps more. [14]
2. Why does SRTP have a NULL cipher?
The SRTP Null cipher is used when authentication is desired without encryption.
3. How key derivation works, is there packet loss in SRTP?
Packet loss is not a problem for SRTP key derivation because the n:th packet is the packet with the n:th packet index: The receiver will extract the sequence number from the first SRTP packet that it receives, compute the packet index [1]
4. The MKI is optional. Does that mean it is only present in some of the packets?
No, the MKI is signaled for the SRTP session and is not signaled on a packet-by-packet basis. In a given SRTP session, it is either present in every packet or not present at all. Also note that the MKI length if fixed for a particular session.
5. I don't see why the "salting key" is needed.
The use of the salting key helps to future-proof SRTP's predefined ciphers from attacks that will weaken its key strength below its key size; [12]
6. All keys are derived from a single master key, is this secure enough?
Yes, so long as the master key from which all keys are derived is not used beyond its recommended lifetime of 231 SRTCP packets or 248 RTP packets, whichever comes first
7. Why is AES Counter Mode Used by SRTP?
AES Counter Mode is the default cipher in SRTP because it requires zero packet expansion (i.e. there is no cryptographic padding), it processes out-of-order (non-sequential) data blocks efficiently, allows processing of data blocks in parallel.[6]
8. What is the length of the MKI?
RFC 3711 does not specify the length of the MKI field, though it does require that it be fixed for each SRTP session.
9. Is there a max possible size of an SRTP packet?
The largest possible payload, when the default encryption transform of AES Counter Mode is used, is at most 216 AES blocks, or 220 bytes. [1]
10. Is SRTP a separate protocol from RTP?
SRTP is not a separate protocol but a profile of RTP. SRTP's SAVP profile encapsulates RTP packets, encrypts the RTP payload, optionally adds a message authentication tag (message authentication is strongly recommended) and optionally adds an MKI.
2.6 Strength
Here are some of Strengths of SRTP which has been described: SRTP provides confidentiality, integrity and authentication of message. It provides protections against replay attacks for both RTP and RTCP.It supports AES which allows for out-of-order packet reception and processing. It also minimizes computation and resource consumption for generation cryptographic keys. Key derivation algorithm helps protect against certain cryptanalytic attacks and provide perfect forward secrecy. [6]
2.7 Weakness
There is lack for RTP header encryption which results in traffic analysis by collecting information from the RTP headers and extensions. It cannot maintain end-to-end message integrity and authentication because the media is mainly sent from an IP network to an SS7 network i.e. PSTN.The key refresh and key management impact has on processing and resource consumption in large multicast groups. [1]
3. Conclusion
Now a day SRTP has been a standard protocol to provide protection of media streams. It supports authentication, confidentiality and integrity of media message to help protect against attacks such as eavesdropping, message replay, call hijacking and various DoS attacks. One of the long term challenges and an area for further research remains in the key exchange and management in large multicast groups. At present, SRTP is not considered a standard in VOIP implementations. There is lack of expertise to deploy SRTP in VoIP enterprise environments by corporations. As for example, eavesdropping, disruption to convince organizations to deploy SRTP as a standard practice.
REFERENCES
[1] M. Baugher, D. Mcgrew Cisco Systems, Inc. RFC 3711, March 2004
[2] M. Naslund, E. CArrara, K.Norrman, Ericsson Research RFC 3711, March 2004
[3] J. Bilien, et al. Secure VoIP: Call Establishment and Media Protection. Royal Institute of Technology (KTH). Stockholm, Sweden, 2004
[4] http://www.heise.de/newsticker/meldung/91607 [Accessed 19th October 2007]
[5] http://www.news.com/2100-1010_3-6193211.html [Accessed 19th October 2007]
[6] http://www.searchnetworkingchannel.techtarget.com/tip/0,289483,sid100_gci127023
6, 00.html [Accessed 2nd December 2007]
[7] http://www.voip-info.org/wiki-SRTP [Accessed 2nd December 2007]
[8] http://srtp.sourceforge.net/srtp.html [Accessed 19th November 2007]
[9] http://srtp.sourceforge.net/faq.html [Accessed 25th November 2007]
[10] http://www.networksorcery.com/enp/protocol/srtp.htm [Accessed 27th November 2007]
[11] http:// tools.ietf.org/wg/sipping/draft-wing-sipping-srtp-key-02.txt [Accessed 22nd November 2007]
[12] http:// www.vovida.org/protocols/downloads/srtp/ [Accessed 19th November 2007]
[13] http://www.whatis.techtarget.com/definition/0,,sid9_gci1233810,00.html [Accessed 21st November 2007]
[14] http:// www.voipnow.org/2006/03/ingate_snom_suc.html [Accessed 2nd December 2007]
[15] http://www.imc.org/ietf-rtpsec/mail-archive/msg00694.html [Accessed 1st December 2007]
|