Peer-to-peer communication is lauded for the security it brings due to the implicit trust between peers. What happens when this communication stops being directly peer-to-peer and an intermediary is introduced?
Why is Privacy Enhanced RTP Conferencing (PERC) Needed?
With peer-to-peer communication, the endpoint usually sends a packet directly to the receiving endpoint. This can be handled securely using SRTP, since the packets are encrypted and the DTLS protocol ensures that the endpoints implictly trust the originating and terminating endpoints.
However, this approach stops being as effective in instances of large-scale distribution. For example, during a large-scale video conference within a company, merely two endpoints will not suffice. Similarly, when distributing webinars and large-scale gaming videos (such as through Twitch) a Selective Forwarding Mixer (SFM) or Media Distributor must be used to connect the original stream to a myriad of endpoints.
In these instances, the endpoint sends a packet to a Media Distributor before it reaches the receiving endpoint or endpoints. This Media Distributor performs some actions on the packet, then sends it to the receiving endpoint. To the first endpoint, the Media Distributor appears to be the receiving endpoint. However, it is merely a step along the process.
This Media Distributor becomes a go-between that disrupts the end-to-end security maintained by a purely peer-to-peer system. The endpoints must now trust an additional source besides each other: the Media Distributor.
In order to resolve this, the IETF’s Privacy Enhanced RTP Conferencing (PERC) Working Group is developing solutions including SRTP Double Encryption Procedures. PERC aims to contribute mechanisms that provide hop-by-hop and end-to-end security guarantees based on two separate, yet related cryptographic contexts.
How Does SRTP Double Encryption Work?
Once a Media Distributor is introduced, the question becomes, how do you protect the payload information while simultaneously providing the Media Distributor access to the data it needs?
In order to resolve this question, SRTP Double Encryption encrypts the media payload separately from the other components. Other media components include the RTP header. The Media Distributor may have access to the header and other information it may need to modify, but the payload remains secure.
The encryption process can be separated into two components: end-to-end and hop-by-hop. The recommended cipher for these algorithms is AES-GCM.
End-to-end: Sending to Receiving Endpoint
In order to secure the media payload being passed from one endpoint to another, the first cryptographic key, or payload key, is used between the endpoints. This key is used to encrypt the media packet, excluding the RTP header. Solely the endpoints have access to the key. In contrast, the Media Distributor knows nothing about this key.
This payload key establishes the confidentiality of the media payload and is considered the inner, end-to-end encryption.
Hop-by-hop: The Media Distributor
Since the RTP header and other components may be manipulated by the Media Distributor, a second cryptographic key, or header key, must be used. This ensures integrity and confidentiality for the header information passed from the endpoints to the Media Distributor. This key is known by both endpoints and the Media Distributor.
This header key establishes the confidentiality of the RTP header between the Media Distributor and the endpoints, and is considered the outer, hop-by-hop encryption.
The Process of PERC
The PERC WG separates the solution into three main components: the endpoint, the Media Distributor, and the receiving endpoint. Each component has its own unique process it must follow.
The Endpoint
The endpoint encrypts the media packet (excluding the RTP header), with the payload key. This is the inner, end-to-end encryption. Additionally, the endpoint encrypts the RTP header and other media components with the header key. This is the outer, hop-by-hop encryption. Encryption is always done in this order: end-to-end followed by hop-by-hop. The doubly-encrypted packet is then sent to the Media Distributor. The Media Distributor, which has access to the header key, is able to decrypt and make any necessary changes to the RTP header. However, it does not have access to the payload key, therefore it is unable to decrypt the body of the media payload.
The Media Distributor
Once the Media Distributor has received the packet and decrypted the RTP header, it makes any necessary changes. These changes are implemented as a new RTP header extension. The original value of the RTP header is still included in the new RTP header extension as the Original Header Block (OHB). The Media Distributor may not change values in the OHB, though it may add information to the OHB. Once the Media Distributor is done implementing changes, it encrypts the packet using the header key. Again, this is the outer, hop-by-hop encryption. The again doubly-encrypted packet is then sent to the receiving endpoint.
The Receiving Endpoint
Once the receiving endpoint accepts the packet, it uses the header key to decrypt the outer, hop-by-hop encryption. If the integrity check does not pass, the packet must be discarded. The receiving endpoint may now use the OHB to reconstruct the original packet. It then uses the payload key to decrypt the inner, end-to-end encryption and verify its validity.
Conclusion
Once a Media Distributor is introduced, additional steps must be taken to ensure a secure system. SRTP Double Encryption brings this security through the combination of end-to-end and hop-by-hop encryption.
Interested in learning more about the future of WebRTC? Check out our white paper on innovative uses of real-time video and audio communication.
