My conclusion: The handshake of DTLS is to negotiate a symmetric encryption key (each client's key will be different), and the subsequent communication will use this key for encrypted communication. The negotiation process either uses an asymmetric encryption algorithm to verify the identity of the signature, or the client and the server store each other's information to compare and verify the identity.
1. Introduction to DTLS
1.1 The role of DTLS
The Internet pioneers first considered availability when designing Internet protocols, and did not take security into account, so the TCP and UDP protocols at the transport layer themselves do not have security. The SSL/TLS protocol is based on TCP socket, and uses encryption, digital certificate-based authentication and other mechanisms to build an end-to-end secure channel between the transport layer and the application layer to ensure the encryption of transmitted data.
However, the SSL/TLS protocol cannot be used for the UDP protocol, and UDP also has the need for secure transmission, so the DTLS protocol (Datagram TLS) was born.
That is, the role of DTLS is to provide an end-to-end secure channel for UDP, just as SSL/TLS does to TCP. And DTLS refers to the security mechanism of the SSL/TLS protocol as much as possible, and reuses 70% of the TLS code in the specific implementation.
1.2 Features of DTLS
The UDP protocol is an unreliable protocol that is not connection-oriented, and does not encrypt the transmitted segments, so it cannot guarantee the identity authentication of both parties, the in-order reception, loss-free and encrypted transmission during message transmission.
The DTLS protocol realizes the handshake connection between the client and the server on the socket provided by UDP, and realizes the encryption by using PSK or ECC during the handshake process, and uses the cookie verification mechanism and certificate to realize the identity authentication of both parties. In addition, the sequence number is added to the header of the message segment, the message segment that arrives out of sequence is cached, and the retransmission mechanism realizes reliable transmission.
After the handshake is completed, the two communicating parties can use the negotiated session key during the handshake phase to encrypt and decrypt application data.
1.3 DTLS protocol layer
The DLTS protocol is divided into two layers, the lower layer is the record layer (record layer), and the content of the record packet is divided into two parts: the header and the payload. The payload of the record packet 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.
图一.DTLS协议的层次In the entire communication process of the DTLS protocol, the process of constructing a segment by both parties is to first generate upper-layer payload messages (such as handshake messages, application data, and warning messages), and then add headers to form a complete upper-layer message. Then use this as the payload of the record layer, and finally add the header of the record layer to form a complete record segment, and finally call the UDP socket interface and send it to the other party.
The encryption process is to encrypt only the payload of the record layer (that is, the upper layer message, the encrypted message in this protocol is the finished message and the application data), so after the receiver receives the record message, the first thing to do is to judge the record. Whether the message is encrypted by the sender, if so, it should be decrypted before the plaintext data can be read for subsequent processing.
2. The handshake process for the client/server to establish a DTLS connection
2.1 The interaction process of the entire handshake phase
The transmission phase of DTLS is divided into two phases: the handshake phase and the transmission application data phase after the handshake is established.
The handshake phase of DTLS is shown in Figure 2 below:
图二.DTLS协议客户机与服务器握手阶段的交互过程The client initiates a connection to the server, and the server can choose whether to verify the client's cookie and certificate according to the configuration (that is, whether to send the client_hello_verify and certificate_request message segments to the client).
2.2 DTLS cookie verification mechanism
Since DTLS is based on UDP, it can suffer from two forms of denial of service attacks. One is a resource consumption attack similar to TCP, and the other is an amplification attack, that is, a malicious attacker imitates the IP address of the attacker to send a communication initialization segment to the server, and the server returns a much larger certificate to the server. For the attacker, an excessively large number of certificates may cause the attacker to be paralyzed.
The cookie mechanism requires the client to repeatedly send the cookie value sent by the server to verify that the source IP address of the communicating party can indeed communicate, thereby reducing the harm of denial of service attacks.
The specific mechanism of cookie authentication is: the
protocol stipulates that the first segment client_hello sent by the client contains the value of the cookie (it may be empty). The server checks the cookie value in the received segment. If the cookie is empty, it means that no connection has been established before. The server randomly generates a cookie based on the client's source IP address through a hash method, and fills it in client_hello_verify to send to the client.
The client then fills in the cookie sent by the server in the client_hello segment sent for the second time. After the server receives the segment for the second time, it checks the cookie value in the segment and the server sent it to the host before. Whether the cookie values are exactly the same, if so, pass the cookie verification and continue the handshake connection; if not, refuse to establish the connection.
2.3 Contents of client_hello segment and server_hello segment
In addition to the cookie, the content of the client_hello segment includes a 32-byte random number generated by the client, of which the first 4 bytes are the timestamp and the last 28 bytes are the random number generated by the system. In addition, the content of this segment also includes the encryption method (PSK or ECC) and compression method supported by the client for the server to choose.
After passing the cookie verification, the server sends the server_hello segment to the client. This segment contains a 32-byte random number generated by the server, and the encryption method and compression method selected by the server for subsequent sessions.
2.4 Contents of the certificate segment
The certificate segment sent by the server to the client contains the public key of the server certificate; after receiving the segment, the client reads the public key of the server certificate from the corresponding position of the segment according to the protocol. The key is stored in the relevant variable. The client uses this public key to verify whether the next server_key_exchange message from the server is valid.
2.5 ECDH key exchange protocol and ECDSA digital signature algorithm based on ECC encryption
If the encryption method selected by the protocol is ECC (elliptic curve encryption), ECDH (elliptic curve key exchange protocol) and ECDSA (elliptic curve digital signature algorithm) are used in the construction of the server_key_exchange segment. ECDH and ECDSA are the combination of ECC and DH (diffie-hellman) key exchange protocol and DSA (Digital Signature Algorithm) respectively.
ECDSA: used for digital signature, it is a combination of ECC and DSA. The entire signature process is similar to DSA, but the difference is that the algorithm used in the signature is ECC, and the final signed value is also divided into r and s.
ECDH: It is a DH (Diffie-Hellman) key exchange algorithm based on ECC (Elliptic Curve Cryptosystems, elliptic curve cryptosystem, see ECC).
ECDH uses:
Because through ECDH, both parties can negotiate a shared secret without sharing any secret. Therefore, ECDH is widely used in the protocol, and the symmetric encryption key is obtained through ECDH. Such as *_ECDH_* cipher suites in TLS. protocol using DH algorithm
It can be upgraded to ECDH algorithm. ECDH has the advantages of high strength, short key length, and fast calculation speed of ECC.
Key exchange process:
Assume that the two parties to the key exchange are Alice and Bob, who have shared curve parameters (elliptic curve E, order N, base point G).
1.Alice generates a random integer a and calculates A=a*G. Bob generates a random integer b and calculates B=b*G.
2. Alice passes A to Bob. The delivery of A can be made public, i.e. an attacker can obtain A. Since the discrete logarithm problem of elliptic curves is a difficult problem, the attacker cannot calculate a through A and G. Bob passes B to Alice. Similarly, the transfer of B can be made public.
3. Bob receives A from Alice and calculates Q=b*A
4. Alice receives B passed by Bob and calculates Q'=a*B
Summary:
Both Alice and Bob get Q=b*A=b*(a*G)=(b*a)*G=(a*b)*G=a*(b*G)=a*B=Q' (commutative law and associative law), that is, both parties obtain a consistent key Q.
The server_key_exchange segment contains the selected elliptic curve E, order N, and x, y coordinates of the base point G. After receiving this segment, the client performs the corresponding format check and reads the data, so The server and the client jointly obtain the agreed parameters for the ECDH key negotiation and exchange protocol, so that the same session key (symmetric encryption key) can be jointly negotiated for the encrypted session content.
At the same time, in order to prevent man-in-the-middle attacks, the server also performs an ECDSA digital signature on the entire segment at the end of the server_key_exchange segment. The specific signature process is to first use the client_hello segment and the two 32-byte random numbers in the server_hello segment as function parameters, and use the sha256 hash algorithm to generate a summary of the payload of the server_key_exchange segment itself, and then use the server's The private key and sha256 hash algorithm perform ECDSA digital signature to obtain the signature results r and s, and write them at the end of the server_key_exchange segment.
After the client receives the server_key_exchange segment, it first checks the format of each numerical item, and then extracts the signature values r and s at the end of the segment. After that, use the x and y coordinate values of the public key of the server that have been read to perform ECDSA signature verification on the server_key_exchange segment. If the result is consistent with the r and s values in the segment, the segment passes the verification.
2.6 Identity authentication process and session key generation process based on PSK encryption
The encryption method of the entire DTLS protocol can be ECC or PSK (PreSharedKey). If it is ECC, the key negotiation between the two communication parties is carried out through the ECDH protocol; if it is PSK, the encrypted communication is directly based on the key that has been agreed upon by the two communication parties in advance.
For PSK encrypted communication, it is very critical to verify the communication identity of the other party. Therefore, both parties in the communication will locally access each other's psk_id (namely the identity mark) and psk_id_length (the length of the identity mark), and verify the identity of the other party by comparing the psk_id, psk_id_length in the received segment with the locally stored ones. .
In the whole communication process, the difference between using PSK and ECC is mainly reflected in the difference in the content of the server_key_exchange segment, the client_key_exchange segment and the way the two parties calculate the pre-master key.
When using PSK encryption, the contents of the server_key_exchange segment and the client_key_exchange 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 check the received segment, and only the psk_id and psk_id_length are completely consistent with the local storage before the subsequent communication.
After both parties have passed the authentication, both parties will use the same function to generate the pre-master secret key, and the parameters of the function include the 32-byte random numbers generated by both parties in the previous communication stage, thus ensuring that although the locally stored psk The secret key does not change, but the session secret key will always change for each temporary communication, thus enhancing the anti-attack.
After the two parties generate the pre-master key, they call and use the same method of ECC encryption to generate the master key, that is, the symmetric key used for subsequent session communication. The 32-byte random number generated by both parties will still be used in this process. .
Therefore, both parties of the communication use the PSK encryption method to realize the identity authentication and the generation of the session key.
2.7 Contents of server_hello_done segment and client_key_exchange segment
The payload part of the server_hello_done message segment sent by the server is empty, and it is only sent to the client as a flag, indicating that the message segment of the current stage of the server has been sent.
After receiving the server_hello_done segment, the client sends the client_key_exchange segment to the server, which contains the x and y coordinates of the base point used for key negotiation (equivalent to Bob's B), and is different from the server_key_exchange segment. The client does not perform an ECDSA digital signature at the end of the segment.
2.8 Client generates session key
After that, the client generates a pre-master secret for subsequent sessions through the ecdh_pre_master_secret function. The parameters of the function include the client's own private key , and the x and y coordinates of the base point of the ECDH key agreement algorithm shared with the server (I think it should be Bob's b (whether it is the client's own private key). key) and get A) from the server_key_exchange segment .
After the pre-master secret key is generated, the master secret key master_secret is generated according to the 32-byte random numbers generated by the client and the server respectively in the previous stage. At this time, the master secret key is a symmetric secret key, which is used for encryption and decryption of subsequent sessions.
2.9 Contents of change_cipher_spec segment and finished segment
After the client calculates the session key, it sends the change_cipher_spec segment to the server. The payload of this segment is empty, which is used as a flag to notify the server, indicating that the client has calculated the master key, and the segment sent later will be Encrypted with master key.
The last segment sent by the client in the handshake phase is the finished segment, and the payload content is the MAC value (message verification code), which is used for authentication to the server. And it is worth noting that the finished segment as the payload part of the record layer has been encrypted and encoded with the session key generated in the previous step.
2.10 Server generates session key
After the server receives the finished segment sent by the client, it will go through the same process as the client using the ECDH key negotiation algorithm, and call the same function to generate the pre-master key first, and then the master key.
2.11 End of handshake phase
Finally, the server generates a finished segment encrypted by the session key to the client, marking the end of the entire handshake phase.
After the client receives the finished segment sent by the server, it can send application data. And the application data will always be encrypted with the session key, thus realizing the security that UDP does not have.