This is the seventh day of my participation in the August More Text Challenge. For details, see: August More Text Challenge **

At the heart of HTTPS is TLS, and at the heart of TLS is password negotiation and generation.

The process of key negotiation is the process of TLS handshake:

The figure above shows the detailed handshake steps of TLS1.2, focusing on the key negotiation steps:

  1. Client Hello provides three key information: Client Random Random code of the client, Cipher Suite password group for the server to select, signature Algorithm Signature algorithm for the server to know its capabilities.

  2. Server Hello provides two key information: Server Random server random code, cipher Suite selected password group (used for key negotiation, signature, and symmetric encryption)

  3. Certificate provides the public key, certificate chain, and signature of the server

  4. ServerKeyExchange provides: server-side key generation parameters (for clients to use to generate pre-master keys) and server signatures

  5. ClientKeyExchange provides: Client key generation parameters (let the server generate the same pre-master key)

  6. Both parties use the same parameters (Client Random + Server Random + pre-master key) to generate the master key respectively, and continue to calculate the session key according to the master key, and then use the symmetric encryption algorithm. Encrypts application data.

This article will cover the algorithms involved in the above steps.

ECDHE encryption negotiation

Let’s first take a look at the algorithms used in password negotiation. The most commonly used versions of TLS are 1.2 and 1.3, and their key negotiation mode is mainly ECDHE, which is the elliptic curve DH short password in Chinese

The purpose of ECDHE is to enable communication parties to negotiate a secure key under insecure communication conditions, and TLS uses this mechanism to generate pre-master keys.

“Forward safety”

Many HTTPS articles on the web are still talking about RSA asymmetric encryption to generate pre-master keys. This algorithm has long been abandoned because there is no “forward security” and if the server private key is breached, all previous ciphertext can be deciphered. At present, RSA algorithm is mostly used for signature, no longer for encryption.

The leakage of the Private key does not cause the leakage of the session key in the past. Forward security protects past communications from future exposure of passwords or keys, even if the system is actively attacked. Our hero today, ECDHE, has forward security.

Principle of THE ECDHE algorithm

  1. ECDHE is an improvement of DH algorithm (Diffie-Hellman), the core of which is “discrete logarithm”. A=g^ A (mod p), where if 0<= A <=p-1 is true, then the exponent A is said to be the discrete logarithm of the module P of A with base g. When the module P is A very large prime number, it’s very difficult to find A from what we know A, g, p;

  2. Based on this, the communication parties agree on G and p, and generate their own discrete logarithms A and b as private keys, send the calculated g^a%p= a, g^b%p= b as public keys to each other, and calculate a ^b%p, b ^a%p respectively. According to the exchange law of discrete logarithms, these two are equal, and this value is used as the communication encryption key. Then both parties have the same key without transmitting the key

  1. There are two types of DH negotiation algorithms. One is ephemeral, or DHE, which generates the common parameters G and p once a session is used up and then discarded. The next session generates new parameters to ensure “forward security”. The other is fixed, which is generated once for permanent use, not applied in the password system;

  2. The disadvantage of DHE is that the computation speed is slow. Because the encryption strength is positively correlated with the key length, the computation amount of DH algorithm is increasing, which puts great pressure on the server and bandwidth.

  3. At this time, EC elliptic curve algorithm appears. It applies elliptic curve mathematics on the basis of DH algorithm, and provides a considerable level of security through a small key length. For example, 256bit ECC encryption can reach DH 2048bit encryption strength, which greatly reduces the delay of encryption and decrypting.

  4. In the process of ECDHE key exchange, both parties agree on the elliptic curve parameter G, generate their private keys M and n, calculate the public keys mG and nG, and send them to each other. According to the elliptic permission algorithm, n*(mG)=m*(nG), the shared key of both parties can be obtained. In TLS, the pre-master key is generated in this way.

Another major flaw in the ECDHE algorithm is its inability to prevent “man-in-the-middle” attacks. If there is a “man in the middle”, posing as the other party to negotiate the key with both parties, the algorithm can be broken, so the DH algorithm does not actually prevent man-in-the-middle attack, and asymmetric encryption is needed for authentication. This is why TLS uses an authentication algorithm for key negotiation:

That’s the core of key negotiation, and in the next article we’ll detail the server signature algorithm and ultimately the application data encryption algorithm.

Thank you for reading. If there are any inaccuracies or errors, please leave a message and correct them. I will correct them immediately.




Summary is not easy, please do not reprint privately, otherwise don’t blame the old man you are welcome

Welcome technical friends to communicate with me, wechat 1296386616

References:

RSA algorithm is analysed past with carp zhuanlan.zhihu.com/p/375258787

COMPARISON AND EVALUATION OF DIGITAL SIGNATURE SCHEMES EMPLOYED IN NDN NETWORK by Al Imem Ali arxiv.org/ftp/arxiv/p…

How to protect the data is read ECDSA algorithm Datacruiser zhuanlan.zhihu.com/p/97953640

TLS1.2 PreMasterSecret And MasterSecret by old greens laoqingcai.com/tls1.2-prem…

The Transport Layer Security (TLS) Protocol Version 1.2 datatracker.ietf.org/doc/html/rf…