Ana səhifə

Lappeenrannan university of technology


Yüklə 160 Kb.
tarix25.06.2016
ölçüsü160 Kb.


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




  1. 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).



    1. 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]





Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©atelim.com 2016
rəhbərliyinə müraciət