1. Introduction
Keys are critical in cryptographic operations in public-key infrastructure (PKI). SSL handshakes involve exchanging several pieces of information, such as public keys, private keys, shared secrets, pre-master secrets, and master secrets.
Let’s explore what happens between the key exchange and the data encryption and authentication.
2. SSL/TLS Handshake
A secure SSL/TLS connection gets established in multiple steps. The client and the server must agree on the methods and data to share.
We’ll use a TLS 1.2 connection to illustrate this complex process. The method employed for all prior SSL/TLS versions is the same.
The handshake initiates and establishes a secure connection between the server and the client:
The handshake involves the following:
- Client Hello: This is a hello message from the client to the server having information such as client version, client random, session ID, cipher suites, compression methods, and extensions
- Server Hello: This is a reply message from the server to the client having server version, server random, session ID, cipher suites, compression methods, and extensions
- Exchange Certificate: The server sends a signed TLS/SSL certificate and the server’s public key to prove its identity. Sometimes, the server may also require the client to authenticate with a certificate and seek the same from the client
- Server Hello Done: Server sends this message to the client to confirm that the server hello message has been executed and completed
- Client Key Exchange: This message is sent by the client once it receives the server hello done from the server. At this point, the client creates a pre-master secret. If the server’s certificate is insufficient for the client to share a pre-master secret, then the client needs a server key exchange message. The client and the server create the master secret key
- Change Cipher spec: This protocol initiates symmetric encryption for data exchange using the shared keys
- Handshake Finished: The handshake process from both the client and server sides exchanges this message at the end.
Asymmetric and symmetric encryption is part of the SSL/TLS security protocols. Keys and secrets are for encryption, decryption, and authentication. In the rest of the article, we’ll cover details about when we use different keys.
3. SSL/TLS Keys
Let’s now discuss how the shared secret, pre-master secret, master secret, public key, and private keys work.
3.1. Shared Secret
Generally, a shared secret is to generate one or more keys for message encryption and to authenticate users.
In cryptography, this is a piece of information that is known only to the participating systems:
The client and the server generate a public/private key pair and share each other’s public keys as per the Diffie-Hellman key exchange protocol. Afterward, they can compute a shared secret offline.
It usually refers to the key of a symmetric cryptosystem, in which the same key encrypts and decrypts data.
Generally, we use the shared secret and an initialization vector (IV) to create the session and message keys. Lastly, a shared secret can be a password, passphrase, large integer, or a collection of bytes selected at random.
3.2. Public Key
The primary function of a public key is to encrypt messages before sending them.
An asymmetric cryptosystem uses randomly generated public and private keys. Anybody can encrypt data using a public key, but only those with the corresponding private key can decode the data.
The public and private keys are mathematically related. Only a related key pair can encrypt and decrypt data. The encrypted information will be unreadable if the corresponding private key for decryption is missing.
In PKI, the sender and receiver don’t share the same key. PKI is used only for short messages.
3.3. Private Key
The private key is kept secret and is only accessible by the owner.
In a symmetric cryptosystem, the same key (secret key) is used for encryption and decryption. In this cryptography scheme, the sender and receiver share the same key.
Furthermore, a private key decrypts the cipher text in the asymmetric cryptosystem. A digital signature created using the private key can be confirmed using the associated public key. A private key is faster than a public key and applicable to high-volume text content.
3.4. Pre-master Secret
The client generates a 48-bit pre-master secret and sends it to the server mainly to compute master secrets.
The client encrypts the pre-master secret using the server public key obtained from the server’s certificate. The server decrypts the message using the private key. The client and the server use the pre-master secret to produce the symmetric keys for the secured portion of the session.
The algorithm and parameters used during the data exchange affect the length of the message. We want a fixed-length value to derive the keys for any cipher suite. The pre-master secrets serve this purpose.
3.5. Master Secret
The client and server use the master secret to generate the session key.
The server decrypts the pre-master secret key using its private key after receiving it.
The client and the server use a Pseudo-Random Function (PRF) to calculate the master secret key. PRF is a deterministic algorithm with two inputs and a single output. PRF obtains its result by iterating a hash-based message authentication code (HMAC) based on the SHA256 hash function.
Let’s discuss how the pre-master secret creates the master secret key. The RFC guideline to calculate the fixed-length value master secret using the pre-master secret is:
The master secret is a function of the client and server randoms that were previously exchanged between the client and the server during the handshake stage.
Further, the first three inputs to PRF are string representations of byte sequences. So, the addition operator in the above code concatenates the random. A master secret key is 48 bytes long and computed using random values.
4. When to Use Different Keys?
The following table shows at what stage of communication between client and server the shared secret, pre-master secret, public key, private key, and master secret are used:
Stage
Keys Involved
Client-server hello
Shared secret (Session ID)
Certificate exchange
Server’s public key
Client key exchange
The client creates a pre-master secret and uses a public key to encrypt it, while the server uses its private key to decrypt it
Server key exchange
Optional – required only if the server’s certificate is insufficient for authentication
Post handshake
Both client and server use master secret for symmetric encryption/decryption
5. Conclusion
In this article, we talked about SSL handshakes, shared secrets, pre-master secrets, master secrets, and public/private keys.
A key-agreement technique, such as PKI, is used to construct the shared secret at the beginning of the SSL/TLS communication session. The server uses its public key for encryption and its private key for decryption.
Once the client and the server receive a hello done message, the client sends a pre-master secret to the server to compute a master secret using PRF.
Lastly, after the handshake, for the rest of the session, the client and the server use the master secret to generate the session keys for symmetric data encryption/decryption.