51

Both crypto.SE and security.SE have excellent Q&As about how TLS generates session keys (I have linked some at the bottom).

In reading these threads I'm having troubles with terminology since the following terms seem to be used with overlapping contexts, though they are clearly different concepts. Reading definitions is only partially helpful since they don't show the differences between their usages.

  • pre-master secret
  • master secret
  • private key
  • shared secret / session key

As I understand it, the pre-master secret is related to private keys, but is algorithm independent, and the master secret is (often?) used as the session key. But I'm sure there's more nuance to the definitions.


Related Questions:

Mike Ounsworth
  • 3,717
  • 1
  • 20
  • 29

2 Answers2

34

Simplified SSLv3/TLS Simplified SSLv3/TLS from this book Note, $R_{(Alice|Bob)}$ is a random nonce chosen by Alice or Bob respectively, and $\{S\}_{Bob}$ is encryption with Bob's public key.

pre-master secret

As stated in one of the answer you link to, "The point of a premaster secret is to provide greater consistency between TLS cipher suites."

In the figure above, the premaster secret is $S$ (in message 3). In this case, it is randomly generated. It could come from a diffie-hellman exchange, or some other method, depending on the agreed upon cipher suite.

It isn't really "related to the private keys" but how it is generated/agreed upon depends on the cipher suite chosen in the second message of the figure.

master secret

In the figure above, the master secret is $K$. Shown on the sides, it is a function of the pre-master secret and the two random values sent in the first two messages.

private key

I'm not really sure where this comes from. It could refer to the Bob's private key for the certificate sent in message 2. It could also refer to private keys used in a diffie-hellman key exchange. If doing client authentication, it could refer to the client's private key associated with their certificate.

shared secret / session key

This is what is referred to in the last step of the figure. The session key is referred to as "keys derived from K". Many keys are actually derived from K. This could be the encryption key, integrity protection keys (for say HMAC), IVs for the ciphers, etc. And, it is usually a different set for each direction.

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
mikeazo
  • 39,117
  • 9
  • 118
  • 183
8

When a TLS/SSL session starts (after the hellos and cipher decisions) the server gives the client its cert. The key in the cert could perform different actions depending on the key agreement algorithm decided on by the client and server.

Let's say they agree on the RSA key agreement. This means the cert contains the server's public RSA key and the server has a private RSA key used for decryption, hence private key. The client generates a random sequence called the pre-master secret. The client uses the public RSA key on the cert to encrypt the PMS. The server decrypts the message and gets the PMS. The server and client then perform some random mixing on the PMS, which could be a KDF. That master secret is used to derive keys for symmetric encryption and MAC.

Another option: The server and client could perform Diffie-Hellman key exchange in which the client must also generate a public-private DH pair used to exchange AND generate (due to the way DH works the client doesn't choose the PMS) the PMS. The master secret is derived as above. A more modern approach is to use session keys in which the server cert contains its public key for verifying a signature algorithm (RSA-SHA, ECDSA) that it used to sign either an RSA or DHE (the E stands for "ephemeral" and means one-time use keys or session keys) public key for key agreement. Thus the server is not reusing its key agreement public key. This provides perfect forward secrecy: Finding the PriK (long-lived key) of the signature algorithm the server uses to sign its keys does not make all the session keys vulnerable. In addition, finding a session key should allow you to obtain information that would allow you to decrypt traffic that used another session key (the PMS could also be considered a "session key").

You could look up PKI to understand more about how cert verification works which I did not explain. This is where the client makes sure the cert is valid.

Asymmetric crypto is used for key agreement (keys are smaller than messages) due to the high processing power required and symmetric crypto is used for encryption and authentication of the resulting ciphertext. Also, the term key agreement is different than key exchange (more general). Key agreement means that there is no trusted third party involved in the actual exchange of keys, which is true in the case of SSL/TLS.

kelalaka
  • 49,797
  • 12
  • 123
  • 211
dylan7
  • 551
  • 4
  • 10