#include "include/jsrtp.h"

Detailed Description

Secure Real-Time Protocol (SRTP)

SRTP Framework

RTP is the Real-time Transport Protocol [RFC3550]. We define SRTP as a profile of RTP. This profile is an extension to the RTP Audio/Video Profile [RFC3551]. Except where explicitly noted, all aspects of that profile apply, with the addition of the SRTP security features. Conceptually, we consider SRTP to be a "bump in the stack" implementation which resides between the RTP application and the transport layer. SRTP intercepts RTP packets and then forwards an equivalent SRTP packet on the sending side, and intercepts SRTP packets and passes an equivalent RTP packet up the stack on the receiving side.

Secure RTCP (SRTCP) provides the same security services to RTCP as SRTP does to RTP. SRTCP message authentication is MANDATORY and thereby protects the RTCP fields to keep track of membership, provide feedback to RTP senders, or maintain packet sequence counters. SRTCP is described in Section 3.4.

Secure RTP (see IETF specifications RFC3711, RFC7741)

The format of an SRTP packet is illustrated in Figure 1 [1]

Secure Real-Time Protocol (SRTP) Packet Structure

The ﬁrst twelve octets are present in every RTP packet, while the list of CSRC identiﬁers is present only when inserted by a mixer. The ﬁelds have the following meaning:

version (V): 2 bits

This ﬁeld identiﬁes the version of RTP. The version deﬁned by this speciﬁcation is two (2). (The value 1 is used by the ﬁrst draft version of RTP and the value 0 is used by the protocol initially implemented in the “vat” audio tool.)
padding (P): 1 bit

If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored, including itself. Padding may be needed by some encryption algorithms with ﬁxed block sizes or for carrying several RTP packets in a lower-layer protocol data unit.
extension (X): 1 bit

If the extension bit is set, the ﬁxed header must be followed by exactly one header extension, with a format deﬁned in Section 5.3.1.
CSRC count (CC): 4 bits

The CSRC count contains the number of CSRC identiﬁers that follow the ﬁxed header.
marker (M): 1 bit

The interpretation of the marker is deﬁned by a proﬁle. It is intended to allow signiﬁcant events such as frame boundaries to be marked in the packet stream. A proﬁle may deﬁne additional marker bits or specify that there is no marker bit by changing the number of bits in the payload type ﬁeld (see Section 5.3).
payload type (PT): 7 bits

This ﬁeld identiﬁes the format of the RTP payload and determines its interpretation by the application. A proﬁle may specify a default static mapping of payload type codes to payload formats. Additional payload type codes may bedeﬁned dynamically through non-RTP means (see Section 3). A set of default mappings for audio and video is speciﬁed in the companion RFC 3551 [1]. An RTP source may change the payload type during a session, but this ﬁeld should not be used for multiplexing separate media streams (see Section 5.2). A receiver must ignore packets with payload types that it does not understand.
sequence number: 16 bits

The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number should be random (unpredictable) to make known-plaintext attacks on encryption more diﬃcult, even if the source itself does not encrypt according to the method in Section 9.1, because the packets may ﬂow through a translator that does. Techniques for choosing unpredictable numbers are discussed in [17].
timestamp: 32 bits

The timestamp reﬂects the sampling instant of the ﬁrst octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations (see Section 6.4.1). The resolution of the clock must be suﬃcient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not suﬃcient). The clock frequency is dependent on the format of data carried as payload and is speciﬁed statically in the proﬁle or payload format speciﬁcation that deﬁnes the format, or may be speciﬁed dynamically for payload formats deﬁned through non-RTP means. If RTP packets are generated periodically, the nominal sampling instant as determined from the sampling clock is to be used, not a reading of the system clock. As an example, for ﬁxed-rate audio the timestamp clock would likely increment byone for each samplingperiod. If an audio application reads blocks covering 160 sampling periods from the input device, the timestamp would be increased by 160 for each such block, regardless of whether the block is transmitted in a packet or dropped as silent. The initial value of the timestamp should be random, as for the sequence number. Several consecutive RTP packets will have equal timestamps if they are (logically) generated at once, e.g., belong to the same video frame. Consecutive RTP packets may contain timestamps that are not monotonic if the data is not transmitted in the order it was sampled, as in the case of MPEG interpolated video frames. (The sequence numbers of the packets as transmitted will still be monotonic.) RTP timestamps from diﬀerent media streams may advance at diﬀerent rates and usually have independent, random oﬀsets. Therefore, although these timestamps are suﬃcient to reconstruct the timing of a single stream, directly comparing RTP timestamps from diﬀerent media is not eﬀective for synchronization. Instead, for each medium the RTP timestamp is related to the sampling instant by pairing it with a timestamp from a reference clock (wallclock) that represents the time when the data corresponding to the RTP timestamp was sampled. The reference clock is shared by all media to be synchronized. The timestamp pairs are not transmitted in every data packet, but at a lower rate in RTCP SR packets as described in Section 6.4. The sampling instant is chosen as the point of reference for the RTP timestamp because it is known to the transmitting endpoint and has a common deﬁnition for all media, independent of encoding delays or other processing. The purpose is to allow synchronized presentation of all media sampled at the same time. Applications transmitting stored data rather than data sampled in real time typically use a virtual presentation timeline derived from wallclock time to determine when the next frame or other unit of each medium in the stored data should be presented. In this case, the RTP timestamp would reﬂect the presentation time for each unit. That is, the RTP timestamp for each unit would be related to the wallclock time at which the unit becomes current on the virtual presentation timeline. Actual presentation occurs some time later as determined by the receiver. An example describing live audio narration of prerecorded video illustrates the signiﬁcance of choosing the sampling instant as the reference point. In this scenario, the video would be presented locally for the narrator to view and would be simultaneously transmitted using RTP. The “sampling instant” of a video frame transmitted in RTP would be established by referencing its timestamp to the wallclock time when that video frame was presented to the narrator. The sampling instant for the audio RTP packets containing the narrator’s speech would be established by referencing the same wallclock time when the audio was sampled. The audio and video may even be transmitted by diﬀerent hosts if the reference clocks on the two hosts are synchronized by some means such as NTP. A receiver can then synchronize presentation of the audio and video packets by relating their RTP timestamps using the timestamp pairs in RTCP SR packets.
SSRC: 32 bits

The SSRC ﬁeld identiﬁes the synchronization source. This identiﬁer should be chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identiﬁer. An example algorithm for generating a random identiﬁer is presented in Appendix A.6. Although the probability of multiple sources choosing the same identiﬁer is low, all RTP implementations must be prepared to detect and resolve collisions. Section 8 describes the probability of collision along with a mechanism for resolving collisions and detecting RTP-level forwarding loops based on the uniqueness of the SSRC identiﬁer. If a source changes its source transport address, it must also choose a new SSRC identiﬁer to avoid being interpreted as a looped source (see Section 8.2).
CSRC list: 0 to 15 items, 32 bits each

The CSRC list identiﬁes the contributing sources for the payload contained in this packet. The number of identiﬁers is given by the CC ﬁeld. If there are more than 15 contributing sources, only 15 can be identiﬁed. CSRC identiﬁers are inserted by mixers (see Section 7.1), using the SSRC identiﬁers of contributing sources. For example, for audio packets the SSRC identiﬁers of all sources that were mixed together to create a packet are listed, allowing correct talker indication at the receiver.

The "Encrypted Portion" of an SRTP packet consists of the encryption of the RTP payload (including RTP padding when present) of the equivalent RTP packet. The Encrypted Portion MAY be the exact size of the plaintext or MAY be larger. Figure 1 shows the RTP payload including any possible padding for RTP [RFC3550].

None of the pre-defined encryption transforms uses any padding; for these, the RTP and SRTP payload sizes match exactly. New transforms added to SRTP (following Section 6) may require padding, and may hence produce larger payloads. RTP provides its own padding format (as seen in Fig. 1), which due to the padding indicator in the RTP header has merits in terms of compactness relative to paddings using prefix-free codes. This RTP padding SHALL be the default method for transforms requiring padding. Transforms MAY specify other padding methods, and MUST then specify the amount, format, and processing of their padding. It is important to note that encryption transforms that use padding are vulnerable to subtle attacks, especially when message authentication is not used [V02]. Each specification for a new encryption transform needs to carefully consider and describe the security implications of the padding that it uses. Message authentication codes define their own padding, so this default does not apply to authentication transforms.

The OPTIONAL MKI and the RECOMMENDED authentication tag are the only fields defined by SRTP that are not in RTP. Only 8-bit alignment is assumed.

MKI (Master Key Identifier): configurable length, OPTIONAL. The MKI is defined, signaled, and used by key management. The 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 SHALL NOT identify the SRTP cryptographic context, which is identified according to Section 3.2.3. The MKI MAY be used by key management for the purposes of re-keying, identifying a particular master key within the cryptographic context (Section 3.2.1).
Authentication tag: configurable length, RECOMMENDED. The authentication tag is used to carry message authentication data. The Authenticated Portion of an SRTP packet consists of the RTP header followed by the Encrypted Portion of the SRTP packet. Thus, if both encryption and authentication are applied, encryption SHALL be applied before authentication on the sender side and conversely on the receiver side. The authentication tag provides authentication of the RTP header and payload, and it indirectly provides replay protection by authenticating the sequence number. Note that the MKI is not integrity protected as this does not provide any extra protection.

SRTP Cryptographic Contexts

Each SRTP stream requires the sender and receiver to maintain cryptographic state information. This information is called the "cryptographic context". SRTP uses two types of keys: session keys and master keys. By a "session key", we mean a key which is used directly in a cryptographic transform (e.g., encryption or message authentication), and by a "master key", we mean a random bit string (given by the key management protocol) from which session keys are derived in a cryptographically secure way. The master key(s) and other parameters in the cryptographic context are provided by key management mechanisms external to SRTP, see Section 8.

Transform-independent parameters

Transform-independent parameters are present in the cryptographic context independently of the particular encryption or authentication transforms that are used. The transform-independent parameters of the cryptographic context for SRTP consist of:

a 32-bit unsigned rollover counter (ROC), which records how many times the 16-bit RTP sequence number has been reset to zero after passing through 65,535. Unlike the sequence number (SEQ), which SRTP extracts from the RTP packet header, the ROC is maintained by SRTP as described in Section 3.3.1.

We define the index of the SRTP packet corresponding to a given ROC and RTP sequence number to be the 48-bit quantity
```
   \f[
       i = {2}^{16} \oplus ROC + SEQ
   \f]
```
for the receiver only, a 16-bit sequence number s_l, which can be thought of as the highest received RTP sequence number (see Section 3.3.1 for its handling), which SHOULD be authenticated since message authentication is RECOMMENDED,
an identifier for the encryption algorithm, i.e., the cipher and its mode of operation,
an identifier for the message authentication algorithm,
a replay list, maintained by the receiver only (when authentication and replay protection are provided), containing indices of recently received and authenticated SRTP packets,
an MKI indicator (0/1) as to whether an MKI is present in SRTP and SRTCP packets,
if the MKI indicator is set to one, the length (in octets) of the MKI field, and (for the sender) the actual value of the currently active MKI (the value of the MKI indicator and length MUST be kept fixed ror the lifetime of the context),
the master key(s), which MUST be random and kept secret,
for each master key, there is a counter of the number of SRTP packets that have been processed (sent) with that master key (essential for security, see Sections 3.3.1 and 9),
non-negative integers n_e, and n_a, determining the length of the session keys for encryption, and message authentication.

In addition, for each master key, an SRTP stream MAY use the following associated values:

a master salt, to be used in the key derivation of session keys. This value, when used, MUST be random, but MAY be public. Use of master salt is strongly RECOMMENDED, see Section 9.2. A "NULL" salt is treated as 00...0.
an integer in the set {1,2,4,..., ${2}^{24}$ }, the "key_derivation_rate", where an unspecified value is treated as zero. The constraint to be a power of 2 simplifies the session-key derivation implementation, see Section 4.3.
an MKI value,
<From, To> values, specifying the lifetime for a master key, expressed in terms of the two 48-bit index values inside whose range (including the range end-points) the master key is valid. For the use of <From, To>, see Section 8.1.1. <From, To> is an alternative to the MKI and assumes that a master key is in one to-one correspondence with the SRTP session key on which the <From, To> range is defined.

` SRTCP SHALL by default share the crypto context with SRTP, except:

no rollover counter and s_l-value need to be maintained as the RTCP index is explicitly carried in each SRTCP packet,
a separate replay list is maintained (when replay protection is provided),
SRTCP maintains a separate counter for its master key (even if the master key is the same as that for SRTP, see below), as a means to maintain a count of the number of SRTCP packets that have been processed with that key.

Note in particular that the master key(s) MAY be shared between SRTP and the corresponding SRTCP, if the pre-defined transforms (including the key derivation) are used but the session key(s) MUST NOT be so shared.

In addition, there can be cases (see Sections 8 and 9.1) where several SRTP streams within a given RTP session, identified by their synchronization source (SSRCs, which is part of the RTP header), share most of the crypto context parameters (including possibly master and session keys). In such cases, just as in the normal SRTP/SRTCP parameter sharing above, separate replay lists and packet counters for each stream (SSRC) MUST still be maintained.

Also, separate SRTP indices MUST then be maintained. A summary of parameters, pre-defined transforms, and default values for the above parameters (and other SRTP parameters) can be found in Sections 5 and 8.2.

SRTP Packet Processing

Assuming initialization of the cryptographic context(s) has taken place via key management, the sender SHALL do the following to construct an SRTP packet:

Determine which cryptographic context to use as described in Section 3.2.3.
Determine the index of the SRTP packet using the rollover counter, the highest sequence number in the cryptographic context, and the sequence number in the RTP packet, as described in Section 3.3.1.
Determine the master key and master salt. This is done using the index determined in the previous step or the current MKI in the cryptographic context, according to Section 8.1.
Determine the session keys and session salt (if they are used by the transform) as described in Section 4.3, using master key, master salt, key_derivation_rate, and session key-lengths in the cryptographic context with the index, determined in Steps 2 and 3.
Encrypt the RTP payload to produce the Encrypted Portion of the packet (see Section 4.1, for the defined ciphers). This step uses the encryption algorithm indicated in the cryptographic context, the session encryption key and the session salt (if used) found in Step 4 together with the index found in Step 2.
If the MKI indicator is set to one, append the MKI to the packet.
For message authentication, compute the authentication tag for the Authenticated Portion of the packet, as described in Section 4.2. This step uses the current rollover counter, the authentication algorithm indicated in the cryptographic context, and the session authentication key found in Step 4. Append the authentication tag to the packet.
If necessary, update the ROC as in Section 3.3.1, using the packet index determined in Step 2.

To authenticate and decrypt an SRTP packet, the receiver SHALL do the following:

Determine which cryptographic context to use as described in Section 3.2.3.
Run the algorithm in Section 3.3.1 to get the index of the SRTP packet. The algorithm uses the rollover counter and highest sequence number in the cryptographic context with the sequence number in the SRTP packet, as described in Section 3.3.1.
Determine the master key and master salt. If the MKI indicator in the context is set to one, use the MKI in the SRTP packet, otherwise use the index from the previous step, according to Section 8.1.
Determine the session keys, and session salt (if used by the transform) as described in Section 4.3, using master key, master salt, key_derivation_rate and session key-lengths in the cryptographic context with the index, determined in Steps 2 and 3.
For message authentication and replay protection, first check if the packet has been replayed (Section 3.3.2), using the Replay List and the index as determined in Step 2. If the packet is judged to be replayed, then the packet MUST be discarded, and the event SHOULD be logged.

Next, perform verification of the authentication tag, using the rollover counter from Step 2, the authentication algorithm indicated in the cryptographic context, and the session authentication key from Step 4. If the result is "AUTHENTICATION FAILURE" (see Section 4.2), the packet MUST be discarded from further processing and the event SHOULD be logged.
Decrypt the Encrypted Portion of the packet (see Section 4.1, for the defined ciphers), using the decryption algorithm indicated in the cryptographic context, the session encryption key and salt (if used) found in Step 4 with the index from Step 2.
Update the rollover counter and highest sequence number, s_l, in the cryptographic context as in Section 3.3.1, using the packet index estimated in Step 2. If replay protection is provided, also update the Replay List as described in Section 3.3.2.
When present, remove the MKI and authentication tag fields from the packet.

Packet Index Determination, and ROC, s_l Update

SRTP implementations use an "implicit" packet index for sequencing, i.e., not all of the index is explicitly carried in the SRTP packet. For the pre-defined transforms, the index i is used in replay protection (Section 3.3.2), encryption (Section 4.1), message authentication (Section 4.2), and for the key derivation (Section 4.3).

When the session starts, the sender side MUST set the rollover counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps modulo ${2}^{16}$ , the sender side MUST increment ROC by one, modulo ${2}^{32}$ (see security aspects below). The sender’s packet index is then defined as

      \f[
          i = {2}^{16} \oplus ROC + SEQ
      \f]

Receiver-side implementations use the RTP sequence number to determine the correct index of a packet, which is the location of the packet in the sequence of all SRTP packets. A robust approach for the proper use of a rollover counter requires its handling and use to be well defined. In particular, out-of-order RTP packets with sequence numbers close to ${2}^{16}$ or zero must be properly handled.

The index estimate is based on the receiver’s locally maintained ROC and s_l values. At the setup of the session, the ROC MUST be set to zero. Receivers joining an on-going session MUST be given the current ROC value using out-of-band signaling such as key-management signaling. Furthermore, the receiver SHALL initialize s_l to the RTP sequence number (SEQ) of the first observed SRTP packet (unless the initial value is provided by out of band signaling such as key management).

On consecutive SRTP packets, the receiver SHOULD estimate the index as

      \f[
          i = {2}^{16} \oplus v + SEQ
      \f]

where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo ${2}^{32}$ ) such that i is closest (in modulo ${2}^{48}$ sense) to the value ${2}^{16} \oplus ROC + s_l$ (see Appendix A for pseudocode).

After the packet has been processed and authenticated (when enabled for SRTP packets for the session), the receiver MUST use v to conditionally update its s_l and ROC variables as follows. If $v=(ROC-1) \bmod{{2}^{32}}$ , then there is no update to s_l or ROC. If v=ROC, then s_l is set to SEQ if and only if SEQ is larger than the current s_l; there is no change to ROC. If $v=(ROC+1) \bmod{{2}^{32}}$ , then s_l is set to SEQ and ROC is set to v.

After a re-keying occurs (changing to a new master key), the rollover counter always maintains its sequence of values, i.e., it MUST NOT be reset to zero.

As the rollover counter is 32 bits long and the sequence number is 16 bits long, the maximum number of packets belonging to a given SRTP stream that can be secured with the same key is ${2}^{48}$ using the predefined transforms. After that number of SRTP packets have been sent with a given (master or session) key, the sender MUST NOT send any more packets with that key. (There exists a similar limit for SRTCP, which in practice may be more restrictive, see Section 9.2.) This limitation enforces a security benefit by providing an upper bound on the amount of traffic that can pass before cryptographic keys are changed. Re-keying (see Section 8.1) MUST be triggered, before this amount of traffic, and MAY be triggered earlier, e.g., for increased security and access control to media. Recurring key derivation by means of a non-zero key_derivation_rate (see Section 4.3), also gives stronger security but does not change the above absolute maximum value.

On the receiver side, there is a caveat to updating s_l and ROC: if message authentication is not present, neither the initialization of s_l, nor the ROC update can be made completely robust. The receiver’s "implicit index" approach works for the pre-defined transforms as long as the reorder and loss of the packets are not too great and bit-errors do not occur in unfortunate ways. In particular, ${2}^{15}$ packets would need to be lost, or a packet would need to be ${2}^{15}$ packets out of sequence before synchronization is lost. Such drastic loss or reorder is likely to disrupt the RTP application itself.

The algorithm for the index estimate and ROC update is a matter of implementation, and should take into consideration the environment (e.g., packet loss rate) and the cases when synchronization is likely to be lost, e.g., when the initial sequence number (randomly chosen by RTP) is not known in advance (not sent in the key management protocol) but may be near to wrap modulo ${2}^{16}$ .

A more elaborate and more robust scheme than the one given above is the handling of RTP’s own "rollover counter", see Appendix A.1 of [RFC3550].

Replay Protection

Secure replay protection is only possible when integrity protection is present. It is RECOMMENDED to use replay protection, both for RTP and RTCP, as integrity protection alone cannot assure security against replay attacks.

A packet is "replayed" when it is stored by an adversary, and then re-injected into the network. When message authentication is provided, SRTP protects against such attacks through a Replay List. Each SRTP receiver maintains a Replay List, which conceptually contains the indices of all of the packets which have been received and authenticated. In practice, the list can use a "sliding window" approach, so that a fixed amount of storage suffices for replay protection. Packet indices which lag behind the packet index in the context by more than SRTP-WINDOW-SIZE can be assumed to have been received, where SRTP-WINDOW-SIZE is a receiver-side, implementation dependent parameter and MUST be at least 64, but which MAY be set to a higher value.

The receiver checks the index of an incoming packet against the replay list and the window. Only packets with index ahead of the window, or, inside the window but not already received, SHALL be accepted.

After the packet has been authenticated (if necessary the window is first moved ahead), the replay list SHALL be updated with the new index. The Replay List can be efficiently implemented by using a bitmap to represent which packets have been received, as described in the Security Architecture for IP [RFC2401].

Generic AEAD Processing

Types of Input Data

Associated Data: This is data that is to be authenticated but not encrypted
Plaintext: Data that is to be both encrypted and authenticated
Raw Data: Data that is to be neither encrypted nor authenticated

Which portions of SRTP/SRTCP packets that are to be treated as associated data, which are to be treated as plaintext, and which are to be treated as raw data

AEAD Invocation Inputs and Outputs

Encrypt Mode

Inputs:

Encryption_key : Octet string, either 16 or 32 octets long
Initialization_Vector : Octet string, 12 octets long
Associated_Data : Octet string of variable length
Plaintext : Octet string of variable length

Outputs:

Ciphertext : Octet string, length = length(Plaintext)+tag_length

(*): In AEAD the authentication tag in embedded in the cipher text. When GCM is being used the ciphertext consists of the encrypted plain text followed by the authentication tag.

Decrypt Mode

Inputs:

Encryption_key : Octet string, either 16 or 32 octets long
Initialization_Vector : Octet string, 12 octets long
Associated_Data : Octet string of variable length
Ciphertext : Octet string of variable length

Outputs:

Plaintext : Octet string, length = length(Ciphertext)-tag_length
Validity_Flag : Boolean, TRUE if valid, FALSE otherwise

Handling of AEAD Authentication

AEAD requires that all incoming packets MUST pass AEAD authentication before any other action takes place. Plaintext and associated data MUST NOT be released until the AEAD authentication tag has been validated. Further the ciphertext MUST NOT be decrypted until the AEAD tag has been validated.

Should the AEAD tag prove to be invalid, the packet in question is to be discarded and a Validation Error flag raised. Local policy determines how this flag is to be handled and is outside the scope of this document.

Counter Mode Encryption

Each outbound packet uses a 12-octet IV and an encryption key to form two outputs, a 16-octet first_key_block which is used in forming the authentication tag and a key stream of octets, formed in blocks of 16-octets each. The first 16-octet block of key is saved for use in forming the authentication tag, and the remainder of the key stream is XORed to the plaintext to form cipher. This key stream is formed one block at a time by inputting the concatenation of a 12-octet IV (see sections 8.1 and 9.1) with a 4-octet block to AES. The pseudo-code below illustrates this process:

def GCM_keystream( Plaintext_len, IV, Encryption_key ):
    assert Plaintext_len  <= (2**36) - 32 ## measured in octets
    key_stream = ""
    block_counter = 1
    first_key_block = AES_ENC( data=IV||block_counter,
                               key=Encryption_key        )
    while len(key_stream) < Plaintext_len:
          block_counter = block_counter + 1
          key_block = AES_ENC( data=IV||block_counter,
          key=Encryption_key        )
          key_stream  = key_stream || key_block
          key_stream = truncate( key_stream, Plaintext_len )
    return (first_key_block, key_stream )

In theory this keystream generation process allows for the encryption of up to ${2}^{36}-32$ octets per invocation (i.e. per packet), far longer than is actually required.

With any counter mode, if the same (IV, Encryption_key) pair is used twice, precisely the same keystream is formed. As explained in section 9.1 of RFC 3711, this is a cryptographic disaster. For GCM the consequences are even worse since such a reuse compromises GCM’s integrity mechanism not only for the current packet stream but for all future uses of the current encryption_key.

Unneeded SRTP/SRTCP Fields

AEAD counter mode encryption removes the need for certain existing SRTP/SRTCP mechanisms.

SRTP/SRTCP Authentication Field

The AEAD message authentication mechanism MUST be the primary message authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP authentication mechanisms SHOULD NOT be used with any AEAD algorithm and the optional SRTP/SRTCP Authentication Tags are NOT RECOMMENDED and SHOULD NOT be present. Note that this contradicts section 3.4 of [RFC3711] which makes the use of the SRTCP Authentication field mandatory, but the presence of the AEAD authentication renders the older authentication methods redundant.

Rationale - Some applications use the SRTP/SRTCP Authentication Tag as a means of conveying additional information, notably [RFC4771]. This document retains the Authentication Tag field primarily to preserve compatibility with these applications.

RTP Padding

AES-GCM does not requires that the data be padded out to a specific block size, reducing the need to use the padding mechanism provided by RTP. It is RECOMMENDED that the RTP padding mechanism not be used unless it is necessary to disguise the length of the underlying plaintext.

AES-GCM processing for SRTP

SRTP IV formation for AES-GCM

 0  0  0  0  0  0  0  0  0  0  1  1
 0  1  2  3  4  5  6  7  8  9  0  1
+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00|    SSRC   |     ROC   | SEQ |---+
+--+--+--+--+--+--+--+--+--+--+--+--+   |
                                        |
+--+--+--+--+--+--+--+--+--+--+--+--+   |
|         Encryption Salt           |->(+)
+--+--+--+--+--+--+--+--+--+--+--+--+   |
                                        |
+--+--+--+--+--+--+--+--+--+--+--+--+   |
|       Initialization Vector       |<--+
+--+--+--+--+--+--+--+--+--+--+--+--+
 
Figure 1: AES-GCM SRTP Initialization
                Vector Formation

Vector formation - The 12 octet initialization vector used by AES-GCM SRTP is formed by first concatenating 2 octets of zeroes, the 4-octet SSRC, the 4-octet Rollover Counter (ROC) and the 2-octet sequence number SEQ. The resulting 12-octet value is then XORed to the 12-octet salt to form the 12-octet IV.

Summary of AES-GCM in SRTP/SRTCP

For convenience, much of the information about the use of AES-GCM family of algorithms in SRTP is collected in the tables contained in this section. The AES-GCM family of AEAD algorithms is built around the AES block cipher algorithm. AES-GCM uses AES counter mode for encryption and Galois Message Authentication Code (GMAC) for authentication. A detailed description of the AES-GCM family can be found in [RFC5116]. The following members of the AES-GCM family may be used with SRTP/SRTCP:

Name                 Key Size      AEAD Tag Size      Reference
================================================================
AEAD_AES_128_GCM_8   16 octets      8 octets          [RFC5282]
AEAD_AES_128_GCM     16 octets     16 octets          [RFC5116]
AEAD_AES_256_GCM     32 octets     16 octets          [RFC5116]
 
        Table 1: AES-GCM algorithms for SRTP/SRTCP

Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication tags), and it MAY support AEAD_AES_128_GCM_8 Below we summarize parameters associated with these three GCM algorithms:

+--------------------------------+------------------------------+
| Parameter                      | Value                        |
+--------------------------------+------------------------------+ 
| Master key length              | 128 bits                     |
| Master salt length             | 96 bits                      |
| Key Derivation Function        | AES_CM_PRF [RFC3711]         |
| Maximum key lifetime (SRTP)    | 2^48 packets                 |
| Maximum key lifetime (SRTCP)   | 2^31 packets                 |
| Cipher (for SRTP and SRTCP)    | AEAD_AES_128_GCM_8           |
| AEAD authentication tag length | 64 bits                      |
+--------------------------------+------------------------------+
            Table 2: The AEAD_AES_128_GCM_8 Crypto Suite
 
+--------------------------------+------------------------------+
| Parameter                      | Value                        |
+--------------------------------+------------------------------+
| Master key length              | 128 bits                     |
| Master salt length             | 96 bits                      |
| Key Derivation Function        | AES_CM_PRF [RFC3711]         |
| Maximum key lifetime (SRTP)    | 2^48 packets                 |
| Maximum key lifetime (SRTCP)   | 2^31 packets                 |
| Cipher (for SRTP and SRTCP)    | AEAD_AES_128_GCM             |
| AEAD authentication tag length | 128 bits                     |
+--------------------------------+------------------------------+
            Table 3: The AEAD_AES_128_GCM Crypto Suite
 
+--------------------------------+------------------------------+
| Parameter                      | Value                        |
+--------------------------------+------------------------------+
| Master key length              | 256 bits                     |
| Master salt length             | 96 bits                      |
| Key Derivation Function        | AES_256_CM_PRF [RFC6188]     |
| Maximum key lifetime (SRTP)    | 2^48 packets                 |
| Maximum key lifetime (SRTCP)   | 2^31 packets                 |
| Cipher (for SRTP and SRTCP)    | AEAD_AES_256_GCM             |
| AEAD authentication tag length | 128 bits                     |
+--------------------------------+------------------------------+
            Table 4: The AEAD_AES_256_GCM Crypto Suite

AES-CCM for SRTP/SRTCP

AES-CCM is another family of AEAD algorithms built around the AES block cipher algorithm. AES-CCM uses AES counter mode for encryption and AES Cipher Block Chaining Message Authentication Code (CBC-MAC) for authentication. A detailed description of the AES-CCM family can be found in [RFC5116]. Four of the six CCM algorithms used in this document are defined in previous RFCs, while two, AEAD_AES_128_CCM_12 and AEAD_AES_256_CCM_12, are defined in section 7 of this document.

Any implementation of AES-CCM SRTP/SRTCP MUST support both AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet AEAD authentication tags), and MAY support the other four variants.

 Name                 Key Size    AEAD Tag Size    Reference
================================================================
 AEAD_AES_128_CCM     128 bits    16 octets        [RFC5116]
 AEAD_AES_256_CCM     256 bits    16 octets        [RFC5116]
 AEAD_AES_128_CCM_12  128 bits    12 octets        see section 7
 AEAD_AES_256_CCM_12  256 bits    12 octets        see section 7
 AEAD_AES_128_CCM_8   128 bits     8 octets        [RFC6655]
 AEAD_AES_256_CCM_8   256 bits     8 octets        [RFC6655]
 
         Table 6: AES-CCM algorithms for SRTP/SRTCP

In addition to the flag octet used in counter mode encryption, AES-CCM authentications also uses a flag octet that conveys information about the length of the authentication tag, length of the block counter, and presence of additional authenticated data (see section 2.2 of [RFC3610]). For AES-CCM in SRTP/SRTCP, the flag octet has the hex value 5A if an 8-octet AEAD authentication tag is used, 6A if a 12-octet AEAD authentication tag is used, and 7A if a 16-octet AEAD authentication tag is used. The flag octet is one of the inputs to AES during the counter mode encryption of the plaintext.

+--------------------------------+------------------------------+
| Parameter                      | Value                        |     
+--------------------------------+------------------------------+
| Master key length              | 128 bits                     |
| Master salt length             | 96 bits                      |
| Key Derivation Function        | AES_CM_PRF [RFC3711]         |
| Maximum key lifetime (SRTP)    | 2^48 packets                 |
| Maximum key lifetime (SRTCP)   | 2^31 packets                 |
| Cipher (for SRTP and SRTCP)    | AEAD_AES_128_CCM_8           |
| AEAD authentication tag length | 64 bits                      |     
+--------------------------------+------------------------------+
 
           Table 7: The AEAD_AES_128_CCM_8 Crypto Suite
 
 
+--------------------------------+------------------------------+
| Parameter                      | Value                        |     
+--------------------------------+------------------------------+
| Master key length              | 128 bits                     |
| Master salt length             | 96 bits                      |
| Key Derivation Function        | AES_CM_PRF [RFC3711]         |
| Maximum key lifetime (SRTP)    | 2^48 packets                 |
| Maximum key lifetime (SRTCP)   | 2^31 packets                 |
| Cipher (for SRTP and SRTCP)    | AEAD_AES_128_CCM_12          |
| AEAD authentication tag length | 96 bits                      |     
+--------------------------------+------------------------------+
 
           Table 8: The AEAD_AES_128_CCM_12 Crypto Suite
 
 
+--------------------------------+------------------------------+
| Parameter                      | Value                        |     
+--------------------------------+------------------------------+
| Master key length              | 128 bits                     |
| Master salt length             | 96 bits                      |
| Key Derivation Function        | AES_CM_PRF [RFC3711]         |
| Maximum key lifetime (SRTP)    | 2^48 packets                 |
| Maximum key lifetime (SRTCP)   | 2^31 packets                 |
| Cipher (for SRTP and SRTCP)    | AEAD_AES_128_CCM             |
| AEAD authentication tag length | 128 bits                     |     
+--------------------------------+------------------------------+
 
            Table 9: The AEAD_AES_128_CCM Crypto Suite
 
 
+--------------------------------+------------------------------+
| Parameter                      | Value                        |     
+--------------------------------+------------------------------+
| Master key length              | 256 bits                     |
| Master salt length             | 96 bits                      |
| Key Derivation Function        | AES_256_CM_PRF [RFC6188]     |
| Maximum key lifetime (SRTP)    | 2^48 packets                 |
| Maximum key lifetime (SRTCP)   | 2^31 packets                 |
| Cipher (for SRTP and SRTCP)    | AEAD_AES_256_CCM_8           |
| AEAD authentication tag length | 64 bits                      |     
+--------------------------------+------------------------------+
 
         Table 10: The AEAD_AES_256_CCM_8 Crypto Suite
 
 
+--------------------------------+------------------------------+
| Parameter                      | Value                        |     
+--------------------------------+------------------------------+
| Master key length              | 256 bits                     |
| Master salt length             | 96 bits                      |
| Key Derivation Function        | AES_256_CM_PRF [RFC6188]     |
| Maximum key lifetime (SRTP)    | 2^48 packets                 |
| Maximum key lifetime (SRTCP)   | 2^31 packets                 |
| Cipher (for SRTP and SRTCP)    | AEAD_AES_256_CCM_12          |
| AEAD authentication tag length | 96 bits                      |     
+--------------------------------+------------------------------+
 
          Table 11: The AEAD_AES_256_CCM_12 Crypto Suite
 
 
+--------------------------------+------------------------------+
| Parameter                      | Value                        |     
+--------------------------------+------------------------------+
| Master key length              | 256 bits                     |
| Master salt length             | 96 bits                      |
| Key Derivation Function        | AES_256_CM_PRF [RFC6188]     |
| Maximum key lifetime (SRTP)    | 2^48 packets                 |
| Maximum key lifetime (SRTCP)   | 2^31 packets                 |
| Cipher (for SRTP and SRTCP)    | AEAD_AES_256_CCM             |
| AEAD authentication tag length | 128 bits                     |     
+--------------------------------+------------------------------+
 
           Table 12: The AEAD_AES_256_CCM Crypto Suite

Use of the ARIA Block cipher with SRTP

ARIA is a general-purpose block cipher algorithm developed by Korean cryptographers in 2003. It is an iterated block cipher with 128-, 192-, and 256-bit keys and encrypts 128-bit blocks in 12, 14, and 16 rounds, depending on the key size. It is secure and suitable for most software and hardware implementations on 32-bit and 8-bit processors. It was established as a Korean standard block cipher algorithm in 2004 [ARIAKS] and has been widely used in Korea, especially for government-to-public services. It was included in PKCS #11 in 2007 [ARIAPKCS]. The algorithm specification and object identifiers are described in [RFC5794].

ARIA-CTR

Section 4.1.1 of [RFC3711] defines AES-128 counter mode encryption, which it refers to as "AES_CM". Section 2 of [RFC6188] defines "AES_192_CM" and "AES_256_CM" in SRTP. ARIA counter modes are defined in the same manner except that each invocation of AES is replaced by that of ARIA [RFC5794], and are denoted by ARIA_128_CTR, ARIA_192_CTR and ARIA_256_CTR respectively, according to the key lengths. The plaintext inputs to the block cipher are formed as in AES-CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs are processed as in AES-CTR. Note that, ARIA-CTR MUST be used only in conjunction with an authentication transform.

Section 3.2 of [RFC6904] defines AES-CTR for SRTP header extension keystream generation. When ARIA-CTR is used, the header extension keystream SHALL be generated in the same manner except that each invocation of AES is replaced by that of ARIA [RFC5794].

ARIA-GCM

GCM (Galois Counter Mode) [GCM][RFC5116] is an AEAD (Authenticated Encryption with Associated Data) block cipher mode. A detailed description of ARIA-GCM is defined similarly as AES-GCM found in [RFC5116][RFC5282].

The document [I-D.ietf-avtcore-srtp-aes-gcm] describes the use of AES-GCM with SRTP [RFC3711][RFC6904]. The use of ARIA-GCM with SRTP is defined the same as that of AES-GCM except that each invocation of AES is replaced by ARIA [RFC5794]. When [RFC6904] is in use, a separate keystream to encrypt selected RTP header extension elements MUST be generated in the same manner defined in [I-D.ietf-avtcore-srtp-aes-gcm] except that AES-CTR is replaced by ARIA-CTR.

Protection Profiles

This section defines SRTP Protection Profiles that use the ARIA transforms and key derivation functions defined in this document. The following list indicates the SRTP transform parameters for each protection profile. Those are described for use with DTLS-SRTP [RFC5764].

The parameters cipher_key_length, cipher_salt_length, auth_key_length, and auth_tag_length express the number of bits in the values to which they refer. The maximum_lifetime parameter indicates the maximum number of packets that can be protected with each single set of keys when the parameter profile is in use. All of these parameters apply to both RTP and RTCP, unless the RTCP parameters are separately specified.

SRTP_ARIA_128_CTR_HMAC_SHA1_80

cipher: ARIA_128_CTR
cipher_key_length: 128 bits
cipher_salt_length: 112 bits
key derivation function: ARIA_128_CTR_PRF
auth_function: HMAC-SHA1
auth_key_length: 160 bits
auth_tag_length: 80 bits
maximum_lifetime: at most ${2}^{31}$ SRTCP packets and at most ${2}^{48}$ SRTP packets

SRTP_ARIA_128_CTR_HMAC_SHA1_32

cipher: ARIA_128_CTR
cipher_key_length: 128 bits
cipher_salt_length: 112 bits
key derivation function: ARIA_128_CTR_PRF
auth_function: HMAC-SHA1
auth_key_length: 160 bits
SRTP auth_tag_length: 32 bits
SRTCP auth_tag_length: 80 bits
maximum_lifetime: at most ${2}^{31}$ SRTCP packets and at most ${2}^{48}$ SRTP packets

SRTP_ARIA_192_CTR_HMAC_SHA1_80

cipher: ARIA_192_CTR
cipher_key_length: 192 bits
cipher_salt_length: 112 bits
key derivation function: ARIA_192_CTR_PRF
auth_function: HMAC-SHA1
auth_key_length: 160 bits
auth_tag_length: 80 bits
maximum_lifetime: at most ${2}^{31}$ SRTCP packets and at most ${2}^{48}$ SRTP packets

SRTP_ARIA_192_CTR_HMAC_SHA1_32

cipher: ARIA_192_CTR
cipher_key_length: 192 bits
cipher_salt_length: 112 bits
key derivation function: ARIA_192_CTR_PRF
auth_function: HMAC-SHA1
auth_key_length: 160 bits
SRTP auth_tag_length: 32 bits
SRTCP auth_tag_length: 80 bits
maximum_lifetime: at most ${2}^{31}$ SRTCP packets and at most ${2}^{48}$ SRTP packets

SRTP_ARIA_256_CTR_HMAC_SHA1_80

cipher: ARIA_256_CTR
cipher_key_length: 256 bits
cipher_salt_length: 112 bits
key derivation function: ARIA_256_CTR_PRF
auth_function: HMAC-SHA1
auth_key_length: 160 bits
auth_tag_length: 80 bits
maximum_lifetime: at most ${2}^{31}$ SRTCP packets and at most ${2}^{48}$ SRTP packets

SRTP_ARIA_256_CTR_HMAC_SHA1_32

cipher: ARIA_256_CTR
cipher_key_length: 256 bits
cipher_salt_length: 112 bits
key derivation function: ARIA_256_CTR_PRF
auth_function: HMAC-SHA1
auth_key_length: 160 bits
SRTP auth_tag_length: 32 bits
SRTCP auth_tag_length: 80 bits
maximum_lifetime: at most ${2}^{31}$ SRTCP packets and at most ${2}^{48}$ SRTP packets

SRTP_AEAD_ARIA_128_GCM

cipher: ARIA_128_GCM
cipher_key_length: 128 bits
cipher_salt_length: 96 bits
aead_auth_tag_length: 128 bits
auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
key derivation function: ARIA_128_CTR_PRF
maximum_lifetime: at most ${2}^{31}$ SRTCP packets and at most ${2}^{48}$ SRTP packets

SRTP_AEAD_ARIA_256_GCM

cipher: ARIA_256_GCM
cipher_key_length: 256 bits
cipher_salt_length: 96 bits
aead_auth_tag_length: 128 bits
auth_function: NULL
auth_key_length: N/A
auth_tag_length: N/A
key derivation function: ARIA_256_CTR_PRF
maximum_lifetime: at most ${2}^{31}$ SRTCP packets and at most ${2}^{48}$ SRTP packets

The ARIA-CTR protection profiles use the same authentication transform that is mandatory to implement in SRTP, HMAC-SHA1 with a 160-bit key.

Note that SRTP Protection Profiles which use AEAD algorithms do not specify an auth_function, auth_key_length, or auth_tag_length, since they do not use a separate auth_function, auth_key, or auth_tag. The term aead_auth_tag_length is used to emphasize that this refers to the authentication tag provided by the AEAD algorithm and that this tag is not located in the authentication tag field provided by SRTP/SRTCP.

[1] http://blog.csdn.net/fanbird2008/article/details/18623141

For API Documentation:

See also: ProtoocolPP::jprotocol; ProtoocolPP::jsrtp; ProtoocolPP::jsrtpsa; ProtoocolPP::jarray; ProtoocolPP::jrand

For Additional Documentation:

See also: jprotocol; jsrtp; jsrtpsa; jarray; jrand

The source code contained or described herein and all documents related to the source code (herein called "Material") are owned by John Peter Greninger and Sheila Rocha Greninger. Title to the Material remains with John Peter Greninger and Sheila Rocha Greninger. The Material contains trade secrets and proprietary and confidential information of John Peter Greninger and Sheila Rocha Greninger. The Material is protected by worldwide copyright and trade secret laws and treaty provisions. No part of the Material may be used, copied, reproduced, modified, published, uploaded, posted, transmitted, distributed, or disclosed in any way without prior express written consent of John Peter Greninger and Sheila Rocha Greninger (both are required)

No license under any patent, copyright, trade secret, or other intellectual property right is granted to or conferred upon you by disclosure or delivery of the Materials, either expressly, by implication, inducement, estoppel, or otherwise. Any license under such intellectual property rights must be express and approved by John Peter Greninger and Sheila Rocha Greninger in writing

Licensing information can be found at www.protocolpp.com/license with use of the binary forms permitted provided that the following conditions are met:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution
Any and all modifications must be returned to John Peter Greninger at GitHub.com https://github.com/jpgreninger/protocolpp for evaluation. Inclusion of modifications in the source code shall be determined solely by John Peter Greninger. Failure to provide modifications shall render this license NULL and VOID and revoke any rights to use of Protocol++®
Commercial use (incidental or not) requires a fee-based license obtainable at www.protocolpp.com/shop
Academic or research use requires prior written and notarized permission from John Peter and Sheila Rocha Greninger

Use of the source code requires purchase of the source code. Source code can be purchased at www.protocolpp.com/shop

US Copyrights at https://www.copyright.gov/
- TXu002059872 (Version 1.0.0)
- TXu002066632 (Version 1.2.7)
- TXu002082674 (Version 1.4.0)
- TXu002097880 (Version 2.0.0)
- TXu002169236 (Version 3.0.1)
- TXu002182417 (Version 4.0.0)
- TXu002219402 (Version 5.0.0)
- TXu002272076 (Version 5.2.1)
- TXu002383571 (Version 5.4.3)

The name of its contributor may not be used to endorse or promote products derived from this software without specific prior written permission and licensing

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

The documentation for this class was generated from the following file:

include/jsrtp.h