Slides about double encryption in a webrtc context to achieve real end-to-end encryption when using an SFU. Work by the Jitsi Team and The CoSMo team, for Symphony, presented at RTC World in Miami on February 2017.

1. Privacy Enhanced WebRTC
Dr Alex & Dr Dan

2. Why do we need Privacy Enhanced WebRTC?
WebRTC is end – to end encrypted by default, but webrtc is also p2p.
Most recent webrtc solutions include a media server for many reasons including
scalability.
When used with a media server, webrtc is not end-to-end encrypted anymore, but
only hop-by-hop (between the local peer and the media server, then between the
media server and the remote peer)
Large enterprises and banks in particular are slowly moving to the cloud but having
their media content transparent to any 3rd party is a blocker, even worse if the
solution is a mutualized (multi-tenants) infrastructure

3. Cloud provider
Alice
Bob
Encryption Key are generated
in/by the browser
Application
Server
Communications over the public internet via a 3rd party Cloud Provider
Javascript
Frontend
Javascript
Frontend
WebRTC Default Case - P2P
This is a true End-To-End
encryption (E2E)

4. TURN Server
Cloud provider
Alice
Bob
Encryption Key are generated
in/by the browser
Application
Server
Communications over the public internet via a 3rd party Cloud Provider
Javascript
Frontend
Javascript
Frontend
WebRTC Default Case - TURN
A TURN Server DOES NOT
terminates the encryption. In
this case this is also a true
End-To-End encryption
(E2E)

5. Media Server
Cloud provider
Alice
Bob
Encryption Key are generated
in/by the browser
Application
Server
Communications over the public internet via a 3rd party Cloud Provider
WebRTC Default Case - Media Server A media Server DOES
terminate the encryption: The
content is accessible in clear
on the server. It is called Hop-
by-Hop encryption (HBH)
RAW MEDIA / CONTENT
Javascript
Frontend
Javascript
Frontend

6. Enterprise
Internal Network
Media Server
Cloud “Untrusted” provider
Alice
Bob
Encryption Keys
Application
Server
Internal Communications via a 3rd party Cloud Provider
Javascript
Frontend
Javascript
Frontend
Double encryption
Trusted Network Connection
The key manager is separated from the browser UA. Browser/app are provided
with two keys. One is used to encrypt the content itself, and not accessible to
the media server. It acts as a garant of ETE encryption of the content. The
other one is used for the normal SRTP encryption, an HBH encryption of the
global stream. This allow backward compatibility with webRTC while adding
true E2E encryption.

7. What are the specs surrounding secure media transfer?
RTP
SRTP
PERC – DOUBLE SRTP

8. 2 standard committees involved in WebRTC
Standard committees
Committee Focus Scope Effort
W3C Browser (UserAgent) Javascript API in
browsers
Key management API
IETF Encryption, Network Libwebrtc native
code (C++)
Second encryption
=
Payload encryption
1 existing standard, currently looking for any implementations to get feedback:
➠ Privacy Enhanced RTP Conferencing (perc)

9. Normal Media Transfer: RTP
Encryption
RTP
Packet
(VP8)
Encoded
Media
RTP Header
VP8 payload descriptor
(Media Metadata)

10. Normal Media Transfer: RTP example with MPEG payload
Encryption
RTP Packet
(MPEG)
Encoded
Media
RTP Header
MEPG payload descriptor
(Media Metadata)

11. SRTP
Encryption
SRTP Packet
RTP Header
Encrypted
VP8
Encoded
Media
VP8 payload
descriptor
Signature

12. Existing double encryption standard: PERC
PERC (Privacy Enhanced RTP Conferencing, ietf working group)
Enabling end-to-end security in centralized switched RTP based conferences.
Trusted: Entities in the trusted domain are fully trusted to
perform the role and actions put on them. They may have
access to unprotected content and keying material used to
protect content end-to-end.
Semi-trusted: Semi-trusted entities have no access to
confidential material such as the content and the keying material
used to protect content end-to-end. They are however trusted to
perform basic operations for selective forwarding of content as
well as session establishment.
Semi-trusted on public internet

13. Existing double encryption standard: PERC
PERC (Privacy Enhanced RTP Conferencing, ietf working group)
Enabling end-to-end security in centralized switched RTP based conferences.
Javascript
Trusted For non-public networks
(vpns) javascript can be a trusted
layer
Steps:
1) Key exchange in client application
(javascript)
1) W3C api to set encryption keys
1) Media encryption / decryption in
webrtc.org

14. First Real World implementation with Jitsi
How packets flow in a webrtc SFU today
What’s the problem in case of double-encryption
Possible Solution

15. SRTP Encrypted Media Transfer: within an SFU
RTP
Packet
(VP8)
Encoded
Media
RTP Header
VP8 payload descriptor
(Media Metadata)
RTP
Packet
(VP8)
Encoded
Media
RTP Header
VP8 payload descriptor
MODIFIED
RTP
Packet
(VP8)
Encoded
Media
RTP Header
VP8 payload descriptor
MODIFIED
Note: You need to modify the SSRC to be able to terminate
RTCP and handle “noisy neighbors”
Encryption
Encryption
Encryption
EncryptionEncryption
EncryptionEncryption
SRTP Packet
RTP Header
Encrypted
VP8
Encoded
Media
VP8 payload
descriptor
Signature
EncryptionEncryption
RTP Header
Encrypted
VP8
Encoded
Media
VP8 payload
descriptor
Signature
EncryptionEncryption
EncryptionEncryption
RTP Header
Encrypted
VP8
Encoded
Media
VP8 payload
descriptor
Signature
Route packet
depending on
Payload
Headers

16. Encrypted HBH
Double-Encrypted Media Transfer: PERC (ex: WebRTC)
EncryptionEncryption
SRTP
PacketRTP Header
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
RTP
Packet
VP8
Encoded
Media
RTP Header
VP8 payload descriptor E2E HBH
Encryption
PERC Packet
RTP Header
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
Signature HBH

17. PERC Encrypted Media Transfer: within an SFU - PROBLEM
EncryptionEncryption
EncryptionEncryption
RTP Header
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
Route packet
depending on
Payload
Headers
HBH
SRTP
Packet
Encrypted HBH
Encryption
PERC Packet
RTP Header
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
Signature HBH

18. Solution: Frame Marking. Some info from the payload
descriptor is copied over in the RTP Header as an Extension
EncryptionEncryption
SRTP
PacketRTP Header
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
RTP
Packet
VP8
Encoded
Media
RTP Header
VP8 payload descriptor
E2E HBH
RTP Header Extention
NEW !
Impl By DrAlex
DrAlex modified Libwebrtc to copy the info from the payload descriptor into a RTP Header
Extension, to use external keys for E2E encryption, and implemented the second encryption in
the pipeline.
Encrypted HBH
Encryption
PERC Packet
RTP Header
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
Signature HBH

19. EncryptionEncryption
PERC Encrypted Media Transfer:
within a smart SFU
EncryptionEncryption
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
NEW !
Impl. By Jitsi
Encrypted HBH
Encryption
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
Signature HBH
HBH
PERC Packet SRTP
PacketRTP Header
RTP Header Extention
RTP Header
RTP Header Extention
EncryptionEncryption
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
RTP Header
RTP Header Extention
EncryptionEncryption
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
RTP Header
RTP Header Extention
Encrypted HBH
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
Signature HBH
RTP Header
RTP Header Extention
Encrypted HBH
Encrypted E2E
VP8
Encoded
Media
VP8 payload
descriptor
Signature E2E
Signature HBH
RTP Header
RTP Header Extention
The Jitsi team modified the Jitsi server to read the frame marking
header extension at the right place, but also to handle another
header extension proposed by PERC (2 items).

20. Thanks! Questions ?
How packets flow in a webrtc SFU today
What’s the problem in case of double-
encryption
Solution using standards.
RTP
SRTP
PERC – DOUBLE SRTP