1
$\begingroup$

In the TLS 1.2 handshake, after checking the certificate, the public key from the certificate was used to encrypt the data to create a symmetric encryption key, hence the authentication took place on the factor of knowing the private key, as it is needed to decrypt that data.

In TLS 1.3, the public key cannot be used to encrypt data needed to create a symmetric encryption key because this data is included in the first message sent by the client and the client cannot know the public key until it receives the certificate that the server sends in response to the first message.

Since the public key is not used to encrypt data needed to generate a symmetric encryption key or any other data the private key knowledge factor disappears.

How does TLS 1.3 provide authentication and what is the point of using PKI and Public Key Certificate if the public key is not used to verify that the party has a private key?

$\endgroup$

2 Answers 2

5
$\begingroup$

... the public key from the certificate was used to encrypt the data to create a symmetric encryption key, hence the authentication took place on the factor of knowing the private key, as it is needed to decrypt that data.

This was not the authentication. What you describe is the RSA key exchange, which was removed in TLS 1.3 and is even considered obsolete with TLS 1.2.

The proof that the server knows the private key is instead done with the CertificateVerify message, which is (slightly simplified) a signature (using the private key) over the messages previously send in the handshake. This means it also includes client side random data and thus can not be simply replayed within another handshake.

$\endgroup$
5
  • $\begingroup$ The party whose authenticity is being verified sends: * Certificate - the party's certificate chain. * CertificateVerify - a digital signature made with a private key based on a Transcript-Hash(Handshake Context, Certificate) and the algorithm by which this digital signature is made. Then, the other party verifies the certificate chain and uses the public key from the certificate to verify the electronic signature from CertificateVerify, right? $\endgroup$ Nov 7, 2022 at 18:37
  • $\begingroup$ @NikitaKhodakovsky: correct. Although it does not matters if the signature in CertificateVerify is verified first or the certificate + chain. Probably the latter is done only after validating the signature since certificate validation is more expensive, especially if revocation is properly accounted for. $\endgroup$ Nov 7, 2022 at 18:46
  • $\begingroup$ So what is the proof that the server knows the private key in TLS 1.2? $\endgroup$
    – 傅继晗
    Jan 2 at 12:30
  • 1
    $\begingroup$ @傅继晗: For DH key exchange it is done by digitally signing parts of the ServerKeyExchange. $\endgroup$ Jan 2 at 12:49
  • $\begingroup$ @SteffenUllrich Thank you so much. I've been reading RFC documents and, as you mentioned, I found that the phases of verifying the server's private key are completely different. In addition, in TLS 1.2, the data to be signed includes only the Diffie-Hellman parameters, while in TLS 1.3, it includes all the content of the entire handshake phase. This difference is significant, and surprisingly, there are very few online articles that mention it, which is also a point that confuses me. $\endgroup$
    – 傅继晗
    Jan 2 at 13:04
0
$\begingroup$

The key exchange in TLS 1.3 is mainly based on the SIGMA protocol, implementing a "SIGn-then-MAc" variant of SIGMA. I will only describe high-level ideas for the full handshake, other considerations are needed for other handshake like the PSK mode. For an extensive security analysis, I recommend "A cryptographic analysis of TLS 1.3 handshake protocol" by Dowling, Fischlin, Günther and Stebila.

How does TLS 1.3 provide authentication

Zooming out of TLS 1.3, SIGMA builds on an unauthenticated DH and authentication in SIGMA is guaranteed by signature over the communication transcript of the key exchange and a MAC over the identity of the authenticating party. The basic SIGMA flow with mutual authentication between a Client C and Server S is as follows:

  • C -> S: $g^x, \text{identity(C)}$.
  • S -> C: $g^y, \mathrm{sig}(sk_S, g^x, g^y), MAC(identity(S))$
  • C -> S: $\mathrm{sig}(sk_C, g^x, g^y)$

SIGMA is shown (here for example) to provide strong authentication guarantees, key secrecy and forward secrecy even assuming a strong attacker; i.e.: an attacker that fully control the network, that can reveal established session keys, compromise the long-term signing keys of some entities. As a consequence, TLS 1.3 inherits those guarantees, though it makes a few changes like deriving the keys with a more complex key schedule that incorporate the entire transcript in the key schedule.

what is the point of using PKI and Public Key Certificate if the public key is not used to verify that the party has a private key?

Firstly, as seen in the SIGMA flow. The public keys are used to provide signature during authentication. Additionally, a PKI serves as a trusted way to bind identities to public key. This is necessary since a malicious party can impersonate another without any ground truth regarding identities and public keys.

Note that, technically, SIGMA doesn't take maliciously generated public keys into it's threat model. But this is another issue.

$\endgroup$

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.