skip to content

In SRTP, how does the AES-CM key derivation turn one master key and master salt into separate session keys?

level: middleimportance: nice to knowfreq 8%

answer

  1. one master, many session keys
  2. an 8-bit label per key type
  3. index DIV key_derivation_rate
  4. XOR with the master salt

basics

~20 s

SRTP runs AES in counter mode, keyed by the master key, over a one-byte label plus the packet index divided by the key derivation rate, XORed with the master salt. Labels 0x00 to 0x05 yield SRTP and SRTCP encryption, authentication and salting keys.

solid answer

~50 s

RFC 3711 section 4.3 defines it. For each key it builds `key_id = label || r`, where `r = index DIV key_derivation_rate` (and anything DIV 0 is 0), XORs `key_id` right-aligned with the master salt to get `x`, and takes the first n bits of AES counter mode keyed with the master key, starting from `x * 2^16`. Labels `0x00`, `0x01` and `0x02` give SRTP's encryption key, authentication key and salting key; `0x03` to `0x05` give the same three for SRTCP, whose input index is `0 || SRTCP index`. The default key derivation rate is 0, so derivation runs once before the first packet; DTLS-SRTP profiles fix it at 0, and SDES can set `KDR=n` for 2^n. Separate labels are what let SRTP and SRTCP share one master key and the same SSRC without reusing a keystream.

go deeper

for a junior

Recall that key management delivers a master key and SRTP derives separate encryption, authentication and salting keys from it before the first packet.

for a middle

Explain the inputs: label, packet index divided by the derivation rate, XOR with the master salt, AES-CM under the master key, and the six labels.

for a senior

Show judgement about the derivation rate: zero by default and in DTLS-SRTP, never a way to stretch a master key's packet limit, and costly when many streams share a key.

for a principal

Reason about what the derivation buys a platform: one key management run serving SRTP and SRTCP safely, with key lifetime still governed by packet indices and re-keying policy.

## Master key versus session keys Key management, whether a DTLS-SRTP handshake or an SDES `a=crypto` line, delivers a **master key** and usually a **master salt**. SRTP never protects a packet with the master key directly. RFC 3711 requires every interoperable implementation to run the **SRTP key derivation** to produce **session keys**: - an **encryption key** for the cipher; - an **authentication key** for the message authentication code; - a **salting key** mixed into the cipher's initialisation vector. SRTCP, the protected form of RTCP, gets its own three. RFC 3711 makes the first derivation mandatory and runs it before the first packet. ## The derivation step by step The default pseudo-random function is **AES in counter mode** (AES-CM), keyed by the master key. For every key it needs, SRTP: 1. computes `r = index DIV key_derivation_rate`, where `index` is the 48-bit SRTP packet index (rollover counter and sequence number) and `a DIV 0` is defined as 0; 2. forms `key_id = label || r`, an 8-bit label followed by `r`; 3. computes `x = key_id XOR master_salt`, aligning the two on their least significant bits; 4. runs AES-CM under the master key with the counter block starting at `x * 2^16`, and keeps the first n bits of keystream, n being the length of the key wanted. ```pseudocode function derive(master_key, master_salt, label, index, kdr, n): r = (kdr == 0) ? 0 : floor(index / kdr) key_id = label || r // 8-bit label, then r x = key_id XOR master_salt // right-aligned iv = x * 2^16 return leftmost n bits of AES_CM(master_key, iv) ``` ## The labels | Label | Session key | Stream | |---|---|---| | `0x00` | encryption key | SRTP | | `0x01` | authentication key | SRTP | | `0x02` | salting key | SRTP | | `0x03` | encryption key | SRTCP | | `0x04` | authentication key | SRTCP | | `0x05` | salting key | SRTCP | Values `0x06` to `0xff` are left for future extensions. For SRTCP, RFC 3711 replaces the SRTP index with the 32-bit quantity `0 || SRTCP index`, a fixed zero bit in place of the E flag. The output length is set by the cryptographic context rather than by the master key. With the default transform, a 128-bit master key yields a 160-bit authentication key, but RFC 3711 points out that the effective strength never exceeds the master key's. ## Why the separation matters - **SRTP and SRTCP may share a master key.** An SRTP stream and its SRTCP stream carry the same SSRC. RFC 3711 says that is not a two-time-pad risk because the key derivation gives them different session keys. - **Cipher and MAC keys stay independent.** The encryption key and the authentication key come from different labels, so neither reveals the other; the general argument for key separation belongs to cryptographic foundations. - **The salt raises the cost of precomputation.** RFC 3711 section 9.2 explains that the salt defends against key-collision and time-memory trade-off attacks. It **must be random but may be public**. ## The key derivation rate The `key_derivation_rate` is 0 or a power of two from 1 to 2^24, and must stay fixed for the life of a master key. - **0, the default:** derivation happens exactly once. - **Non-zero:** session keys are re-derived whenever the packet index is a multiple of the rate. A rate of 2^16 gives new session keys every 65,536 packets, about every 1,311 seconds (roughly 22 minutes) for a 50-packet-per-second voice stream. How each keying method sets it: - **DTLS-SRTP:** RFC 5764 fixes it at zero for its profiles. - **SDES:** the `KDR=n` session parameter declares a rate of 2^n for n from 1 to 24; omitting it means a single derivation. A non-zero rate limits how much traffic any one session key protects, but RFC 3711 is clear that it **does not extend the master key's lifetime**: two packets must differ in IV or in session key, and both depend on distinct packet indices. RFC 3711 also advises against a non-zero rate when many streams share a key, because endpoints would have to hold more session keys at once.

  • Does a non-zero SRTP key derivation rate let one master key protect more packets?
    No. RFC 3711 section 9.2 says key derivation limits the plaintext under a fixed session key but does not extend the master key's lifetime. Avoiding keystream reuse needs distinct IVs or distinct session keys, and both come from distinct packet indices, so the 2^48 SRTP and 2^31 SRTCP limits per master key still apply.
  • Why can SRTP and SRTCP share one master key when both carry the same SSRC?
    Because the key derivation uses different labels, 0x00 to 0x02 for SRTP and 0x03 to 0x05 for SRTCP, the two streams get different session keys. The same SSRC and overlapping index values therefore never produce the same keystream, which RFC 3711 section 8 states explicitly.

saying these in an interview costs you the question

  • SRTP encrypts each packet directly with the master key from key management.
  • The SRTP master salt must be kept as secret as the master key.
  • By default SRTP re-derives its session keys every 2^16 packets.
  • A non-zero key derivation rate extends how many packets a master key may protect.
  • SRTCP uses exactly the same session keys as SRTP because it shares the master key.