0

In TLS 1.3 (RFC8446), there are many secrets and keys. As far as I've understood, every certificate (usually only the server) has a long term key associated with it which is used with HKDF to generate a temporary key for the certificate verify part of the server response in the handshake. This made me wonder how the base key for the session key is derrived.

Are there long term keys which are used (probably with a KDF) to generate the shared session key (or more to be precice, to generate the key shares used to generate the session key)? Or are these ephemeral keys that are generated for every session?

1 Answer 1

1

There are two different handshake modes.

Usually, the Diffie-Hellman key exchange algorithm is used to derive an ephemeral shared secret. This secret is not derived from the private key of the certificate. Instead, the server uses its private key only to sign the messages of the handshake (which include the Diffie-Hellman parameters). Based on the shared secret, client and server both calculate the Handshake Secret and then the Master Secret using HKDF. The Master Secret in turn is used to derive the actual keys for symmetric encryption of the traffic.

Alternatively, the pre-shared key (PSK) mode can be chosen, if client and server already have a shared secret, either from a previous TLS session or through some out-of-band agreement. In this case, the Master Secret can be derived directly from the PSK, or the PSK can be combined with a Diffie-Hellman key exchange to produce an ephemeral secret.

Generating the Master Secret directly from a long-term PSK should be avoided, because if the PSK is compromised, all prior TLS traffic can be decrypted. In contrast, when ephemeral keys are generated using Diffie-Hellman, an attacker who compromises the server's private key and/or the PSK still cannot decrypt past TLS traffic (so-called Forward Secrecy).

1
  • 1
    Nit: in 1.2 and below server signs the ServerKX message body, which is effectively always [FF|EC]DHE group and server pubkey. (Technically in 1.0 it can be a temp RSA pubkey for the ancient 'export' suites, but those have been deprecated or prohibited for decades.) In 1.3 server signs (a hash of) the transcript so far, which includes ClientHello and ServerHello (including the key_share values in each) and EncryptedExtensions and Certificate. May 31 at 0:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .