User Interfaces Encryption of Voice and Video

WebRTC and SIP Security

The CaféX Fusion Client SDK solution is fully complaint with the governing security RFCs regarding webRTC and SIP-based applications. Amongst others,

• RFC 3711, defining Secure RTP (SRTP)
• RFC 4572, defining how to use TLS, on top of which DTLS was designed, in combination with SDP
• RFC 5763, defining DTLS as a key management mechanism
• RFC 5763, defining how to integrate SRTP and DTLS

FCSDK offers two secured interfaces, usually public, with confidentiality, message authentication and replay protection to establish voice and video communication.  The secure signalling interface is provided by a Secure WebSocket, implemented by standard web protocols.  The Media Path is established utilising the secure signalling and SRTP over DTLS-1.2, based on the latest standardised TLS version.

The WEB-RTC - Mandates:

Implementations MUST support DTLS-SRTP for key-management.

FCSDK Call Setup Security

Call Setup between Alice and an endpoint is established as follows:

• When Alice has received a FCSDK-token from the Fusion Enabled Web Application (which is use-case specific). A secure websocket can be established for signalling.
• Secure Websockets are established using a standard handshake, between Client and Server, so that certificate based authentication may be performed, defined by the TLS protocol.
• DTLS performs a similar handshake with different generated certificates used only for media, as per the RFC: 

  Both transport receiver and transport sender implementations MUST
     provide means to generate a key pair and self-signed certificate

• Over the Secure Websocket Alice's client will negotiate SDP with the Media Broker.  The SDP OFFER that Alice sends will contain a Fingerprint of her client's generated certificate. This Fingerprint will be used by Media Broker to ensure that the certificate that is exchanged when the DTLS is established is valid and correct. 
• Like wise the SDP ANSWER will contain a Fingerprint for Alice to perform the same operation of validity.
• The Fusion Media Broker then initiates a DTLS handshake that will trigger negotiation of security parameters such as encryption algorithms supported. CafeX's Media Broker capabilities are listed below.
• Alice will confirm the certificate passed from the Media Broker matches the fingerprint it had sent before. If not, the handshake will be silently stopped.
• Encrypted media can now flow in both directions.
• Each media stream is uniquely defined with an SSRC which can be found in the SDP.  Once Media Packets (RTP) are decrypted by a client or Media Broker, their SSRC will be checked against the negotiated SDP.  Any packets with an unknown SSRC are dropped by Media Broker.

The fingerprint information along with the call SSRC makes sure signalling and media belong to the same call and peers are who they claim to be.

Some clients have SDP which contains a crypto attribute.  This has been dropped by the WebRTC specification an was used to negotiate SDES, which DTLS-SRTP replaces.  This attribute can be ignored.

Security Suites and Extensions Supported

CafeX Media Brokers support the following list of encryption ciphers:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_EMPTY_RENEGOTIATION_INFO_SCSV