Shulou(Shulou.com)06/03 Report--

This article mainly explains "what is the DTLS protocol". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the DTLS protocol".

DTLS (Datagram Transport Layer Security) is a customized and improved TLS protocol for UDP based on the fact that packets may be lost or reordered in UDP scenarios. The use of DTLS in WebRTC consists of two parts: negotiating and managing SRTP keys and providing an encrypted channel for DataChannel.

In this paper, combined with the actual packet analysis of WebRTC using DTLS for SRTP key agreement process. And summarize the problems encountered in the use of DTLS in the actual project.

Brief introduction of DTLS Protocol

Before analyzing the application of DTLS in WebRTC, the basic principle of DTLS protocol is introduced. DTLS protocol consists of two layers: Record protocol and Handshake protocol.

Record protocol: use symmetric key to encrypt the transmitted data, and use HMAC to check the integrity of the data, which realizes the secure transmission of the data.

Handshake protocol: using asymmetric encryption algorithm to complete the negotiation of symmetric keys used by Record protocol.

HandShake

The process of TLS handshake protocol is as follows, refer to RFC5246

The process of DTLS handshake protocol is as follows, refer to RFC6347

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

HelloVerifyRequest in DTLS is an added message to prevent DoS attacks.

TLS does not send CertificateRequest, which is not required, but reverse authentication, that is, the server authenticates the client.

SequenceNumber and Epoch are added to DTLS's RecordLayer, Cookie is added to ClientHello, and Fragment information is added to Handshake (to prevent MTU from exceeding UDP), all of which are designed to adapt to packet loss of UDP and improvements that are easy to be attacked. Reference RFC 6347

The last Alert of DTLS is to decrypt the client's Encrypted Alert message and respond directly to the client. In fact, Server should respond to the encrypted message. Here, our server responds to the plaintext to parse the Alert packet encrypted by the client.

RecordLayer protocol is a protocol related to DTLS transmission, and above UDP is Handshake or ChangeCipherSpec or ApplicationData above RecordLayer,RecordLayer. The definition of RecordLayer protocol refers to RFC4347, and there are actually three packages for RecordLayer:

DTLSPlaintext,DTLS plaintext RecordLayer.

DTLSCompressed, compressed data, generally not used.

DTLSCiphertext, encrypted data, this is what happens after ChangeCipherSpec.

There is no clear field indicating what kind of message it is, but it can be judged by context and content. For example, ChangeCipherSpec can be passed by type, it must be a Plaintext. Except for the other handshakes of Finished, it is usually Plaintext.

SRTP key negotiation role negotiation

In the DTLS protocol, both sides of the communication can be divided into Client and Server. The identity negotiated by DTLS in WebRTC is described in SDP. The description is as follows. Refer to the DTLS parameter in SDP-Anatomy.

A=setup:active

The setup property is in RFC4145

Setup:active, as client, initiates negotiations

Setup:passive, as sever, waits for negotiation to be initiated

Setup:actpass, as client, initiates negotiations. As server, wait for negotiation to be initiated.

Algorithm negotiation-Hello message

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

Version:Client gives the highest version it can support or want to use, such as DTLS1.2. When Server receives this message, it responds according to the version it can support or which version it wants to use, such as DTLS1.0. In the end, the negotiated version, namely DTLS1.0, shall prevail.

CipherSuites:Client gives the cipher suite that it can support. After receiving it, CipherSuites,Server chooses a response that it can support, such as TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014). The cipher suite determines the type of certificate, key generation algorithm, digest algorithm and so on.

Random: random numbers of both parties involved in the generation of MasterSecret. MasterSecret is used to generate the master key and export the SRTP key. For more information, please see [Export SRTP key]

Extensions:Client gives you the extension protocol you want to use, and Server can respond to what you support. For example, Client sets the extension SessionTicket TLS, but Server does not respond, so it will not be used in the end.

Cipher Suite

Encrypting sockets in Hello messages uses the registered name in IANA. The IANA name consists of the descriptions of Protocol,Key Exchange Algorithm,Authentication Algorithm,Encryption Algorithm and Hash Algorithm. For example, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 means something like this:

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)

Encrypted sockets can be found in ciphersuite.info. When you look up the name of IANA, you can also look up the name in OpenSSL. The name of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in OpenSSL is ECDHE-RSA-AES128-GCM-SHA256 Note: for information about Authentication (authentication), KeyExchange (key exchange), Encryption (encryption), MAC (Message Authentication Code) message digest, etc., you can refer to RSA key agreement.

Extension

The extension protocol for DTLS is specified in the Extensions information of ClientHello and ServerHello, and all TLS extensions refer to TLS Extensions. Here are a few extensions used by WebRTC:

Use_srtp: after the DTLS handshake is completed (Finished), the data is transferred using SRTP, and DTLS generates the key of SRTP. RFC5764 . The extended information in ClientHello defines RFC5764 4.1.2. SRTP Protection Profiles and srtp_mki.

Supported_groups, formerly known as elliptic_curves, describes the supported ECC encryption algorithm, refer to RFC8422 5.1.1.Supported Elliptic Curves Extension, generally use secp256r1.

Signature_algorithms,DTLS1.2 extension, specify the use of Hash and Signature algorithms, refer to RFC5246 7.4.1.4.1. Signature Algorithms . DTLS1.0,RSA uses the md5sha1 digest algorithm and DSA uses the sha1 digest algorithm.

Extended_master_secret, expand the generation method of MasterSecret, refer to RFC7627. In KeyExchange, some constants are added to generate MasterSecret. TLS defines the extension method, and if you use this extension, DTLS's approach will be somewhat different from that of TLS.

Renegotiation_info, refer to RFC5746

In addition to these extension protocols, SRTP key export is also related to:

RFC5705: Keying Material Exporters for Transport Layer Security (TLS), how DTLS exports Key from MasterSecret, such as SRTP's Key. RFC5764: the detailed specification of DTLS Extension to Establish Keys for the SRTP,DTLS 's use_srtp extension, including ClientHello extension definition, Profile definition, and Key calculation.

Authentication-Certificate

Digital certificates are issued by some recognized and trusted certification authorities and are not easy to forge. A digital certificate can be used for the receiver to verify the identity of the peer. When the receiver receives a certificate from the peer, the receiver will check the digital signature of the signature authority. Generally speaking, the receiver will pre-install the certificates of many commonly used signature authorities (containing public keys) in advance, and the signatures can be verified using the pre-public key.

After negotiating the method of exchanging keys through Hello messages, the Server side sends the Server certificate to Client for Client to verify the identity of Server. The certificate sent by Server must be applicable to the encrypted socket used by the negotiated KeyExchange and the Hash/Signature algorithm pair described in the Hello message extension.

In WebRTC, both parties of the communication will usually not be able to obtain an authentication certificate signed by a well-known root certificate authority (CA), and a self-signed certificate is usually the only option. RFC4572 defines a mechanism, which is called "certificate fingerprint" by adding a secure hash of the self-signed certificate in the SDP. Under the premise of ensuring the secure transmission of the SDP, if the fingerprint of the certificate provided matches the fingerprint in the SDP, the self-signed certificate can be trusted. In practical application scenarios, SDP exchanges in a secure signaling channel (https), and the security integrity of SDP can be achieved. In this way, in the process of DTLS negotiation, the fingerprint of the certificate can be used to complete the identity verification of both sides of the communication. The certificate fingerprint is described in SDP as follows. Refer to the DTLS parameter 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:5E key Exchange-KeyExchange

ServerKeyExchange is used to send the public key used by the Server side to the Client side. There are two situations:

RSA algorithm: if the server uses the RSA algorithm, you can not send this message, because the public key used by the RSA algorithm is already described in Certificate.

The DH algorithm calculates a shared key based on the other party's public key and his 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, according to their special mathematical characteristics, they can calculate the same shared key. About how the DH algorithm calculates the shared key, refer to the DH algorithm.

ClientKeyExchange is used to send the public key used by Client to the Server side.

RSA algorithm: if the RSA algorithm is used in key negotiation, the RSA public key on the server side is used and the premaster secret is encrypted and sent to the server side.

DH algorithm: if the DH algorithm used in key negotiation is not described in the certificate, the public key of the DH algorithm used by the client is sent to the Server side in order to calculate the shared key. The result of KeyExchange is that Client and Server get the RSA Key or calculate the shared key through the DH algorithm. For more information, please see the process of [exporting SRTP key]

Certificate Verification-CertificateVerify

Use the Hash/Signature algorithm described in ClientRequest to sign the HandShake messages received and sent and send an Server. The Server side verifies the signature.

Encryption Authentication-Finished

When Server and Client complete the exchange of symmetric keys, the peer is notified through ChangeCipherSpec to enter the encryption phase, and epoch is added by 1.

The Client then encrypts the "client finished" using the exchanged key and sends it to the server using the Finished message. Server uses the exchanged key to encrypt "server finished" and send it to the client. Once the finished message is validated, you can communicate normally.

Export SRTP key

The process of DTLS is described above, and the following steps for exporting SRTP keys are explained in detail by combining the actual data given in the above example.

Negotiated encryption algorithm

Cryptographic suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) elliptic curve algorithm: secp256r1, elliptic curve point compression algorithm: uncompressed. Introduction of the basic knowledge of elliptic curve algorithm in the ECC elliptic curve encryption algorithm-ECDH,ECDHE,ECDSA, we can know from the document that the elliptic curve encryption algorithm has the following parameters:

Prime p, which is used to determine the range of a finite field

A _ (_) _ (b) parameter in elliptic curve equation

The base point G used to generate subgroups

Order n of subgroups

The auxiliary factor h of a subgroup is defined as a six-tuple.

The parameters corresponding to secp256r1 can be found in SECG-SEC2 2.4.2 Recommended Parameters secp256r1 as follows:

The parameters used by secp256r1 are as follows: the prime number p:p=FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF=2224 (232 − 1) + 2192 square 296 − 1 elliptic curve E: y ^ 2 = x ^ 3 + ax+b is defined as follows: the uncompressed format of a=FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFCb=5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B base point G: the order n:n=FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551 cofactor h:h=01 of G=046B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C2964FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5 finite field exchanges the public key of elliptic curve algorithm through KeyExchange

ECDH Server Parameter

Pubkey:04b0ce3c5f2c4a9fbe7c2257c1328438f3378f74e9f528b6e27a00b44eee4c19e5e6b2cb6cab09f796bcf8c05102b2a4bcdc753d91cc4f431f558c845a1ba6f1ce

Record as Spk

ECDH Client Paramter

PubKey: 0454e8fbef1503109d619c39be0ccaf89efa3c3962300476465cbc66b15152cd8a900c45d506420f0123e65d8fbb70cb60b497893f81c5c2a0ef2f4bc2da996d9e

Record as Cpk

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

Assume that the elliptic curve private key used by Server is Ds and the Dc used by Client. The shared key is calculated as follows. Refer to ECC elliptic curve encryption algorithm-ECDH,ECDHE,ECDSA

S = Ds * Cpk = Dc * Spk

This shared key S is the pre-master-secret we see in the RFC document.

Calculate master secret

The process of calculating 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 pseudo-random number function (pseudorandom function), given in the negotiated cipher suite.

Export a byte sequence of SRTP encryption parameters using master_secrete

Using the calculation method given by RFC5705 4. Exporter Definition, the byte sequence is calculated by using the parameters master_secret and client_random,server_random:

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

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

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

The values of master_key_len and master_salt_len, defined in the profile described by user_srtp. The profile used in our example is SRTP_AES128_CM_HMAC_SHA1_80, and the corresponding profile is configured as follows:

SRTP_AES128_CM_HMAC_SHA1_80 cipher: AES_128_CM cipher_key_length: 128cipher_salt_length: 1122maximum_lifetime: 2 ^ 31 auth_function: HMAC-SHA1 auth_key_length: 160auth_tag_length: 80

That is, we need a sequence of bytes (128 bytes 8 to 112 Universe 8) * 2 = 60 paces.

Export SRTP key

The byte sequence of SRTP encryption parameters is calculated in DTLS-SRTP 4.2. Key Derivation describes the meaning of a byte sequence:

Client_write_SRTP_master_ key [SRTPSecurityParams.master _ key_len]; / 128 bitsserver_write_SRTP_master_ key [SRTPSecurityParams.master _ key_len]; / 128 bitsclient_write_SRTP_master_ salt [SRTPSecurityParams.master _ salt_len]; / 112 bitsserver_write_SRTP_master_ salt [SRTPSecurityParams.master _ salt_len]; / 112 bits

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

DTLS timeout retransmission

DTLS is based on UDP, so packet loss is inevitable and needs to be retransmitted. If it is not handled properly, the entire communication parties will not be able to establish a session and the call will fail. RFC6347 4.2.4 gives the mechanism of timeout and retransmission. When dealing with retransmission, the following points should be noted:

In the DTLS protocol, in order to solve the problem of packet loss and retransmission, message_seq. When sending a DTLS retransmission message, be sure to update the message_seq in it, so that the peer will recognize the packet as a retransmission packet and respond to the correct message. Otherwise, the packets are silently discarded and do not respond.

When the server side receives the FINISHED message of the client and sends the FINISHED message to the client, the server status is updated to complete the negotiation, and the SRTP data is sent. At this point, a packet loss occurs in the FINISHED message sent to client. Client discards the SRTP data when it receives it. At the same time, send a FINISHED message to server,server again to respond correctly. Otherwise, it will lead to the false appearance that the DTLS negotiation is completed and the call fails.

With openssl version 1.1.1, the DTLS timeout retransmission time cannot be set, and the timeout retransmission mechanism is not available, so people start to use boringssl. Openssl 1.1.1 has supported setting DTLS timeout retransmission to achieve the same effect as boringssl. Reference DTLS_set_timer_cb

DTLS function of OpenSSL

DTLS is a huge protocol system, which includes a variety of encryption, signature, certificate, compression and other algorithms. Most projects are based on DTLS functionality implemented by OpenSSL or BoringSSL. The DTLS function of OpenSSL is used in the actual project, and the interfaces related to negotiation are summarized below.

X509_digest, which calculates the certificate fingerprint, and the fingerprint attribute used in SDP negotiation.

SSL_CTX_set_cipher_list, sets the cipher suite used, and affects the cipher list in Hello messages by setting the description of the algorithm.

SSL_CTX_set1_sigalgs_list sets the signature algorithm. The signature_algorithms extension in hello messages is affected by setting the description of the signature algorithm. Signature_algorithms to DTLS Hello message, KeyExchange,CerficateVerify message. If the signature_algorithms setting is incorrect, there will be internal error, so it is not easy to locate the problem.

SSL_CTX_set_verify sets whether the certificate of the peer is verified. Since self-signed certificates are used in most data cases in RTC, it is necessary to verify the identity of the certificate.

SSL_CTX_set_tlsext_use_srtp sets the srtp extension. Profile in the srtp extension affects the negotiation and extraction of keys used in srtp encryption.

SSL_set_options uses SSL_OP_NO_QUERY_MTU and [SSL_set_mtu] to set the size of the fragment. The default OpenSSL uses a smaller fragment. Through the above two interfaces, set the fragment suitable for the network situation.

DTLS_set_timer_cb, set the Callback for timeout retransmission, and let callback set a more reasonable timeout retransmission time.

The basic protocol of WebRTC has been supported in the open source project SRS. Students who are interested in DTLS protocol can quickly build a native environment based on SRS and further deepen their understanding of DTLS through debugging.

Thank you for your reading, the above is the content of "what is the DTLS protocol", after the study of this article, I believe you have a deeper understanding of what is the DTLS protocol, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.