49
$\begingroup$

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:

Improve this question
$\endgroup$
6
  • 3
    $\begingroup$ +5 Sometimes I wish we could give extra rep points for really good questions. Who would have thought, someone actually searched around and read related questions before posting :) $\endgroup$
    – mikeazo
    Commented Jul 24, 2015 at 16:46
  • $\begingroup$ @mikeazo Thanks *blush. It's not that I searched around, but rather that I'm quite active on security.se, and this has been bothering me for a while. $\endgroup$
    – Mike Ounsworth
    Commented Jul 24, 2015 at 17:26
  • $\begingroup$ What research have you done? Have you read the TLS spec? The official spec would be the obvious place to check, and I believe it's all defined in there. Reading questions here isn't a substitute for checking the primary sources. $\endgroup$
    – D.W.
    Commented Jul 24, 2015 at 19:36
  • 3
    $\begingroup$ Pre-master secret: tools.ietf.org/html/rfc5246#page-58. Computation of master secret, and how it differs from pre-master secret: tools.ietf.org/html/rfc5246#page-64. The session keys are defined and used in the record layer: tools.ietf.org/html/rfc5246#page-16. If you want to know how TLS works, reading the entire spec is a great exercise! $\endgroup$
    – D.W.
    Commented Jul 24, 2015 at 20:15
  • 1
    $\begingroup$ Part of this is answered at What is the purpose of four different secrets shared by client and server in SSL/TLS?. $\endgroup$
    – user10496
    Commented Sep 3, 2016 at 2:19

2 Answers 2

Reset to default
34
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ +1 Thanks! About "private keys"; I was under the impression that each party presented a premaster secret, and that if the server uses a Diffie-Hellman certificate, then it will always use the same premaster secret (somehow related to the cert). From your answer I am getting that there is only one premaster secret S, and the thing in the DH cert is R_bob. Is that correct? $\endgroup$
    – Mike Ounsworth
    Commented Jul 24, 2015 at 17:36
  • 1
    $\begingroup$ $R_{bob}$ would be a new random number every time, AFAIK. So it wouldn't be anything in the cert. Though things can change quite a bit for specific cipher suites. If there is a specific cipher suite you are interested in, I'd ask that as a separate question. My answer most relates to the RSA cipher suite. $\endgroup$
    – mikeazo
    Commented Jul 24, 2015 at 17:44
  • 1
    $\begingroup$ @MikeOunsworth DH certs are only used for "fixed" aka "static" (integer) DH which essentially nobody uses. The ECC equivalent is very rare. Fixed-[EC]DH combined with client authentication (also rare) does produce a fixed premaster secret, which is still handled by including nonces in the master secret derivation. What is common is ephemeral DH or ECDH, combined with cert-based authentication (RSA, DSS or ECDSA respectively); SSL/TLS spells these DHE and ECDHE. $\endgroup$
    – dave_thompson_085
    Commented Jul 24, 2015 at 23:37
8
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Ephemeral DH (DHE) keyexchange has been signed with RSA or DSA(DSS) using the server cert (and if applicable client cert) since SSLv3 in about 1999, and ephemeral ECDH (ECDHE) similarly since ECC was added in 2006; these are not "more modern". The only keyexchange with an ephemeral RSA key signed by the cert -- or even used at all -- is for some "EXPORT" suites which are only in versions before 2006 (and were widely discouraged before 2000). RSA signing of keyexchange (DHE-RSA or ECDHE-RSA) uses a nonstandard combination of MD5+SHA1 through TLSv1.1 and a negotiated hash in TLSv1.2. $\endgroup$
    – dave_thompson_085
    Commented Jul 24, 2015 at 23:40
  • $\begingroup$ @dave_thompson_085 Are there still situations in which the key on the server's cert is a Long-lived RSA not ephemeral which the client uses to encrypt and send a Pre-master secret to the server. Where the RSA key is not signed by the cert, it is the key on the cert? Or is that even older than the ephenumeral RSA you mentioned ? $\endgroup$
    – dylan7
    Commented Aug 1, 2015 at 4:02
  • 1
    $\begingroup$ Yes, "plain" RSA keyexchange is in all versions of the protocol and is still used, but many users and/or admins nowadays (post-Snowden and other public breaches) don't prefer it because it doesn't provide Forward Secrecy, and some prohibit it for that reason. I didn't make any criticism of that paragraph. $\endgroup$
    – dave_thompson_085
    Commented Aug 5, 2015 at 3:33
  • $\begingroup$ One more related question about this statement That Master secret is used to derive keys for symmetric encryption and MAC. If different session keys are generated for different purposes like to encrypt/decrypt data or for mac tags, then how the client knows which key to use? Or in other words, if multiple session keys can be generated out of the master key, then how both sides align on which "symmetric" key to use? $\endgroup$
    – stdout
    Commented Nov 16, 2019 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.