Privacy and Security , Huddle 01

Published in

Huddle 01

6 min readJan 17, 2021

At Huddle 01, user privacy and security is of at-most priority and it inherits from WebRTC where encryption and authentication is implemented at its core. WebRTC standardisation is done collectively by WHATWG, W3C, IETF and strong internet working group , the protocols used for encryption safe and guards users privacy .

This security ensures users data can’t be seen by any 3rd party (Privacy) and no one can insert any malicious code in between. Huddle 01 works on browser sandbox and not in a separate process. Its components does not require any special or any separate plugin.

The browser is a TRUSTED COMPUTING BASE (TCB) where the code logic works inside of a sandbox that isolates them from the user’s computer. Therefore a script can’t access user audio/video / screen share or other local resources without user consent.

Huddle 01 utilises WebRTC which uses DTLS and SRTP to provide security and privacy. DTLS is a standard protocol implemented in all browser supporting WebRTC and is used to encrypt application data. Since DTLS is already implemented in browser it requires no prior setup and is designed to stop eavesdropping and tampering. DTLS is sibling of TLS, protocol which offers full encryption with asymmetric cryptography methods, data and message authentication. TLS is over TCP but DTLS is over UDP. DTLS solves packet lost and reordering via (not in TLS)

packet retransmission
assigning sequence number within the handshake
replay detection.

For exchanging media SRTP is used as it optimised for audio/video packets and has advantages instead of sending media via DLTS.

How Secure Link is Established ?

After signalling and ICE checks happens between two peers they start to establish one or more secure channel. DTLS handshake is used on connection provided by ICE.

DTLS is a client/server protocol therefore one side needs to start the handshake. When DTLS handshake occurs certificates are exchanged and after the handshake process they are compared to certificate hash present in SDP . This makes sure you are communicating with peer you intended too.

DTLS alone is enough for data channel encryption but for media we are required to create SRTP session. The keys generated from DLTS are utilised to bootstrap SRTP session as it doesn’t have it’s own handshake mechanism .

What is DTLS ?

As mentioned above DTLS (Datagram Transport Layer Security) is protocol secure data channel via encryption to prevent eavesdropping, tampering and message forgery.

For communication between DTLS server/client a cipher and key needs to be negotiated and these values are determined with DTLS handshake. After handshake is over Change Cipher Specis called and all messages thereafter are encrypted.

Packet Format Every DTLS packet starts with a header

Content Type You can expect the following types

Change Cipher Spec — 20
Handshake — 22
Application Data — 23

Handshake is used to exchange the details to start the session. Change Cipher Spec is used to notify the other side that everything will be encrypted. Application Data are the encrypted messages.

Version Version can either be 0x0000feff (DTLS v1.0) or 0x0000fefd (DTLS v1.2) there is no v1.1

Epoch The epoch starts at 0, but becomes 1 after a Change Cipher Spec. Any message with a non-zero epoch is encrypted.

Sequence Number Sequence Number is used to keep messages in order. Each message increases the Sequence Number. When the epoch is incremented the Sequence Number starts over.

Length and Payload The Payload is Content Type specific. For a Application Data the Payload is the encrypted data. For Handshake it will be different depending on the message.

The length is for how big the Payload is.

Handshake State Machine During the handshake, the Client/Server exchange a series of messages. These messages are grouped into flights. Each flight may have multiple messages in it (or just one). A Flight is not complete until all the messages in the flight have been received. We will describe the purpose of each message in greater detail below,

ClientHello ClientHello is the initial message sent by the client. It contains a list of attributes. These attributes tell the server the ciphers and features the client supports. For WebRTC this is how we choose the SRTP Cipher as well. It also contains random data that will be used to generate the keys for the session.

HelloVerifyRequest HelloVerifyRequest is sent by the server to the client. It is to make sure that the client intended to send the request. The Client then re-sends the ClientHello, but with a token provided in the HelloVerifyRequest.

ServerHello ServerHello is the response by the server for the configuration of this session. It contains what cipher will be used when this session is over. It also contains the server random data.

Certificate Certificate contains the certificate for the Client or Server. This is used to uniquely identify who we were communicating with. After the handshake is over we will make sure this certificate when hashed matches the fingerprint in the SessionDescription

ServerKeyExchange/ClientKeyExchange These messages are used to transmit the public key. On startup the client and server both generate keypair. After the handshake these values will be used to generate the Pre-Master Secret

CertificateRequest CertificateRequest is sent by the server notifying the client that it wants a certificate. The server can either Request or Require a certificate.

ServerHelloDone ServerHelloDone notifies the client that the server is done with the handshake

CertificateVerify CertificateVerify is how the sender proves that it has the private key sent in the Certificate message.

ChangeCipherSpec ChangeCipherSpec informs the receiver that everything sent after this message will be encrypted.

Finished Finished is encrypted and contains a hash of all messages. This is to assert that the handshake was not tampered with.

Hand shaking process

The DTLS client and server exchange hellos. The version of the protocol which is to be used is decided at this stage.
The DTLS client calculates the pre-master secret.
The server sends its certificate to the client, which verifies it. If the certificate is invalid, the client sends an alert to the server.
Optionally, and only if the certificate does not contain a server public key, keys are exchanged.
The DTLS client encrypts the pre-master secret.
The server requests the client’s certificate from the client, which sends it. The server verifies it and, if the certificate is invalid, sends an alert to the client. Otherwise, it sends a ServerHelloDone() and the client responds with ClientKeyExchange().
The client calls ChangeCipherSpec() and sends a Finished message.
The server verifies that the Finished message is from the client. If it is invalid, it sends an alert to the client, otherwise it calls ChangeCipherSpec() and sends a Finished message. If the client verifies this successfully, the handshake has completed without error.

Key Generation For key generation we generate the Pre-Master Secret. To obtain this value Diffie–Hellman is used on the keys exchanged by the ServerKeyExchange and ClientKeyExchange. The details differ depending on the chosen Cipher.

Next the Master Secret is generated. Each version of DTLS has a defined Pseudorandom function. For DTLS 1.2 the PRF takes the Pre-Master Secret and random values in the ClientHello and ServerHello. The output from running the Pseudorandom Function is the Master Secret. The Master Secret is the value that is what is used for the Cipher.

What is SRTP ?

SRTP is a protocol used to provide encryption, message authentication, integrity and replay attack protection for media packets (RTP). For a SRTP session a cypher / keys needs to be negotiated which is inherited from DTLS protocol . It is because SRTP protocol doesn’t has it’s own handshake mechanism. SRTP uses Advanced Encryption Standard (AES) as its default encryption cipher.

SRTP defines a Key Derivation Function that is used on the inputs to generate our keys for our SRTP Cipher. Every RTP packet has a 16 bit sequence number to keep the packets in order and gets rollover during a call which SRTP keeps track of ( rollover counter ). Rollover counter and sequence number are used for nonce. Nonce makes sure that for same data different cipher text are generated so that no one can identify the patterns.

Privacy and Security , Huddle 01

How Secure Link is Established ?

What is DTLS ?

Hand shaking process

What is SRTP ?

References

Written by SUSMIT