In SRTP, why does encrypting the RTP payload not stop an attacker from replaying recorded video packets or flipping bits in them?
answer
- confidentiality is not integrity
- counter mode: flipped bit, flipped bit
- a recorded packet decrypts fine twice
- tag over header, payload and ROC
- replay list over the 48-bit index
basics
~20 sEncryption hides content but never fails: flipped bits in SRTP counter-mode ciphertext decrypt to the same flipped plaintext bits, and a recorded packet decrypts fine when re-sent. SRTP adds an authentication tag and a replay list to catch both.
solid answer
~50 sSRTP's default cipher, AES in counter mode, XORs a keystream onto the payload, so decryption accepts anything: flip a ciphertext bit and the same plaintext bit flips, and a packet recorded earlier decrypts exactly as it did the first time. RFC 3711 closes both gaps at the receiver. An **authentication tag** (HMAC-SHA1, 80 bits by default) covers the RTP header, the encrypted payload and the rollover counter, so an edited packet fails verification. A **replay list**, in practice a sliding window of at least 64 packet indices, remembers which 48-bit indices were already accepted, so a genuine packet sent a second time is refused. The two depend on each other: without the tag an attacker could rewrite a replayed packet's sequence number, which is why RFC 3711 says secure replay protection is only possible with integrity protection. Either failure means the packet is discarded and the event logged.
go deeper
Recall that SRTP gives three things, not one: confidentiality, integrity and replay protection. Be ready to say that encryption alone lets a recorded packet be re-sent and lets bits be flipped unnoticed.
Explain the mechanics: counter mode XORs a keystream, so a flipped ciphertext bit flips the same plaintext bit; the tag covers header, ciphertext and ROC; the replay list remembers accepted 48-bit indices.
Show why each check needs the other: a replayed packet carries a genuine tag, and without a tag the sequence number can be rewritten. Tie it to when null or weak authentication is acceptable at all.
Frame it as a risk decision: RFC 3711 permits weak or null authentication only under narrow conditions. Be able to argue which media, such as surveillance or anything driving decisions, rules that out entirely.
## What encryption gives SRTP, and what it does not **SRTP** (Secure Real-time Transport Protocol, RFC 3711) protects RTP media. Its default cipher is **AES in counter mode** (AES-CM): the sender generates a keystream from the session key, the stream's SSRC and the packet index, and XORs it onto the RTP payload. The receiver regenerates the same keystream and XORs it off. That gives **confidentiality**: someone on the path cannot read the video. It gives nothing else. RFC 3711 says so directly: encryption algorithms, including AES counter mode, do not provide message authentication. Decryption with an additive stream cipher never "fails" — it always produces *some* plaintext. Two consequences follow, and both matter on a video stream: - **Bit flipping.** If an attacker flips bit *n* of the ciphertext, bit *n* of the decrypted payload flips. The receiver has no way to notice from decryption alone. - **Replay.** A packet captured earlier is a perfectly valid ciphertext. Re-sent later, it decrypts to exactly the frame it carried the first time. RFC 3711's own example of a replay that matters is a surveillance camera: store its output for a while, then inject it towards the monitoring station so that the station shows a quiet corridor. Encryption does not stop it. ## Two attacks on one stream, and what catches each | Attack on an SRTP video stream | What decryption does | What the receiver uses to catch it | |---|---|---| | Re-send a captured burst of genuine packets | Decrypts them perfectly | The **replay list**: those indices were already accepted | | Flip bits in another packet's payload or header | Produces altered plaintext, silently | The **authentication tag**: recomputed tag does not match | | Edit a replayed packet's sequence number so it looks new | Decrypts to noise, since the keystream depends on the index, and flags nothing | The **authentication tag**: the header is authenticated | ## The authentication tag The tag is the one SRTP field (besides the optional MKI) that plain RTP does not have. For SRTP the tag is computed over the **Authenticated Portion** — the RTP header followed by the encrypted payload — concatenated with the **rollover counter** (ROC), the 32-bit count of sequence-number wraps that both ends keep but never send. The default transform is HMAC-SHA1 with an 80-bit tag; which algorithm and length a session actually uses is chosen by its protection profile. The receiver recomputes the tag over what arrived and compares. Any change to the header, the ciphertext or the implied ROC changes the tag, so the packet is rejected. Note what is *not* encrypted: the RTP header, including the sequence number, travels in clear. It is protected against change, not against reading. ## The replay list Every SRTP packet has a **48-bit index**: `i = 2^16 × ROC + SEQ`, where SEQ is the 16-bit RTP sequence number. The receiver keeps a **replay list** of indices it has already received and authenticated. Conceptually it holds every index; in practice RFC 3711 allows a **sliding window**: indices more than `SRTP-WINDOW-SIZE` behind the highest one are simply assumed received. The window size is a receiver-side choice that MUST be at least 64. A captured burst re-sent a second later carries indices the receiver has already marked, so each one is refused. A burst re-sent much later carries indices that have fallen behind the window, so those are refused too. ## Why the two need each other 1. **Tag without replay list:** a re-sent packet carries the *genuine* tag the sender computed, so the tag check passes. Integrity alone does not stop replay — RFC 3711 says exactly that. 2. **Replay list without tag:** the attacker rewrites the sequence number of a recorded packet so its index lands ahead of the window, and the receiver accepts it. Hence RFC 3711: secure replay protection is only possible when integrity protection is present, and the tag "indirectly provides replay protection by authenticating the sequence number". 3. **Together:** the tag pins the index to the packet, and the replay list refuses any index seen before. Including the ROC in the tag input closes one more gap: a packet recorded in one cycle of the 16-bit sequence space cannot be passed off as the packet with the same SEQ 65,536 packets later, because the receiver would compute the tag with a different ROC. ## What happens on failure A packet that fails either check MUST be discarded, and the event SHOULD be logged. Nothing is sent back to the sender; SRTP defines no error message for it. RFC 3711 allows SRTP without authentication only where both of its conditions hold, and says null authentication MUST NOT be used where a replay could have a non-negligible impact — the camera case is exactly that.
- If an SRTP session runs with null authentication, does the replay window still protect the stream?No. RFC 3711 says secure replay protection is only possible when integrity protection is present. Without a tag, an attacker can rewrite a recorded packet's sequence number so its index lands ahead of the window, and the receiver cannot tell. RFC 3711 also says null authentication MUST NOT be used where a replay could have a non-negligible impact, such as re-injected surveillance-camera output.
- Why does the SRTP authentication tag cover the rollover counter, which is never sent on the wire?For SRTP the tag input is the Authenticated Portion concatenated with the ROC. That binds the tag to the full 48-bit index rather than the 16-bit sequence number, so a packet recorded in one sequence-number cycle cannot be replayed as the packet with the same SEQ one wrap later: the receiver would compute the tag with the next ROC and it would not match. The price is that a receiver holding the wrong ROC fails every tag.
saying these in an interview costs you the question
- Encryption already stops tampering, because the attacker cannot read what they change.
- A tampered SRTP packet fails to decrypt, so no separate integrity check is needed.
- The tag check alone stops replays, because a re-sent packet must carry a forged tag.
- The replay window works without authentication, since it only looks at sequence numbers.
- SRTP encrypts the RTP header, so the sequence number cannot be read or changed.