Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WebRTC security+more @ KamailioWorld 2018

301 views

Published on

An overview on how WebRTC was written from the ground up with some specific concepts in mind, specifically to try and address Security, Authentication and Privacy the right way.

Published in: Technology
  • Be the first to comment

WebRTC security+more @ KamailioWorld 2018

  1. 1. Security, Authentication and Privacy: The WebRTC Challenge Lorenzo Miniero @elminiero Kamailio World May 16th 2018,
  2. 2. Before we start... Lorenzo Miniero • Ph.D @ UniNA • Chairman @ Meetecho • Open source believer Contacts and info • http://www.meetecho.com • https://twitter.com/elminiero • https://www.slideshare.net/LorenzoMiniero
  3. 3. Before we start... Lorenzo Miniero • Ph.D @ UniNA • Chairman @ Meetecho • Open source believer Contacts and info • http://www.meetecho.com • https://twitter.com/elminiero • https://www.slideshare.net/LorenzoMiniero
  4. 4. Before we start... Lorenzo Miniero • Ph.D @ UniNA • Chairman @ Meetecho • Open source believer Contacts and info • http://www.meetecho.com • https://twitter.com/elminiero • https://www.slideshare.net/LorenzoMiniero
  5. 5. Nope, not going to talk about Janus, today...
  6. 6. Nope, not going to talk about Janus, today... ... but it will reappear before we wrap this up!
  7. 7. A bit of history (of evil) • Several security threats • Interception and modification • Abuse of Service (fraud) • Interruption of Service (Denial of Service attacks) • Social attacks (SPAM over Internet Telephony) • Hard to take care of them all • Several protocols/components/topologies involved • Completely different attacks (RTP bleed anyone?) Where do you typically start? Securing the protocols themselves with some good ol’ encryption! • SIP/TLS will protect negotiation info too
  8. 8. A bit of history (of evil) • Several security threats • Interception and modification • Abuse of Service (fraud) • Interruption of Service (Denial of Service attacks) • Social attacks (SPAM over Internet Telephony) • Hard to take care of them all • Several protocols/components/topologies involved • Completely different attacks (RTP bleed anyone?) Where do you typically start? Securing the protocols themselves with some good ol’ encryption! • SIP/TLS will protect negotiation info too
  9. 9. A bit of history (of evil) • Several security threats • Interception and modification • Abuse of Service (fraud) • Interruption of Service (Denial of Service attacks) • Social attacks (SPAM over Internet Telephony) • Hard to take care of them all • Several protocols/components/topologies involved • Completely different attacks (RTP bleed anyone?) Where do you typically start? Securing the protocols themselves with some good ol’ encryption! • SIP/TLS will protect negotiation info too
  10. 10. “Think of the media!”
  11. 11. Securing RTP • Not as easy as securing SIP • Might use RTP/TLS, but... • RTP is almost always transported over UDP • TCP not suitable for its real-time requirements • Might use RTP/IPsec, but... • Assumes IPsec is available (e.g., in a VPN) • A lot of overhead involved Secure Real-time Transport Protocol (SRTP) https://tools.ietf.org/html/rfc3711 • Extends RTP to make it “secure” • Authentication, integrity, protection against replay
  12. 12. Securing RTP • Not as easy as securing SIP • Might use RTP/TLS, but... • RTP is almost always transported over UDP • TCP not suitable for its real-time requirements • Might use RTP/IPsec, but... • Assumes IPsec is available (e.g., in a VPN) • A lot of overhead involved Secure Real-time Transport Protocol (SRTP) https://tools.ietf.org/html/rfc3711 • Extends RTP to make it “secure” • Authentication, integrity, protection against replay
  13. 13. Securing RTP • Not as easy as securing SIP • Might use RTP/TLS, but... • RTP is almost always transported over UDP • TCP not suitable for its real-time requirements • Might use RTP/IPsec, but... • Assumes IPsec is available (e.g., in a VPN) • A lot of overhead involved Secure Real-time Transport Protocol (SRTP) https://tools.ietf.org/html/rfc3711 • Extends RTP to make it “secure” • Authentication, integrity, protection against replay
  14. 14. Securing RTP • Not as easy as securing SIP • Might use RTP/TLS, but... • RTP is almost always transported over UDP • TCP not suitable for its real-time requirements • Might use RTP/IPsec, but... • Assumes IPsec is available (e.g., in a VPN) • A lot of overhead involved Secure Real-time Transport Protocol (SRTP) https://tools.ietf.org/html/rfc3711 • Extends RTP to make it “secure” • Authentication, integrity, protection against replay
  15. 15. Secure Real-time Transport Protocol (SRTP)
  16. 16. Key Exchange (1) • SRTP specifies how to encrypt packets... • ... but not how to exchange keys • Several alternatives • MIKEY (Multimedia Internet KEYing) • https://tools.ietf.org/html/rfc3830 • Ticket-Based system • Too complex for VoIP? (but used by 3GPP) • ZRTP (Zimmermann RTP) • https://tools.ietf.org/html/rfc6189 (Informational!) • Focus on end-to-end (no need for PKI) • Diffie-Hellman on Media path (no need for encrypted signalling)
  17. 17. Key Exchange (1) • SRTP specifies how to encrypt packets... • ... but not how to exchange keys • Several alternatives • MIKEY (Multimedia Internet KEYing) • https://tools.ietf.org/html/rfc3830 • Ticket-Based system • Too complex for VoIP? (but used by 3GPP) • ZRTP (Zimmermann RTP) • https://tools.ietf.org/html/rfc6189 (Informational!) • Focus on end-to-end (no need for PKI) • Diffie-Hellman on Media path (no need for encrypted signalling)
  18. 18. Key Exchange (1) • SRTP specifies how to encrypt packets... • ... but not how to exchange keys • Several alternatives • MIKEY (Multimedia Internet KEYing) • https://tools.ietf.org/html/rfc3830 • Ticket-Based system • Too complex for VoIP? (but used by 3GPP) • ZRTP (Zimmermann RTP) • https://tools.ietf.org/html/rfc6189 (Informational!) • Focus on end-to-end (no need for PKI) • Diffie-Hellman on Media path (no need for encrypted signalling)
  19. 19. Key Exchange (1) • SRTP specifies how to encrypt packets... • ... but not how to exchange keys • Several alternatives • MIKEY (Multimedia Internet KEYing) • https://tools.ietf.org/html/rfc3830 • Ticket-Based system • Too complex for VoIP? (but used by 3GPP) • ZRTP (Zimmermann RTP) • https://tools.ietf.org/html/rfc6189 (Informational!) • Focus on end-to-end (no need for PKI) • Diffie-Hellman on Media path (no need for encrypted signalling)
  20. 20. ZRTP (Zimmermann Secure RTP)
  21. 21. Key Exchange (2) • SDES-SRTP (Secure Description) • https://tools.ietf.org/html/rfc4568 • Simple, widespread • Exchanges keys in SDP (requires secure signalling) • DTLS-SRTP (Datagram Transport Layer Security) • https://tools.ietf.org/html/rfc5763 • Exploits DTLS, which is “like TLS” but for UDP • SDP transports certificate fingerprints (keys exchanged in DTLS) Hot topic in the IETF (RTPSEC BOF was a long time ago, March 2007) • http://www.ietf.org/proceedings/68/rtpsec.html
  22. 22. Key Exchange (2) • SDES-SRTP (Secure Description) • https://tools.ietf.org/html/rfc4568 • Simple, widespread • Exchanges keys in SDP (requires secure signalling) • DTLS-SRTP (Datagram Transport Layer Security) • https://tools.ietf.org/html/rfc5763 • Exploits DTLS, which is “like TLS” but for UDP • SDP transports certificate fingerprints (keys exchanged in DTLS) Hot topic in the IETF (RTPSEC BOF was a long time ago, March 2007) • http://www.ietf.org/proceedings/68/rtpsec.html
  23. 23. Key Exchange (2) • SDES-SRTP (Secure Description) • https://tools.ietf.org/html/rfc4568 • Simple, widespread • Exchanges keys in SDP (requires secure signalling) • DTLS-SRTP (Datagram Transport Layer Security) • https://tools.ietf.org/html/rfc5763 • Exploits DTLS, which is “like TLS” but for UDP • SDP transports certificate fingerprints (keys exchanged in DTLS) Hot topic in the IETF (RTPSEC BOF was a long time ago, March 2007) • http://www.ietf.org/proceedings/68/rtpsec.html
  24. 24. Secure Description (SDES) • Simple mechanism to negotiate parameters • Negotiation in SDP as additional a-line a=crypto:<tag> <crypto-suite> inline:<key||salt> [session-parms] • Supported crypto-suites (AES/SHA1 variations, GCM, ...) • AES_CM_128_HMAC_SHA1_80 • AES_CM_128_HMAC_SHA1_32 • F8_128_HMAC_SHA1_32 • ... • Master key and salt provided inline • Concatenated and base64 encoded • Secure only if no one has access to the SDP...
  25. 25. Secure Description (SDES) • Simple mechanism to negotiate parameters • Negotiation in SDP as additional a-line a=crypto:<tag> <crypto-suite> inline:<key||salt> [session-parms] • Supported crypto-suites (AES/SHA1 variations, GCM, ...) • AES_CM_128_HMAC_SHA1_80 • AES_CM_128_HMAC_SHA1_32 • F8_128_HMAC_SHA1_32 • ... • Master key and salt provided inline • Concatenated and base64 encoded • Secure only if no one has access to the SDP...
  26. 26. Secure Description (SDES) • Simple mechanism to negotiate parameters • Negotiation in SDP as additional a-line a=crypto:<tag> <crypto-suite> inline:<key||salt> [session-parms] • Supported crypto-suites (AES/SHA1 variations, GCM, ...) • AES_CM_128_HMAC_SHA1_80 • AES_CM_128_HMAC_SHA1_32 • F8_128_HMAC_SHA1_32 • ... • Master key and salt provided inline • Concatenated and base64 encoded • Secure only if no one has access to the SDP...
  27. 27. Secure Description (SDES)
  28. 28. Datagram Transport Layer Security (DTLS) • Recent standard, favourite in the IETF • But not very deployed up to very recently... • SRTP keys exchanged over DTLS • https://tools.ietf.org/html/rfc5764 • Ad-hoc extensions for SRTP keys (use_srtp) • Media still SRTP! (DTLS not used as a transport) • SDP still used for negotiation, but does not contain keys • Cryptographic handshake done in-band (à-la ZRTP), over media channel • Basically TLS over UDP • Handshake authenticated via certificate fingerprint • Fingerprint is what is exchanged via SDP • Some additional parameters related to DTLS and roles
  29. 29. Datagram Transport Layer Security (DTLS) • Recent standard, favourite in the IETF • But not very deployed up to very recently... • SRTP keys exchanged over DTLS • https://tools.ietf.org/html/rfc5764 • Ad-hoc extensions for SRTP keys (use_srtp) • Media still SRTP! (DTLS not used as a transport) • SDP still used for negotiation, but does not contain keys • Cryptographic handshake done in-band (à-la ZRTP), over media channel • Basically TLS over UDP • Handshake authenticated via certificate fingerprint • Fingerprint is what is exchanged via SDP • Some additional parameters related to DTLS and roles
  30. 30. Datagram Transport Layer Security (DTLS) • Recent standard, favourite in the IETF • But not very deployed up to very recently... • SRTP keys exchanged over DTLS • https://tools.ietf.org/html/rfc5764 • Ad-hoc extensions for SRTP keys (use_srtp) • Media still SRTP! (DTLS not used as a transport) • SDP still used for negotiation, but does not contain keys • Cryptographic handshake done in-band (à-la ZRTP), over media channel • Basically TLS over UDP • Handshake authenticated via certificate fingerprint • Fingerprint is what is exchanged via SDP • Some additional parameters related to DTLS and roles
  31. 31. Datagram Transport Layer Security (DTLS) • Recent standard, favourite in the IETF • But not very deployed up to very recently... • SRTP keys exchanged over DTLS • https://tools.ietf.org/html/rfc5764 • Ad-hoc extensions for SRTP keys (use_srtp) • Media still SRTP! (DTLS not used as a transport) • SDP still used for negotiation, but does not contain keys • Cryptographic handshake done in-band (à-la ZRTP), over media channel • Basically TLS over UDP • Handshake authenticated via certificate fingerprint • Fingerprint is what is exchanged via SDP • Some additional parameters related to DTLS and roles
  32. 32. Datagram Transport Layer Security (DTLS) • Recent standard, favourite in the IETF • But not very deployed up to very recently... • SRTP keys exchanged over DTLS • https://tools.ietf.org/html/rfc5764 • Ad-hoc extensions for SRTP keys (use_srtp) • Media still SRTP! (DTLS not used as a transport) • SDP still used for negotiation, but does not contain keys • Cryptographic handshake done in-band (à-la ZRTP), over media channel • Basically TLS over UDP • Handshake authenticated via certificate fingerprint • Fingerprint is what is exchanged via SDP • Some additional parameters related to DTLS and roles
  33. 33. Enter WebRTC/RTCWEB... • Standard effort to build real-time communications integrated in browsers • Re-uses pre-existing standards, with some enhancements, and adds others • SDP, SRTP, ICE, and others (but not SIP) are all there, “on steroids” • Strong emphasis on security and privacy • https://tools.ietf.org/html/draft-ietf-rtcweb-security • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch • Media security is mandatory • https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage • MUST implement DTLS-SRTP (with ECDHE+ECDSA) • NULL ciphers and SDES-SRTP MUST NOT be supported • In browsers, HTTPS mandatory as well (to avoid messing with fingerprints)
  34. 34. Enter WebRTC/RTCWEB... • Standard effort to build real-time communications integrated in browsers • Re-uses pre-existing standards, with some enhancements, and adds others • SDP, SRTP, ICE, and others (but not SIP) are all there, “on steroids” • Strong emphasis on security and privacy • https://tools.ietf.org/html/draft-ietf-rtcweb-security • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch • Media security is mandatory • https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage • MUST implement DTLS-SRTP (with ECDHE+ECDSA) • NULL ciphers and SDES-SRTP MUST NOT be supported • In browsers, HTTPS mandatory as well (to avoid messing with fingerprints)
  35. 35. Enter WebRTC/RTCWEB... • Standard effort to build real-time communications integrated in browsers • Re-uses pre-existing standards, with some enhancements, and adds others • SDP, SRTP, ICE, and others (but not SIP) are all there, “on steroids” • Strong emphasis on security and privacy • https://tools.ietf.org/html/draft-ietf-rtcweb-security • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch • Media security is mandatory • https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage • MUST implement DTLS-SRTP (with ECDHE+ECDSA) • NULL ciphers and SDES-SRTP MUST NOT be supported • In browsers, HTTPS mandatory as well (to avoid messing with fingerprints)
  36. 36. Enter WebRTC/RTCWEB... • Standard effort to build real-time communications integrated in browsers • Re-uses pre-existing standards, with some enhancements, and adds others • SDP, SRTP, ICE, and others (but not SIP) are all there, “on steroids” • Strong emphasis on security and privacy • https://tools.ietf.org/html/draft-ietf-rtcweb-security • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch • Media security is mandatory • https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage • MUST implement DTLS-SRTP (with ECDHE+ECDSA) • NULL ciphers and SDES-SRTP MUST NOT be supported • In browsers, HTTPS mandatory as well (to avoid messing with fingerprints)
  37. 37. The WebRTC “trapezoid” (hey, it looks like SIP!)
  38. 38. It really isn’t SIP, though... • Negotiation (Signalling completely agnostic!) • Javascript Session Establishment Protocol (JSEP) • Session Description Protocol (SDP) adaptation • Connection Establishment and NAT Traversal • Session Traversal Utilities for NAT (STUN) • Traversal Using Relay NAT (TURN) • Interactive Connectivity Establishment (ICE) • Media Transport and Control • Real-time Transport (and Control) Protocol (RTP/RTCP) • Secure Extensions to RTP (SRTP) • Datagram Transport Layer Security (DTLS) • Multimedia codecs • Opus audio codec (MTI, Mandatory-to-implement) • VP8 and H.264 video codecs (MTI, Mandatory-to-implement) • Generic Data • WebRTC Data Channels (SCTP)
  39. 39. The WebRTC protocol suite
  40. 40. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  41. 41. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  42. 42. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  43. 43. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  44. 44. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  45. 45. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  46. 46. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  47. 47. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  48. 48. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  49. 49. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is verified (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent verification (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
  50. 50. Does WebRTC “RTP bleed” too? • RTP bleed is a well known issue, now • https://www.rtpbleed.com/ • https://fosdem.org/2018/schedule/event/rtpbleed/ • Basically caused by so-called “media latching” RTP servers often do • Rather than sending to negotiated address, they send to who last sent them media • Simple trick to help with NATs (you don’t need ICE), but terrible for security • Any session can be highjacked or disrupted by just sending stuff to the right port Thanks to its architecture WebRTC is typically NOT affected, though • Media is always encrypted, and connectivity paths are authenticated with ICE • https://www.rtpbleed.com/#so-is-webrtc-also-vulnerable
  51. 51. Does WebRTC “RTP bleed” too? • RTP bleed is a well known issue, now • https://www.rtpbleed.com/ • https://fosdem.org/2018/schedule/event/rtpbleed/ • Basically caused by so-called “media latching” RTP servers often do • Rather than sending to negotiated address, they send to who last sent them media • Simple trick to help with NATs (you don’t need ICE), but terrible for security • Any session can be highjacked or disrupted by just sending stuff to the right port Thanks to its architecture WebRTC is typically NOT affected, though • Media is always encrypted, and connectivity paths are authenticated with ICE • https://www.rtpbleed.com/#so-is-webrtc-also-vulnerable
  52. 52. Does WebRTC “RTP bleed” too? • RTP bleed is a well known issue, now • https://www.rtpbleed.com/ • https://fosdem.org/2018/schedule/event/rtpbleed/ • Basically caused by so-called “media latching” RTP servers often do • Rather than sending to negotiated address, they send to who last sent them media • Simple trick to help with NATs (you don’t need ICE), but terrible for security • Any session can be highjacked or disrupted by just sending stuff to the right port Thanks to its architecture WebRTC is typically NOT affected, though • Media is always encrypted, and connectivity paths are authenticated with ICE • https://www.rtpbleed.com/#so-is-webrtc-also-vulnerable
  53. 53. What about “Man in the Middle” attacks? https://webrtchacks.com/webrtc-and-man-in-the-middle-attacks/
  54. 54. What about “Man in the Middle” attacks? https://webrtchacks.com/webrtc-and-man-in-the-middle-attacks/
  55. 55. The proposed solution: Identity Providers! • All certificates in WebRTC are self-signed • How can I trust a user/verify the fingerprint? • Identity Verification via Identity Providers • PeerConnection generates fingerprints • User authenticates at IdP and sends info • IdP generates Identity Assertion (to be put in SDP) • Peers validate each other against IdPs Playing with Identity Providers • Client side currently only available in Firefox • http://w3c.github.io/webrtc-pc/#sec.identity-proxy • Hackaton at latest IETF101 for Identity Services • http://webrtcbydralex.com/index.php/2018/03/22/
  56. 56. The proposed solution: Identity Providers! • All certificates in WebRTC are self-signed • How can I trust a user/verify the fingerprint? • Identity Verification via Identity Providers • PeerConnection generates fingerprints • User authenticates at IdP and sends info • IdP generates Identity Assertion (to be put in SDP) • Peers validate each other against IdPs Playing with Identity Providers • Client side currently only available in Firefox • http://w3c.github.io/webrtc-pc/#sec.identity-proxy • Hackaton at latest IETF101 for Identity Services • http://webrtcbydralex.com/index.php/2018/03/22/
  57. 57. The proposed solution: Identity Providers! • All certificates in WebRTC are self-signed • How can I trust a user/verify the fingerprint? • Identity Verification via Identity Providers • PeerConnection generates fingerprints • User authenticates at IdP and sends info • IdP generates Identity Assertion (to be put in SDP) • Peers validate each other against IdPs Playing with Identity Providers • Client side currently only available in Firefox • http://w3c.github.io/webrtc-pc/#sec.identity-proxy • Hackaton at latest IETF101 for Identity Services • http://webrtcbydralex.com/index.php/2018/03/22/
  58. 58. The proposed solution: Identity Providers! • All certificates in WebRTC are self-signed • How can I trust a user/verify the fingerprint? • Identity Verification via Identity Providers • PeerConnection generates fingerprints • User authenticates at IdP and sends info • IdP generates Identity Assertion (to be put in SDP) • Peers validate each other against IdPs Playing with Identity Providers • Client side currently only available in Firefox • http://w3c.github.io/webrtc-pc/#sec.identity-proxy • Hackaton at latest IETF101 for Identity Services • http://webrtcbydralex.com/index.php/2018/03/22/
  59. 59. Example of Identity Assertion (IdP) { "fingerprint": [ { "algorithm": "sha-256", "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" }, { "algorithm": "sha-1", "digest": "74:E9:76:C8:19:...:F4:45:6B" } ] }
  60. 60. Example of Identity Assertion (SDP) v=0 o=- 1181923068 1181923196 IN IP4 ua1.example.com s=example1 c=IN IP4 ua1.example.com a=fingerprint:sha-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=identity: eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9 a=... t=0 0 m=audio 6056 RTP/SAVP 0 a=sendrecv ...
  61. 61. What about privacy? • You may have heard this many times... • “This site uses fake datachannels to locate me!” • “WebRTC leaks my real IP address even behind a VPN/proxy!” • Four specific modes for WebRTC behaviour 1 Enumerate all addresses (best media path, but most info disclosed) 2 Default route + associated local addresses (typically same route as HTTP traffic) 3 Default route only (quality implications) 4 Force proxy (reduced quality if proxy doesn’t support UDP) • Mode 1 only used in case of user consent, otherwise fallback to Mode 2 • What is consent, though? (using getUserMedia for that would be terrible...) • Hot debate the past few weeks on the RTCWEB mailing list WebRTC IP Address Handling Requirements • https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling
  62. 62. What about privacy? • You may have heard this many times... • “This site uses fake datachannels to locate me!” • “WebRTC leaks my real IP address even behind a VPN/proxy!” • Four specific modes for WebRTC behaviour 1 Enumerate all addresses (best media path, but most info disclosed) 2 Default route + associated local addresses (typically same route as HTTP traffic) 3 Default route only (quality implications) 4 Force proxy (reduced quality if proxy doesn’t support UDP) • Mode 1 only used in case of user consent, otherwise fallback to Mode 2 • What is consent, though? (using getUserMedia for that would be terrible...) • Hot debate the past few weeks on the RTCWEB mailing list WebRTC IP Address Handling Requirements • https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling
  63. 63. What about privacy? • You may have heard this many times... • “This site uses fake datachannels to locate me!” • “WebRTC leaks my real IP address even behind a VPN/proxy!” • Four specific modes for WebRTC behaviour 1 Enumerate all addresses (best media path, but most info disclosed) 2 Default route + associated local addresses (typically same route as HTTP traffic) 3 Default route only (quality implications) 4 Force proxy (reduced quality if proxy doesn’t support UDP) • Mode 1 only used in case of user consent, otherwise fallback to Mode 2 • What is consent, though? (using getUserMedia for that would be terrible...) • Hot debate the past few weeks on the RTCWEB mailing list WebRTC IP Address Handling Requirements • https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling
  64. 64. What about privacy? • You may have heard this many times... • “This site uses fake datachannels to locate me!” • “WebRTC leaks my real IP address even behind a VPN/proxy!” • Four specific modes for WebRTC behaviour 1 Enumerate all addresses (best media path, but most info disclosed) 2 Default route + associated local addresses (typically same route as HTTP traffic) 3 Default route only (quality implications) 4 Force proxy (reduced quality if proxy doesn’t support UDP) • Mode 1 only used in case of user consent, otherwise fallback to Mode 2 • What is consent, though? (using getUserMedia for that would be terrible...) • Hot debate the past few weeks on the RTCWEB mailing list WebRTC IP Address Handling Requirements • https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling
  65. 65. Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) • Media security works “great” for peer-to-peer • What if I want to join a media conference, though? • Several approaches to conferencing • Full-mesh (everybody connects to everybody) • Multi-point Control Unit (MCU) → server! • Selective Forwarding Unit (SFU) → server! • Going through an SFU or MCU, you “see” the server, not the users Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) https://datatracker.ietf.org/wg/perc/charter/ • Ensure end-to-end confidentiality/authentication • No need to “trust” elements on the media path
  66. 66. Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) • Media security works “great” for peer-to-peer • What if I want to join a media conference, though? • Several approaches to conferencing • Full-mesh (everybody connects to everybody) • Multi-point Control Unit (MCU) → server! • Selective Forwarding Unit (SFU) → server! • Going through an SFU or MCU, you “see” the server, not the users Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) https://datatracker.ietf.org/wg/perc/charter/ • Ensure end-to-end confidentiality/authentication • No need to “trust” elements on the media path
  67. 67. Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) • Media security works “great” for peer-to-peer • What if I want to join a media conference, though? • Several approaches to conferencing • Full-mesh (everybody connects to everybody) • Multi-point Control Unit (MCU) → server! • Selective Forwarding Unit (SFU) → server! • Going through an SFU or MCU, you “see” the server, not the users Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) https://datatracker.ietf.org/wg/perc/charter/ • Ensure end-to-end confidentiality/authentication • No need to “trust” elements on the media path
  68. 68. Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) • Media security works “great” for peer-to-peer • What if I want to join a media conference, though? • Several approaches to conferencing • Full-mesh (everybody connects to everybody) • Multi-point Control Unit (MCU) → server! • Selective Forwarding Unit (SFU) → server! • Going through an SFU or MCU, you “see” the server, not the users Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) https://datatracker.ietf.org/wg/perc/charter/ • Ensure end-to-end confidentiality/authentication • No need to “trust” elements on the media path
  69. 69. Selective Forwarding Unit (SFU) https://webrtchacks.com/webrtc-beyond-one-one/
  70. 70. Double Encryption with PERC Lite https://www.slideshare.net/alexpiwi5/perc-webrtc-e2e-media-encryption-with-sfu
  71. 71. Prototyping PERC Lite with Janus http://www.meetecho.com/blog/meetecho-and-cosmo-strike-again-perc-lite-integration-in-janus/
  72. 72. What else can PERC help with? • PERC originally conceived for multimedia conferencing • Double encryption to preserve end-to-end encryption properties • The same concept can be reused in other contexts, though • e.g., what about multimedia streaming and DRM via WebRTC? • Encrypted content can only be played if you have the right key • Played a bit with this in the Janus Record&Play feature • PERC Lite integration to preserve end-to-end encryption properties • Recording contains end-to-end encrypted RTP packets in .mjr file • Replay needs to happen in PERC Lite session with the original key • Ad-hoc tools to decrypt/encrypt recordings on the server side • Useful for having different keys for different sessions
  73. 73. What else can PERC help with? • PERC originally conceived for multimedia conferencing • Double encryption to preserve end-to-end encryption properties • The same concept can be reused in other contexts, though • e.g., what about multimedia streaming and DRM via WebRTC? • Encrypted content can only be played if you have the right key • Played a bit with this in the Janus Record&Play feature • PERC Lite integration to preserve end-to-end encryption properties • Recording contains end-to-end encrypted RTP packets in .mjr file • Replay needs to happen in PERC Lite session with the original key • Ad-hoc tools to decrypt/encrypt recordings on the server side • Useful for having different keys for different sessions
  74. 74. What else can PERC help with? • PERC originally conceived for multimedia conferencing • Double encryption to preserve end-to-end encryption properties • The same concept can be reused in other contexts, though • e.g., what about multimedia streaming and DRM via WebRTC? • Encrypted content can only be played if you have the right key • Played a bit with this in the Janus Record&Play feature • PERC Lite integration to preserve end-to-end encryption properties • Recording contains end-to-end encrypted RTP packets in .mjr file • Replay needs to happen in PERC Lite session with the original key • Ad-hoc tools to decrypt/encrypt recordings on the server side • Useful for having different keys for different sessions
  75. 75. What else can PERC help with? • PERC originally conceived for multimedia conferencing • Double encryption to preserve end-to-end encryption properties • The same concept can be reused in other contexts, though • e.g., what about multimedia streaming and DRM via WebRTC? • Encrypted content can only be played if you have the right key • Played a bit with this in the Janus Record&Play feature • PERC Lite integration to preserve end-to-end encryption properties • Recording contains end-to-end encrypted RTP packets in .mjr file • Replay needs to happen in PERC Lite session with the original key • Ad-hoc tools to decrypt/encrypt recordings on the server side • Useful for having different keys for different sessions
  76. 76. Encrypted recordings with Janus+PERC Lite https://ieeexplore.ieee.org/document/8169749/
  77. 77. Encrypted recordings with Janus+PERC Lite https://ieeexplore.ieee.org/document/8169749/
  78. 78. Encrypted recordings with Janus+PERC Lite https://ieeexplore.ieee.org/document/8169749/
  79. 79. Encrypted recordings with Janus+PERC Lite https://ieeexplore.ieee.org/document/8169749/
  80. 80. Encrypted recordings with Janus+PERC Lite https://ieeexplore.ieee.org/document/8169749/
  81. 81. An interesting use case: SHINE • Secure Hybrid In Network caching Environment • Security and Content Rights Management • Satellite-assisted In Network Caching Systems https://artes.esa.int/projects/shine-secure-hybrid-network-caching-environment
  82. 82. An interesting use case: SHINE • Secure Hybrid In Network caching Environment • Security and Content Rights Management • Satellite-assisted In Network Caching Systems https://artes.esa.int/projects/shine-secure-hybrid-network-caching-environment
  83. 83. Thanks! Questions? Comments? Get in touch! • https://twitter.com/elminiero • https://twitter.com/meetecho • http://www.meetecho.com

×