WebRTC Transmission Security Mechanism for Internet Communication Security

The digital transformation of the whole society has accelerated the vigorous development of superimposed real-time communication technology. Real-time communication has penetrated into all walks of life and has become an indispensable and important means of communication in people's modern life. Follow [Rongyun Global Internet Communication Cloud] to learn more

Among them, the emergence of WebRTC has enabled the wide application of real-time communication technology. It provides a set of standard APIs that are supported by almost all mainstream browsers, making it possible to communicate audio and video without plug-ins between browsers, greatly reducing audio frequency. threshold for video development. WebRTC can be seen in video conferencing, video recruitment, telemedicine and other scenarios that require real-time interaction.

In WebRTC, in order to ensure the security of media transmission, DTLS and SRTP are introduced to encrypt the communication process. The role and principle of DTLS is similar to that of SSL/TLS, both to make the communication process more secure.

As the second part of the Internet communication security series, this article mainly shares the WebRTC transmission security mechanisms: DTLS and SRTP.

Common encryption methods

encryption

1. Symmetric encryption

Symmetric Cryptography, also known as private key encryption, is the fastest and simplest encryption method. The same secret key is used for encryption and decryption.

Symmetric encryption has many kinds of algorithms, and because of its high efficiency, it is widely used in many encryption protocols. Symmetric encryption usually uses relatively small keys, typically less than 256 bits. The larger the key, the stronger the encryption, but the slower the encryption and decryption process. The size of the key should take into account both security and efficiency.

2. Asymmetric encryption

Asymmetric Cryptography, also known as public key encryption. It uses a pair of keys, public key and private key, to provide a very secure method for data encryption and decryption.

The private key can only be kept safely by one party and cannot be leaked, while the public key can be sent to anyone who requests it. Asymmetric encryption uses one of the pair of keys for encryption, while decryption requires the other key. For example, if you request the public key from the bank, the bank sends the public key to you, and you use the public key to encrypt the message, then only the holder of the private key, the bank, can decrypt your message. Unlike symmetric encryption, banks do not need to send private keys over the network, and the security is greatly improved.

The difference between symmetric encryption and asymmetric encryption is summarized as follows:

(1) The encryption and decryption of symmetric encryption use the same key, so the speed is fast, but because the key needs to be transmitted over the network, the security is not high.

(2) Asymmetric encryption uses a pair of keys, public key and private key, so the security is high, but the speed of encryption and decryption is slow.

(3) The solution is to encrypt the symmetric encryption key with the asymmetric encryption public key, and then send it out. The receiver uses the private key to decrypt to obtain the symmetric encryption key, and then the two parties can use symmetric encryption to communicate.

digital signature

A digital signature is a special encryption check code attached to a message, the so-called checksum, which utilizes asymmetric encryption key encryption technology.

The main function of the digital signature is to prevent the message from being tampered with. Once the message is tampered with by an attacker, it can be immediately discovered by the receiver by matching it with the checksum. The process of digital signature is shown in the following figure:

(The process of digital signature)

Sender A encrypts the message digest (the message is generated by a hash algorithm such as SHA-1) to generate a signature, and sends it to receiver B together with the plaintext message. Receiver B processes the received information. After the calculation, two message digests are obtained. Comparing whether the two message digests are equal can verify whether the message has been tampered with, namely:

(1) The plaintext message generates digest 1 by using the same hash algorithm as the sender;

(2) The signature is decrypted with the public key to generate digest 2.

(The process of digital signature)

---

digital signature

Digital certificates are issued by some recognized and trusted certificate authorities and are not easy to forge. Includes the following:

• Certificate serial number
• Certificate Signature Algorithm
• Certificate issuer
• Validity period
• public key
• Digital Signature of Certificate Authority

A digital certificate can be used by the recipient to verify the identity of the peer. When a receiver (such as a browser) receives a certificate from a peer (such as a web server), it will check the digital signature of the signing authority. Generally speaking, the receiver will pre-install many commonly used signing authorities in advance The certificate (containing the public key) can be used to verify the signature using the public key in advance.

DTLS protocol

DTLS (Datagram Transport Level Security) is a customized and improved TLS protocol for UDP based on the reality that data packets may be lost or reordered in UDP scenarios. DTLS provides a security solution in the UDP transmission scenario, which can prevent messages from being eavesdropped, tampered, and identity impersonation. Where DTLS is used in WebRTC consists of two parts: negotiating and managing [SRTP]() keys and providing encrypted channels for [DataChannel]().

The DTLS protocol can do the following:

• All information is transmitted through encryption, and third parties cannot eavesdrop;
• With data signature and verification mechanism, once it is tampered with, both parties in the communication can find it immediately;
• Has an identity certificate to prevent others from impersonating.

Protocol stack

In WebRTC, RTP is encrypted by introducing DTLS, which makes media communication secure. After the encryption key is negotiated through DTLS, RTP also needs to be upgraded to SRTP, and the communication is performed after encryption by the key. The protocol stack is shown in the following figure:

(DTLS protocol stack)

The DTLS handshake protocol process is as follows, (refer to RFC6347).


(DTLS handshake protocol process)

The handshake process of TLS and DTLS is basically the same, and the differences and special instructions are as follows:

• HelloVerifyRequest in DTLS is a message added to prevent DoS attacks.
• TLS does not send CertificateRequest, this is not necessary, it is reverse verification, that is, the server verifies the client.
• Epoch and SequenceNumber are added to RecordLayer of DTLS; Cookie is added to ClientHello; Fragment information is added to Handshake (to prevent MTU exceeding UDP), all of which are improvements to adapt to UDP packet loss and easy to be attacked. (Refer to RFC 6347)
• The last Alert of DTLS is to decrypt the client's Encrypted Alert message and directly respond to the client. In fact, the server should respond to the encrypted message. Here, our server responds in plaintext to parse the Alert packet encrypted by the client.

The RecordLayer protocol is a protocol related to DTLS transmission, RecordLayer on UDP, Handshake or ChangeCipherSpec or ApplicationData on RecordLayer.

The RecordLayer protocol definition refers to RFC4347, and there are actually three RecordLayer packages:

• DTLSPlaintext, RecordLayer for DTLS plaintext.
• DTLSCompressed, compressed data, generally not used.
• DTLSCiphertext, encrypted data, after ChangeCipherSpec.

There is no explicit field to indicate what kind of message, but it can be judged according to the context and content. For example, ChangeCipherSpec is a passable type, and it must be a Plaintext. In addition to the other handshakes of Finished, it is generally Plaintext.

SRTP key negotiation

role negotiation

In the DTLS protocol, the two sides of communication are divided into Client and Server. DTLS negotiated identities in WebRTC are described in SDP.

The description is as follows, refer to DTLS parameters in SDP-Anatomy

a=setup:active

setup attribute in RFC4145

setup:active, as a client, actively initiate negotiation

setup:passive, as sever, waiting to initiate negotiation

setup:actpass, as a client, actively initiates negotiation. As a server, waiting to initiate negotiation.

Self-Visa Certificate

In WebRTC, the communicating parties will generally not be able to obtain an authentication certificate signed by a well-known root certificate authority (CA), and self-signed certificates are often the only option.

In practical application scenarios, SDP is exchanged in a secure signaling channel (https), and the security and integrity of SDP can be achieved. RFC4572 defines a mechanism for adding a secure hash of a self-signed certificate in SDP, called a "certificate thumbprint".

The description of the certificate fingerprint in SDP is as follows, refer to DTLS parameters in SDP-Anatomy

 a=fingerprint:sha-256 49:66:12:17:0D:1C:91:AE:57:4C:C6:36:DD:D5:97:D2:7D:62:C9:9A:7F:B9:A3:F4:70:03:E7:43:91:73:23:5。

Use the certificate fingerprint to complete the authentication of both communication parties.

Algorithm Negotiation - Hello Message

ClienHello and ServerHello negotiate DTLS Version, CipherSuites, Random, and Extensions.

(ClientHello message)

(ServerHello message)

• Version: Client gives the highest version that it can support or use, such as DTLS1.2. After the server receives this information, it responds according to the version it can support or use, such as DTLS1.0. In the end, the negotiated version, which is DTLS1.0, shall prevail.
• CipherSuites: The Client gives the CipherSuites that it can support, and the Server selects a response that it can support after receiving it, such as TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc014). The cipher suite determines the type of certificate, key generation algorithm, digest algorithm, etc.
• Random: The random number of both parties involved in generating the MasterSecret. The MasterSecret will be used to generate the master key and export the SRTP key. (See the [Export SRTP Key] section for details)
• Extensions: The client gives the extension protocol it wants to use, and the server can respond to the one it supports. For example, although the Client sets the SessionTicket TLS extension, the Server does not respond, so this extension will not be used in the end.

Cipher Suites

(Cipher Suites)

The encrypted socket uses the name registered in IANA in the Hello message.

IANA name by Protocol/Key Exchange Algorithm/ Authentication Algorithm/

Description composition of Encryption Algorithm/Hash Algorithm.

E.g:

The meaning of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is as follows:

• Protocol: Transport Layer Security (TLS)
• Key Exchange: Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)
• Authentication: Rivest Shamir Adleman algorithm (RSA)
• Encryption: Advanced Encryption Standard with 128bit key in Galois/Counter mode (AES 128 GCM)
• Hash: Secure Hash Algorithm 256 (SHA256)

Extension

The extension protocol of DTLS is specified in the Extensions information of ClientHello and ServerHello. For all TLS extensions, refer to TLS Extensions.

The extensions used by WebRTC are listed below:

(Extensions used by WebRTC)

use_srtp: After the DTLS handshake is completed (Finished), use SRTP to transmit data, and DTLS generates the SRTP key.

The extended information in ClientHello defines RFC5764 4.1.2. SRTP Protection Profiles and srtp_mki.

Authentication

Use the certificate fingerprint to complete the authentication of both communication parties. For details, please refer to the [Self-Signed Name Certificate] section.

(Authentication)

key exchange

Server Key Exchange is used to send the public key used by the server to the client. There are two cases:

• RSA algorithm: If the server uses the RSA algorithm, this message may not be sent, because the public key used by the RSA algorithm has been described in the Certificate.
• The DH algorithm calculates the shared key based on the other party's public key and its own private key. Because both Client and Server only know their own private key and each other's public key; and their private keys are different, they can calculate the same shared key according to special mathematical characteristics.

(Server Key Exchange)

Client Key Exchange is used to send the public key used by the Client to the Server.

• RSA algorithm: If the RSA algorithm is used for key negotiation, send the server-side RSA public key to encrypt the premaster secret and send it to the server-side.
• DH algorithm: If the key negotiation uses the DH algorithm and it is not described in the certificate, send the DH algorithm public key used by the client to the server to calculate the shared key. The result of KeyExchange is that the Client and Server obtain the RSA Key, or calculate the shared key through the DH algorithm. For details, see the procedure of [Example of steps to export SRTP keys].

(Client Key Exchange)

Example of steps to export an SRTP key

The process of DTLS is introduced above. The following is a brief description of the derivation steps of the SRTP key by combining the actual data given in the above example.

Negotiated cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Algorithm public key exchanged by KeyExchange: ECDH Server Parameter

 Pubkey:04b0ce3c5f2c4a9fbe7c2257c1328438f3378f74e9f528b6e27a00b44eee4c19e5e6b2cb6cab09f796bcf8c05102b2a4bcdc753d91cc4f431f558c845a1ba6f1ce

named Spk;

ECDH Client Parameter

 PubKey:0454e8fbef1503109d619c39be0ccaf89efa3c3962300476465cbc66b15152cd8a900c45d506420f0123e65d8fbb70cb60b497893f81c5c2a0ef2f4bc2da996d9e

Denoted as Cpk;

Calculate the shared secret S (pre-master-secret) according to the ECDHE algorithm

Assuming that the elliptic curve private key used by the Server is Ds and the Dc used by the Client, the calculation of the shared key is as follows, refer to ECC Elliptic Curve Encryption Algorithm - ECDH, ECDHE, ECDSA

S = Ds Cpk = Dc Spk

This shared secret S is the pre-master-secret we saw in the RFC document

Calculate the master secret

The process of calculating the master secret is as follows, please refer to Computing the Master Secret.

 master_secret=PRF(pre_master_secret,"master 
secret",ClientHello.random+ ServerHello.random)[0..47];

The calculated master_secret is 48 Bytes, where ClientHello.random and ServerHello.random are given in the Hello message. PRF is a pseudorandom function, given in the negotiated cipher suite.

Use master_secrete to export the byte sequence of SRTP encryption parameters, use the calculation method given by RFC5705 4. Exporter Definition, and use the parameters:

 master_secret，client_random，server_random 计算字节序列：

key_block=PRF(master_secret,"EXTRACTOR-dtls_srtp",client_random+server_random)[length]

The required byte sequence length is described in DTLS-SRTP 4.2. Key Derivation.

 2*(SRTPSecurityParams.master_key_len+SRTPSecurityParams.master_salt_len) bytes of data

The values of master_key_len and master_salt_len are defined in the profile described by user_srtp.

The profile we use is SRTP_AES128_CM_

HMAC_SHA1_80, the corresponding profile configuration is:

 SRTP_AES128_CM_HMAC_SHA1_80

        cipher: AES_128_CM

        cipher_key_length: 128

        cipher_salt_length: 112

        maximum_lifetime: 2^31

        auth_function: HMAC-SHA1

        auth_key_length: 160

        auth_tag_length: 80

That is, we need (128/8+112/8)*2 = 60 bytes byte sequence.

Export SRTP keys

Calculate the byte sequence of SRTP encryption parameters. The meaning of the byte sequence is described in DTLS-SRTP 4.2.Key Derivation:

 client_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; // 128 bits

server_write_SRTP_master_key[SRTPSecurityParams.master_key_len]; // 128 bits

client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; // 112 bits

server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len]; // 112 bits

So far we have obtained the SRTP encryption parameters used by Client and Server: master_key and master_salt.

 Clientkey=client_master_key+client_master_salt;

Serverkey=server_master_key+server_master_salt;

After the key is exported, use the key to initialize the SRTPSession to ensure data security and integrity. The Client uses the Clientkey to encrypt the data, sends it to the server, and uses the Serverkey to decrypt the received data.

In WebRTC, both parties in the communication generate self-signed certificates (a=fingerprint:) and DTLS roles (a=setup) and add them to sdp, and conduct sdp exchange negotiation through a secure signaling channel (https). In the DTLS handshake phase, data signature and verification are performed first. If the data is tampered with by an attacker and the verification fails, both parties in the communication can find out immediately.

The two communicating parties negotiate the encryption components, exchange the public keys of both parties, and encrypt and transmit the SRTP key by means of asymmetric encryption. The receiver uses the private key to decrypt to obtain the symmetrically encrypted SRTP key. In this way, the symmetric key is securely transmitted, and the two communicating parties use the symmetric key to encrypt and decrypt the audio and video data, which is efficient and ensures the integrity and security of the audio and video data.