This is the 8th day of my participation in the August More text Challenge. For details, see: August More Text Challenge

When using ECDHE for encryption negotiation, the server needs to prove its identity and use the signature algorithm to sign the key exchange message. The commonly used signature algorithm is RSA and ECDSA.

ECDSA & RSA signature algorithm

During key negotiation, the server must use the agreed signature algorithm (ECDSA or RSA) to sign the negotiation information. A few things to note here:

  1. The signature algorithm of the server has nothing to do with the signature algorithm of the CA certificate, although they are both sent by the server. The CA certificate signature algorithm is determined by the authority that issues the certificate, and the server signature algorithm is selected by the server during key negotiation.

  2. The public key of the server is in the Subject Public Key INFO field of the first certificate in the TLS Certificate message. This public key is used to verify the signature when the server sends encryption parameters.

  1. When the server selects the ECDSA signature algorithm, its elliptic curve parameters are the same as the encryption algorithm ECDHE. The signature at the bottom is the signature encrypted by the server using the private key:

Let’s look at the RSA algorithm in detail

  1. The encryption basis of THE RSA algorithm is that “factorization of large integers is very difficult”. So far, no effective method has been found other than brute force cracking.

  2. Therefore, the RSA password strength is positively related to the length of its key, and the generally accepted secure length is 2,048 bits. As a result, the encryption and decryption efficiency of RSA is very low. The AES algorithm is more than 20 times faster than RSA.

  3. The RSA algorithm can be used for both encryption and signature. During the signature, you need to hash the source data to obtain a fixed length hash value, and then sign the private key to the hash value.

  4. The RSA signature algorithm is very simple: metadata hash^d%N= signature C; Verification process: Signature C^e%N= metadata hash, where the signature algorithm parameter (d,N) is a private key and is unique to the server. Verify that the public key (e,N) is transmitted to the client.

  5. How do RSA public keys and private keys come from?

    • The server and client select the same two large prime numbers p and q, calculate p*q=N, and the length of N is the key length (2,048 bit is recommended).
    • The euler function φ(N) = (p-1)(q-1) is calculated to determine the range of e, e is a random number between 1 and φ(N), and must be a positive integer that is mutually prime with φ(N).
    • Finally, d is calculated. D is the modular inverse element of E for φ(N), that is, D *e%φ(N)=1. By extending Euclidean’s algorithm, the modular inverse element D can be obtained.

ECDSA algorithm

Elliptic Curve Digital Signature Algorithm Elliptic Curve Digital Signature Algorithm Elliptic Curve Digital Signature Algorithm Elliptic Curve Digital Signature Algorithm Elliptic Curve

  1. The principle of elliptic curve algorithm is to select an origin G on A curve that satisfies y2 = x3 + ax + b, and randomly generate A private key D. The point G*d=A, which is also A point on the curve, is used as the public key.

  2. When the ECDSA is signed, the source data is hounded and the Signature operation is performed on the hash value Signature= Private key, hash(source data) (ECDSA). The signature itself contains two digits (R,S). When the client authenticates, insert the public key and S into the calculation. If R can be obtained, the signature is valid. The specific algorithm of ECDSA can refer to this article: How to read the ECDSA algorithm to protect data

  3. By applying elliptic curve parameters to DSA algorithm, the key length is greatly reduced. According to the data, the encryption strength of ECDSA 192bit is similar to that of RSA 1024bit. Meanwhile, the calculation amount is reduced and the transmission efficiency is enhanced.

MasterKey and Session Key

First of all, many articles end TLS1.2 key generation with the master key, which is incorrect.

  1. TLS1.2 The final session key is not the master key but the session key. The session key is generated from the master key. The following figure is taken from SECTION 6.3 of IETR RFC 5246:

  • The final keys used to encrypt the session are server_write_Key, client_write_Key, and server_write_MAC_key, client_write_MAC_key, which are responsible for integrity protection. Session key.
  1. First, the generation of the master key consists of three parts: Client Random + Server Random + pre-Master key. The three values are negotiated during each handshake, so the master key of a new session is different

  • Pseudo-random function (PRF) A pseudo-random function that extracts 48 bytes. The final master key is always 48 bytes in length. Once the master secret is generated, the pre Master secret should be deleted to prevent cracking.
  1. Generate session key: Expand the master key to a sequence of key bytes, Then, PRF operation is used to divide it into client write MAC key + Server write MAC key + Client write encryption key + server write encryption key. Key Material for AES block encryption

  1. AES is the Advanced Encryption Standard, which is a symmetric block cipher algorithm. The fixed block size is 128bit. The Key length supports 128bit to 10 rounds, 192bit to 12 rounds, and 256bit to 14 rounds. In each Round, Add Round Key, byte replacement, row shift, and column confusion are used to encrypt source data. Decryption is the inverse transformation of the above steps; The key block that we’re using here is the one we got from the session key calculation in the previous step.

  • Details about the AES algorithm can be referred to this article: “Cryptography Fundamentals: AES Encryption Algorithm”

  1. AES is used to do the final encryption because the efficiency and speed of symmetric encryption algorithm is much higher than that of asymmetric encryption, so it is the most suitable for application data transmission;

  2. The client uses MAC Secret to protect the integrity of the source data, and then encrypts the data packet using the client write Encryption key. After receiving ciphertext, the server uses the Client write Encryption key to decrypt the ciphertext, and then uses its own write MAC key to verify data integrity.

Finally, a key generation diagram of TLS1.2 is attached

The above is the TLS1.2 encryption negotiation algorithm knowledge, I will in the next article, through the actual TLS1.2 message packet details of the entire handshake process

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…

Cryptology foundation: AES encryption algorithm QiuJYu bbs.pediy.com/thread-2538…

Comics: The underlying principles of THE AES algorithm juejin.cn/post/684490…

“HTTPS key Calculation in TLS” Halfrost halfrost.com/https-key-c…