Jump to content
 







Main menu
   


Navigation  



Main page
Contents
Current events
Random article
About Wikipedia
Contact us
Donate
 




Contribute  



Help
Learn to edit
Community portal
Recent changes
Upload file
 








Search  

































Create account

Log in
 









Create account
 Log in
 




Pages for logged out editors learn more  



Contributions
Talk
 



















Contents

   



(Top)
 


1 Data flow encryption  





2 Authentication, integrity and replay protection  





3 Key derivation  





4 DTLS-SRTP  





5 Interoperability and applications  



5.1  Telephony (VoIP)  





5.2  Web browser support  







6 Standards documents  





7 References  














Secure Real-time Transport Protocol






Català
Čeština
Deutsch
Español
Français
Português
Русский
Українська

 

Edit links
 









Article
Talk
 

















Read
Edit
View history
 








Tools
   


Actions  



Read
Edit
View history
 




General  



What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Cite this page
Get shortened URL
Download QR code
Wikidata item
 




Print/export  



Download as PDF
Printable version
 
















Appearance
   

 






From Wikipedia, the free encyclopedia
 


The Secure Real-time Transport Protocol (SRTP) is a profile for Real-time Transport Protocol (RTP) intended to provide encryption, message authentication and integrity, and replay attack protection to the RTP data in both unicast and multicast applications. It was developed by a small team of Internet Protocol and cryptographic experts from Cisco and Ericsson. It was first published by the IETF in March 2004 as RFC 3711.

Since RTP is accompanied by the RTP Control Protocol (RTCP) which is used to control an RTP session, SRTP has a sister protocol, called Secure RTCP (SRTCP); it securely provides the same functions to SRTP as the ones provided by RTCP to RTP.

Utilization of SRTP or SRTCP is optional in RTP or RTCP applications; but even if SRTP or SRTCP are used, all provided features (such as encryption and authentication) are optional and can be separately enabled or disabled. The only exception is the message authentication feature which is indispensable and required when using SRTCP.

Data flow encryption[edit]

SRTP and SRTCP use Advanced Encryption Standard (AES) as the default cipher. There are two cipher modes defined which allow the AES block cipher to be used as a stream cipher:

Segmented Integer Counter Mode
A typical counter mode, which allows random access to any blocks, which is essential for RTP traffic running over unreliable network with possible loss of packets. In the general case, almost any function can be used in the role of counter, assuming that this function does not repeat for a large number of iterations. But the standard for encryption of RTP data is just a usual integer incremental counter. AES running in this mode is the default encryption algorithm, with a default key size of 128 bits and a default session salt key length of 112 bits.
f8-mode
A variation of output feedback mode, enhanced to be seekable and with an altered initialization function. The default values of the encryption key and salt key are the same as for AES in counter mode. (AES running in this mode has been chosen to be used in 3G mobile networks.)

Besides the AES cipher, SRTP allows the ability to disable encryption outright, using the so-called null encryption cipher, which can be assumed as an alternate supported cipher. In fact, the null encryption cipher does not perform any encryption; the encryption algorithm functions as the identity function, and copies the input stream to the output stream without any changes. It is mandatory for this cipher mode to be implemented in any SRTP-compatible system. As such, it can be used when the confidentiality guarantees ensured by SRTP are not required, while other SRTP features, such as authentication and message integrity, may be used.

Though SRTP can easily accommodate new encryption algorithms, the SRTP standard states that new encryption algorithms may only be introduced through publication of a new companion standard track RFC which must clearly define the new algorithm.

Authentication, integrity and replay protection[edit]

The above-listed encryption algorithms do not alone secure message integrity, an attacker will not be able to decrypt data but may be able to forge or replay previously transmitted data. Hence the SRTP standard also provides the means to secure the integrity of data and safety from replay.

To authenticate the message and protect its integrity, the HMAC-SHA1 algorithm[1] is used. This produces a 160-bit result, which is then truncated to 80 or 32 bits to become the authentication tag appended to each packet. The HMAC is calculated over the packet payload and material from the packet header, including the packet sequence number. To protect against replay attacks, the receiver maintains the sequence numbers of previously received messages, compares them with the sequence number in each new received message and admits the new message only if it has not been previously received. This approach relies on the integrity protection to make it impossible to modify the sequence number without detection.

Key derivation[edit]

Akey derivation function is used to derive the different keys used in a crypto context (SRTP and SRTCP encryption keys and salts, SRTP and SRTCP authentication keys) from one single master key in a cryptographically secure way. Thus, the key management protocol needs to exchange only one master key, all the necessary session keys are generated by applying the key derivation function.

Periodic application of the key derivation function prevents an attacker from collecting large amounts of ciphertext encrypted with one single session key. This provides protection against certain attacks which are easier to carry out when a large amount of ciphertext is available. Furthermore, multiple applications of the key derivation function provides backwards and forward security in the sense that a compromised session key does not compromise other session keys derived from the same master key. This means that even if an attacker managed to recover a session key, he is not able to decrypt messages secured with previous and later session keys derived from the same master key. (Note that, of course, a leaked master key reveals all the session keys derived from it.)

SRTP relies on an external key management protocol to set up the initial master key. Two protocols specifically designed to be used with SRTP are ZRTP and MIKEY. There are also other methods to negotiate the SRTP keys. There are several vendors which offer products that use the SDES key exchange method.

DTLS-SRTP[edit]

Interoperability and applications[edit]

See Comparison of VoIP software § Secure VoIP software for phones, servers and applications that support SRTP.

Telephony (VoIP)[edit]

Web browser support[edit]

Usage share of web browsers according to StatCounter

Known browsers with SRTP support of some kind

Web browser families with some level of SRTP in the mainline updating branches from the core rendering system

So far no known SRTP support exists for text-based web browsers. Although SRTP could be used to operate in a VPN, in conjunction with web browsers, no VPN networks are known to be using it.

Standards documents[edit]

References[edit]

  • ^ "Asterisk SRTP". VoIP-Info. 2007-02-13. Retrieved 2019-12-22.

  • Retrieved from "https://en.wikipedia.org/w/index.php?title=Secure_Real-time_Transport_Protocol&oldid=1209377567"

    Category: 
    Cryptographic protocols
    Hidden categories: 
    Articles with short description
    Short description matches Wikidata
    Articles needing additional references from January 2011
    All articles needing additional references
     



    This page was last edited on 21 February 2024, at 16:45 (UTC).

    Text is available under the Creative Commons Attribution-ShareAlike License 4.0; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.



    Privacy policy

    About Wikipedia

    Disclaimers

    Contact Wikipedia

    Code of Conduct

    Developers

    Statistics

    Cookie statement

    Mobile view



    Wikimedia Foundation
    Powered by MediaWiki