skip to content

Why is keying SRTP with SDES a=crypto lines considered unsafe, and how does DTLS-SRTP avoid the same weakness?

level: middleimportance: must knowfreq 28%

answer

  1. where does the key travel
  2. every signalling hop can read it
  3. logs, traces and recordings
  4. integrity versus confidentiality of SDP

basics

~20 s

SDES puts each sender's SRTP master key in the SDP, so every proxy, log or trace that reads the signalling can decrypt the media. DTLS-SRTP derives keys in a handshake on the media path; signalling carries only a certificate fingerprint.

solid answer

~40 s

SDES (RFC 4568) writes the master key and salt into the SDP as `a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<base64 key||salt>`, each endpoint sending the key it will transmit with. The media is then only as safe as the signalling path: every SIP proxy that terminates hop-by-hop TLS, every trace and every log holding that SDP holds the key. RFC 4568 therefore requires the SDP to be encrypted and authenticated, ideally end to end with S/MIME, which deployments rarely do. There is no forward secrecy either: a logged SDP later decrypts a recorded call. DTLS-SRTP (RFC 5764 with RFC 5763) moves key agreement onto the media path; the signalling carries only `a=fingerprint`, so it needs integrity, not confidentiality, and ephemeral Diffie-Hellman suites give forward secrecy. RFC 8827 forbids WebRTC endpoints from offering or accepting SDES.

go deeper

for a junior

Know the one-line contrast: SDES puts the media key in the signalling, DTLS-SRTP agrees it on the media path and signals only a fingerprint.

for a middle

Explain the a=crypto line, why each proxy and log that reads the SDP holds the key, and why DTLS-SRTP needs signalling integrity but not confidentiality.

for a senior

Bring the operational exposure: hop-by-hop TLS still leaves keys at every proxy, traces leak them, and SDES has no forward secrecy, so a logged SDP decrypts a recording.

for a principal

Frame it as a trust-boundary decision: how many elements must be trusted with media keys under each scheme, and when SDES on a trunk is an acceptable, contained risk.

## Two ways to get an SRTP master key to the peer SRTP itself has no key exchange. RFC 3711 leaves key management to another protocol and only defines how a **master key** and **master salt** are expanded into the keys that protect packets. In practice two mechanisms deliver that master key: - **SDES** (SDP Security Descriptions, RFC 4568) carries it inside the session description. - **DTLS-SRTP** (RFC 5764, signalled per RFC 5763) derives it in a DTLS handshake run between the media endpoints. A SIP trunk between two carriers is the place SDES is still most often found; a WebRTC call is always DTLS-SRTP. ## What an a=crypto line carries An SDES offer has one or more media-level lines of the form `a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]`, for example: ``` a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<base64 of master key || master salt>|2^20|1:4 ``` - The **tag** identifies the line so the answer can accept exactly one. - The **crypto-suite** names the transform. - `inline:` holds the master key concatenated with the master salt, base64-encoded, optionally followed by a key lifetime and an MKI with its length. - Optional session parameters such as `KDR=` or `UNENCRYPTED_SRTP` adjust the SRTP context. Each endpoint sends **its own transmit key**: the offerer's line keys what the offerer sends, and the answer carries the key the answerer will use. Base64 is an encoding, not protection; anyone who reads the line has the key. ## Why the key's safety equals the signalling path's RFC 4568 is blunt: SDP has no authenticated key exchange, so the descriptions are suitable only where the SDP itself is protected. It requires authentication of any message carrying `a=crypto`, and encryption of it whenever an `inline` key is present. Every element that can read or change the SDP therefore matters: 1. **Each SIP proxy.** Hop-by-hop TLS protects each link, but every proxy that terminates TLS sees the key in clear. RFC 4568 recommends S/MIME end to end for SDP that intermediaries process, because transport security that ends at each hop cannot protect the key through them. 2. **Logs and traces.** Signalling traces, debug logs and monitoring systems routinely store SIP bodies, and with them the keys. 3. **Every forked branch.** RFC 4568 notes that all user agents that received a forked offer know the key it proposed. 4. **An attacker who can modify the SDP.** Without integrity protection a modified offer can substitute keys or add `UNENCRYPTED_SRTP`, so the answerer stops decrypting or even sends in clear. RFC 8826 adds the retrospective case. If the calling service ever holds the traffic key, as with SDES, someone who later obtains a stored SDP and a recording of the media decrypts the call. That is the absence of **forward secrecy**, and rotating keys after the call does not help once the old key sits in a log. ## How DTLS-SRTP changes the requirement | | SDES | DTLS-SRTP | |---|---|---| | Where the master key comes from | written in the SDP by each sender | exported from a DTLS handshake on the media path | | What the SDP carries | the key itself | a certificate fingerprint | | What the signalling must provide | confidentiality and integrity | integrity | | Who can decrypt with signalling access alone | anyone who reads the SDP | nobody; they must also attack the media path | | Forward secrecy | none | with ephemeral Diffie-Hellman cipher suites | | WebRTC status (RFC 8827) | must not be offered or accepted | mandatory | RFC 5763 states the gain directly: because DTLS-SRTP needs only message integrity from the signalling, far fewer elements have to be trusted, whereas SDES needs confidentiality and so every intermediate element must be trusted. An attacker who changes the fingerprint can still interpose, which is why the fingerprint's integrity becomes the thing to protect. ## What an operator does when SDES is unavoidable - Demand protected signalling on every hop to the peer and treat each proxy as holding the key. - Keep `a=crypto` lines out of logs, traces and support tickets, or redact the `inline:` value. - Use a fresh random master key per call; RFC 4568 requires each key to be unique within the SDP. - Refuse answers that downgrade to unencrypted SRTP or plain RTP rather than accept them. - Prefer DTLS-SRTP on any trunk whose peer supports it; RFC 5763 defines it for SIP.

  • If every SIP hop on an SDES trunk uses TLS, is the SRTP key then safe?
    Only against eavesdroppers on the links between hops. Each proxy that terminates TLS reads the SDP and the key in clear, and whatever it logs keeps the key. RFC 4568 therefore recommends end-to-end S/MIME for SDP that intermediaries process. Even then there is no forward secrecy: a stored SDP plus a stored recording decrypts the call.
  • Does DTLS-SRTP need the signalling to be encrypted?
    No. The SDP carries only certificate fingerprints, which are public, so the signalling needs integrity rather than confidentiality. If the SDP can be modified, though, an attacker who also controls the media path can substitute its own fingerprint and sit in the middle, so integrity of the signalling remains essential.
  • What can an attacker who can modify an unauthenticated SDES offer do without reading the media?
    RFC 4568 warns of denial of service and worse: replacing keys breaks the call, and adding UNENCRYPTED_SRTP can make the answerer skip decryption or send its own media unencrypted. The defender's control is authenticated signalling, plus a policy that rejects unencrypted answers.

saying these in an interview costs you the question

  • SDES is safe because the SRTP key in the SDP is base64-encoded.
  • TLS on the first hop to the SIP proxy fully protects SDES keys.
  • DTLS-SRTP carries the SRTP master key inside the SDP fingerprint.
  • Since DTLS-SRTP keys are made on the media path, signalling integrity no longer matters.
  • Logging SDES SDP bodies is harmless if keys are rotated after each call.