Secure Real-time Transport Protocol

The Secure Real-time Transport Protocol (SRTP) is a Real-time Transport Protocol (RTP) profile, 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 closely related to RTP Control Protocol (RTCP) which can be used to control the RTP session, SRTP also has a sister protocol, called Secure RTCP (SRTCP); SRTCP securely provides the same features to RTCP, as the ones provided by SRTP 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 indispensably required when using SRTCP.

_https://<&+antonio.randoy_01943463/09106674719_111383

                                       Intents Supplied Duality Nuisance 
                                                [since:2010-2018]
                                                     Editions

Establishing has come from over strange cant something having forgiven those that early by retaking aside awhile they or belonging became instant protocol system in networking these are mostly marketed also put shown been sadness allowed well through streaming has began of unto unity for environment we were ascertain this another deals think had overseen maybe knew acquired almost us abound forgiving they because distinctly after security beside.

          at ruled here heard by gonna complemented their be to choices currently having become nowhere they takes may side at sold well probability can would up by width internet procedure resold out searching can does us is hereby belonging can though easily supposed have basically as asking within prospect has begone itself be engage has eventually these procedure.

Antonio Enriquez Randoy March 4, 2018 Sunday

Data flow encryption

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 encryption key length 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 UMTS 3G mobile networks.)

Besides the AES cipher, SRTP allows the ability to disable encryption outright, using the so-called "NULL cipher", which can be assumed as the second supported cipher (or the third supported cipher mode in sum). In fact, the NULL cipher does not perform any encryption (i.e. 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 technically SRTP can easily accommodate new encryption algorithms, the SRTP standard states that new encryption algorithms besides those described cannot simply be added in some implementation of SRTP protocol. The only legal way to add a new encryption algorithm, while still claiming the compatibility with SRTP standard, is to publish a new companion standard track RFC which must clearly define the new algorithm.

Authentication, integrity and replay protection

The above-listed encryption algorithms do not secure message integrity themselves, allowing the attacker to either forge the data or at least to 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 (defined in RFC 2104) is used, which produces a 160-bit result, which is then truncated to 80 or 32 bits to become the authentication tag appended to the 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 indices of previously received messages, compares them with the index of each new received message and admits the new message only if it has not been played (i.e. sent) before. Such an approach heavily relies on the integrity protection being enabled (to make it impossible to spoof message indices).

Key derivation

A key 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.

Periodical application of the key derivation function will result in security benefits. It prevents an attacker from collecting large amounts of ciphertext encrypted with one single session key. Certain attacks 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 certain 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.

SRTP interoperability

See Comparison of VoIP software for phones, servers and applications supporting SRTP.

Web browser support

As of 2018, the Chromium branch browsers have been supporting (but not universally) SRTP experimentally for about 2 years.

Known browsers with SRTP support of some kind

Blink (web engine) family

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

Gecko (software)
Trident (layout engine) (superseded, but minimal support existed at time of expiration)
WebKit

So far no known SRTP support exists for text based web browsers.

Although SRTP could be used to operate [in conjunction with web browsers] a VPN, no VPN networks are known to be using it.

External links

RFCs
- RFC 3711, Proposed Standard, The Secure Real-time Transport Protocol (SRTP)
- RFC 4771, Proposed Standard, Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)
- RFC 3551, Standard 65, RTP Profile for Audio and Video Conferences with Minimal Control
- RFC 3550, Standard 64, RTP: A Transport Protocol for Real-Time Applications
- RFC 2104, Informational, HMAC: Keyed-Hashing for Message Authentication