Learn through the super-clean Baeldung Pro experience:
>> Membership and Baeldung Pro.
No ads, dark-mode and 6 months free of IntelliJ Idea Ultimate to start with.
Last updated: March 18, 2024
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.
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:
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.
Let’s now discuss how the shared secret, pre-master secret, master secret, public key, and private keys work.
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.
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.
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.
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.
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.
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 |
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.