A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)
Extracted elements (31)
All endpoints in a conference share the same SRTP master salt (transmitted with the EKT Key), but each endpoint generates its own distinct SRTP master key for E2E encryption. Only the SRTP master key (not the salt) is conveyed to other endpoints via the Full EKT Tag, reducing the data that must be distributed per-rekeying event.
PERC defines two security contexts — an 'inner' E2E key per transmitted media flow for authenticated encryption between endpoints, and an 'outer' HBH key known only to adjacent Media Distributors or endpoints for each hop. This dual-key design allows Media Distributors to modify certain RTP headers and process RTCP without ever having access to plaintext media content.
RTCP is encrypted only hop by hop, not end to end. This deliberately gives the Media Distributor the flexibility to forward RTCP content unchanged, transmit compound RTCP packets, initiate RTCP reporting, or convey other information. As a consequence, endpoints MUST NOT send confidential information via RTCP.
The KEK (EKT Key) is never given to the Media Distributor. Even the Key Distributor is unaware of locally generated E2E keys used by each endpoint after the endpoint optionally discards the DTLS-SRTP-derived E2E key. This two-layer approach ensures that neither the MD nor the KD can decrypt media once an endpoint generates a fresh E2E key.
The term 'untrusted' for Media Distributors and Call Processing does not mean those entities are expected to malfunction; it means only that they do not have access to E2E media encryption keys. This distinction is intentional so that conferencing infrastructure can be hosted in cloud environments without compromising media privacy.
In the context of WebRTC, where control is split between a JavaScript application and a browser, the browser acts as the Trusted Endpoint for PERC purposes, just as it acts as the endpoint for DTLS-SRTP in one-to-one calls. This maps PERC's trust model onto the existing WebRTC security architecture.
When RTP header extensions are encrypted HBH per RFC 6904, all hops — including Media Distributors — must decrypt and re-encrypt these header extensions. This is required to give the Media Distributor visibility into extensions such as the audio-level indicator (RFC 6464) while preserving HBH confidentiality.
An endpoint MUST generate a new E2E encryption key whenever it receives a new EKT Key, ensuring that media encrypted under a new KEK epoch uses a fresh SRTP master key.
An endpoint MUST maintain a list of SSRCs from received RTP flows and each SSRC's associated E2E key information, and MUST discard old E2E keys no later than when it leaves the conference.
E2E replay protection MUST be provided for the duration of the conference, mitigating attacks where a Media Distributor retransmits previously captured packets.
Endpoints MUST either use the DTLS-SRTP-generated E2E key for transmission or generate a fresh E2E key; neither option allows the endpoint to skip the E2E key establishment step.
Endpoints MUST NOT send confidential information via RTCP, because RTCP is only encrypted hop by hop in PERC and a compromised Media Distributor can read or modify RTCP content.
Endpoints MUST NOT transmit confidential information via RTP header extensions, because those extensions are only encrypted hop by hop per RFC 8723.
Every packet MUST be authenticated hop by hop between an endpoint and a Media Distributor, as well as between Media Distributors. The use of the replay protection mechanism specified in Section 3.3.2 of RFC 3711 is REQUIRED at each hop.
Key Distributors MUST reject DTLS associations with any unauthorized endpoint or Media Distributor.
The generated SRTP master salt for E2E encryption MUST be replaced with the salt value provided by the Key Distributor via the EKTKey message, because every endpoint in the conference uses the same SRTP master salt.
The Key Distributor MUST NOT establish DTLS-SRTP associations with endpoints without first authenticating the Media Distributor tunneling the DTLS-SRTP packets from the endpoint.
The Media Distributor MUST keep track of each distinct HBH key (and the corresponding salt) and use it only for the specified hop, since no two endpoints have the same HBH key.
Upon receipt of a new EKT Key, the endpoint MUST create a new SRTP master key and prepare to send that key inside a FullEKTField using the new EKT Key. Endpoints MUST also be prepared to decrypt EKT Tags using the new key immediately.
When establishing the DTLS association between endpoints and the Key Distributor, the endpoint MUST act as the DTLS client, and the Key Distributor MUST act as the DTLS server.
Confidential information must not be placed in RTCP packets or RTP header extensions, as both are visible to Media Distributors. The framework ensures media content privacy by restricting E2E key access to trusted endpoints only, making media content unreadable by the conferencing infrastructure.
PERC uses three key types: (1) HBH Key — SRTP master key for hop-by-hop encryption; (2) KEK (EKT Key) — shared by all endpoints, used to encrypt each endpoint's E2E SRTP master key; (3) E2E Key — SRTP master key for end-to-end media encryption, distinct per endpoint. Only endpoints and the Key Distributor hold the KEK; Media Distributors never hold it.
The EKT Key SPI (Security Parameter Index) field is used to differentiate between EKT Tags encrypted with old and new KEKs during rekeying transitions, allowing receivers to apply the correct decryption key for each arriving packet.
The Key Distributor maintains a tunnel with the Media Distributor (e.g., via the PERC-DTLS tunnel protocol) that enables the Media Distributor to relay DTLS packets between endpoints and the Key Distributor, while the Key Distributor securely delivers HBH key information back to the Media Distributor over the same tunnel.
The SRTP double transform (RFC 8723) is used by endpoints to apply both E2E and HBH encryption contexts in a single SRTP operation. Media Distributors use only the corresponding single AES-GCM transform keyed with the appropriate HBH keys.
A compromised endpoint exposes all keying material (KEK, E2E keys, HBH key) and allows injection of arbitrary media using the compromised SSRC or any other SSRC, since all participants share the KEK. PERC's cipher suite does not include per-source authentication (TESLA is noted as a future option); possession of the KEK is all that is verified.
A compromised Media Distributor can perform a splicing attack by swapping SSRCs between streams. PERC prevents this by including the SSRC in both the HBH and E2E integrity checks, so any SSRC modification invalidates authentication at the receiver.
A delayed playout attack allows a Media Distributor to hold received media and forward it later, bypassing E2E replay protection because the MD is permitted to skip stream forwarding. Periodic conference rekeying reduces effectiveness, since significantly delayed media encrypted with expired keys will not be decrypted.
PERC does not provide E2E protection of RTCP messages, allowing a compromised Media Distributor to forge or modify media statistics, picture requests, and loss indications. Forged picture requests can consume significant bandwidth and impair conference performance.
The Key Distributor is the highest-value attack target: compromise yields access to KEK and master salt, enabling decryption of all conference media. Physical and network access must be severely restricted, and keying material should be destroyed once the conference concludes or after rekeying unless retention is required.
An encrypted PERC media packet consists of the RTP fixed header and CSRCs (authenticated by both E2E and HBH), an optional RTP extension (authenticated HBH only), an E2E-encrypted-and-authenticated payload with E2E auth tag and OHB (Original Header Block), an HBH authentication tag wrapping all prior fields, and a plaintext EKT Tag appended after the double transform without additional encryption or authentication.