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

1.DTLS introduction

1.1 the role of DTLS

At the beginning, Internet pioneers mainly considered usability when designing Internet protocols, and security was not considered in it, so the TCP and UDP protocols of the transport layer do not have security. Based on TCP socket, SSL/TLS protocol constructs an end-to-end secure channel between the transport layer and the application layer, which ensures the encryption of the transmitted data.

However, SSL/TLS protocol can not be used in UDP protocol, and UDP also has the need of secure transmission, so the DTLS protocol (Datagram TLS) is produced.

That is, the role of DTLS is to provide an end-to-end secure channel for UDP, just as SSL/TLS does for TCP. And DTLS refers to the security mechanism of SSL/TLS protocol as much as possible, and reuses 70% of the TLS code on the specific implementation.

1.2 Features of DTLS

UDP protocol is an unreliable protocol that is not connection-oriented, and does not encrypt the message segment, so it can not guarantee the identity authentication of both sides of the communication, the sequential reception in the process of message transmission, no loss and encrypted transmission.

On the other hand, the DTLS protocol realizes the handshake connection between the client and the server based on the socket provided by UDP, and realizes the encryption by using PSK or ECC in the handshake process, and uses the cookie authentication mechanism and certificate to realize the identity authentication of both sides of the communication, and uses the sequence number in the header of the message segment to cache the disordered message segment and the retransmission mechanism to achieve reliable transmission.

After the completion of the handshake, both sides of the communication can achieve secure encryption and reliable transmission of application data.

1.3 DTLS protocol level

The DLTS protocol is divided into two layers, the lower layer is the recording layer (recording layer), and the content of the record packet is divided into two parts: the header and the load. The load of the recording package is the content of the upper layer. There are three types of packets in the upper layer of DTLS, namely, handshake messages, warning messages, and application data, as shown in figure 1.

Figure 1. Hierarchy of DTLS protocol

In the whole communication process of DTLS protocol, the process of constructing the message segment is to generate the upper layer payload message (such as handshake message, application data, warning message), and then add a header to form a complete upper layer message. Then use this as the load of the recording layer, finally add the head of the recording layer to form a complete recording message segment, and finally call the socket interface of UDP to send it to the other party.

The encryption process is to encrypt only the payload of the recording layer (that is, the upper layer message, the encrypted message in this protocol is finished message and application data), so after receiving the recording message, the receiver should first determine whether the recording message is encrypted by the sender. If so, it should be decrypted before the plaintext data can be read for later processing.

2.DTLS transmission phase

2.1 the interaction process throughout the handshake phase

The transmission phase of DTLS is divided into two stages: the handshake phase and the application data transmission phase after the handshake is established.

The handshake phase of DTLS is shown in figure 2:

Figure II. Interaction process of DTLS protocol client shaking hands with server

The client initiates a connection to the server, and the server can choose whether to validate the client's cookie and certificate (that is, whether to send client_hello_verify and certificate_request message segments to the client) based on the configuration.

2.2 cookie authentication mechanism for DTLS

Because DTLS is based on UDP, it may suffer from two forms of denial of service *. One is similar to the resource consumption of TCP, and the other is to enlarge *, that is, the malicious * * sends a communication initialization message segment to the server by imitating the IP address of the victim, and the server will return a much larger certificate to the victim. A large number of certificates may cause paralysis of the victim.

The cookie mechanism requires the client to repeat the cookie value sent before the server to verify that the source IP address of the communicating party can actually communicate, thus reducing the harm of denial of service.

The specific mechanisms for cookie authentication are:

The protocol specifies that the first message segment sent by the client, client_hello, contains the value of cookie (possibly empty). The server verifies the cookie value in the received message segment. If the cookie is empty, the connection has not been established before. The server randomly generates a cookie through the hash method according to the source IP address of the client, and fills it into the client_hello_verify and sends it to the client.

The client then fills in the cookie sent before the server in the client_hello message segment sent by the server for the second time. After receiving the message segment for the second time, the server checks whether the cookie value in the message segment is exactly the same as the cookie value previously sent to the host by the server. If so, the handshake connection continues through cookie verification; if not, the connection is refused to establish.

2.3 contents of client_hello message segments and server_hello message segments

In addition to cookie, there are 32 bytes of random numbers generated by the client in the client_hello message segment, in which the first 4 bytes are timestamps and the last 28 bytes are random numbers generated by the system. In addition, the message segment contains client-supported encryption methods (PSK or ECC) and compression methods for the server to choose from.

After passing the cookie check, the server sends the server_hello message segment to the client. The message segment contains a 32-byte random number generated by the server and the encryption and compression selected by the server for subsequent sessions.

2.4 contents of the certificate message paragraph

The certificate message segment sent by the server to the client contains the public key of the server certificate; after the client receives the message segment, according to the protocol, the public key of the server certificate is read from the corresponding position of the message segment and stored in the relevant variables.

2.5 ECDH secret key exchange protocol and ECDSA digital signature algorithm based on ECC encryption

If the encryption method chosen by the protocol is ECC (elliptic curve encryption), ECDH (elliptic curve secret key exchange protocol) and ECDSA (elliptic curve digital signature algorithm) will be used in the construction of server_key_exchange message segment. ECDH and ECDSA are the combination of ECC and DH (diffie-hellman) secret key exchange protocol and DSA (digital signature algorithm) respectively.

The server_key_exchange message segment contains the XMagney coordinates of the selected elliptic curve E, order N and base point G. after receiving this message segment, the client verifies the corresponding format and reads the data, so the server and the client jointly obtain the agreed parameters for the ECDH secret key negotiation exchange protocol, so that they can jointly negotiate the same dialogue key for the encrypted session content.

At the same time, in order to prevent the middleman, the server also signs the whole message segment with ECDSA at the end of the server_key_exchange message segment. The specific signature process is to first use two 32-byte random numbers in the client_hello message segment and the server_hello message segment as function parameters, use the sha256 hash algorithm to generate a summary of the load of the server_key_exchange message segment itself, and then use the server's private key and sha256 hash algorithm to carry out the ECDSA digital signature, get the signature results r and s, and write to the end of the server_key_exchange message segment.

After receiving the server_key_exchange message segment, the client first verifies the format of each numerical item, and then extracts the signature values r and s at the end of the message segment. After that, the ECDSA signature verification of the server_key_exchange message segment is carried out with the XMagney coordinate value of the public key of the read server. If the result is consistent with the r and s values in the message segment, the message segment passes the verification.

2.6 identity authentication process and session key generation process based on PSK encryption

The encryption mode of the whole DTLS protocol can choose ECC or PSK (pre-shared key, PreSharedKey). In the case of ECC, the secret key negotiation between the two sides of the communication is carried out through the ECDH protocol; if it is PSK, the encrypted communication is carried out directly on the basis of the secret key agreed by both parties in advance.

For PSK encrypted communication, it is critical to verify the communication identity of the other party. Therefore, both sides of the communication will access each other's psk_id (identity flag) and psk_id_length (identity flag length) locally, and verify each other's identity by comparing the psk_id,psk_id_length in the received message segment with that stored locally.

In the whole communication process, the difference between PSK and ECC is mainly reflected in the different contents of server_key_exchange message segment and client_key_exchange message segment and the different ways in which the two parties calculate the pre-master key.

When using PSK encryption, the contents of the server_key_exchange message segment and the client_key_exchange message segment are the psk_id and psk_id_length of the server and the client respectively, so that both parties can know each other's psk_id and psk_id_length.

After that, both parties will verify the received message segments, and the subsequent communication will take place only if the psk_id and psk_id_length are exactly the same as the local storage.

When both parties pass the authentication, both parties use the same function to generate the pre-master key, and the parameters of the function include the 32-byte random number generated by each of the two parties in the previous communication phase, thus ensuring that although the psk key stored locally remains unchanged, the session key will always change during each temporary communication, thus enhancing the anti-*.

After the pre-master key is generated by both parties, the master key is generated by calling and using ECC encryption in the same way, that is, the symmetric key for subsequent session communication. The 32-byte random number generated by both parties will still be used in this process.

As a result, both sides of the communication use PSK encryption to achieve identity authentication and session key generation.

2.7 contents of server_hello_done message segments and client_key_exchange message segments

The payload part of the server_hello_done message segment sent by the server is empty and is only sent to the client as a sign that the message segment of the current stage of the server has been sent.

After receiving the server_hello_done message segment, the client sends the client_key_exchange message segment to the server, which contains the x-ray coordinates of the base point used for secret key negotiation, and unlike the server_key_exchange message segment, the client does not sign the ECDSA at the end of the message segment.

2.8 the client generates the session key

The client then uses the ecdh_pre_master_secret function to generate the pre-master key for subsequent sessions. The parameters of the function include the client's own private key and the XMagi y coordinates of the base point shared by the server for the ECDH key negotiation algorithm.

After the pre-master key is generated, the master key master_secret is generated according to the 32-byte random number generated by the client and the server in the previous stage, and the master key is a symmetric key, which is used for the encryption and decryption of the subsequent session.

2.9 contents of change_cipher_spec and finished message segments

After the client calculates the session key, it sends the change_cipher_spec message segment to the server. the payload of this message segment is empty and is used as a flag to notify the server that the client has calculated the master key, and then the message segment sent is encrypted with the master key.

The last message segment sent by the client in the handshake phase is the finished message segment, and the payload content is the MAC value (message authentication code), which is used to authenticate the server. It is also worth noting that the finished message segment, as the payload part of the recording layer, has been encrypted and encoded with the session key generated in the previous step.

2.10 the server generates the session key

After receiving the finished message segment sent by the client, the server and the client use the ECDH key negotiation algorithm to go through the same process and call the same function to generate the pre-master key first, and then generate the master key.

2.11 end of the handshake phase

Finally, the server generates a finished message segment encrypted by the session key to the client, marking the end of the whole handshake phase.

After the client receives the finished message segment from the server, it can send the application data. And the application data will always be encrypted with the session key, thus achieving the security that UDP does not have.

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.