2
$\begingroup$

I wanted several videos by Computerphile on Elliptic Curve Diffie-Hellman, digital signatures and TLS.

For the most part I understand everything but something is bothering me. Computerphile made a video explaining using RSA with ECDHE to ensure nobody is messing with the messages in the middle. The video is titled Key Exchange Problems. I don't understand how introducing a cryptographically signed Diffie-Hellman parameter that can be decrypted with a public key ensures nobody is in the middle?

What stops the person in the middle from decrypting the parameter with the public key just as the client would then resigning it with their private key and sending it to the client? The same goes for signing. If someone was in the middle of a digital signature, couldn't they trick the verifier?

For example:

  1. A (the signer) sends document to verify to C (the verifier) through B (B is in the middle; B forwards doc to C).
  2. A sends encrypted doc to C through B.

This means that if B resigns the document with their private key, then when C will just verify it was signed with C's public key.

$\endgroup$

1 Answer 1

2
$\begingroup$

The idea of using static key pairs is indeed that data in the key exchange gets signed. It doesn't matter too much what gets signed, as long as it the key exchange cannot be performed by an adversary.

To verify signatures it is required that the public key of the signer needs to be trusted. This is what you are missing in the description. If the verifier only accepts that one key or one set of keys then the signature of the adversary gets rejected, signature verification fails and the keys do not get established or used.


How to put trust the public key then becomes the next problem. This is not part of the key agreement protocol. One way is to explicitly trust one public key, for instance by verifying a fingerprint of the public key over the phone. It may also be that the key is uploaded over a trusted channel; this is something that is for instance often performed with SSH public keys.

For TLS the trust is established by trusting (root) certificates of certificate authorities. These are then responsible for only creating certificates for entities that can show that they control a certain domain. These certificates both contain that domain as well as the public key used for verification. This structure is called PKIX: Public Key Infrastructure using X.509 certificates and Certificate Revocation Lists.


Some notes:

  • I've removed any mention of the key agreement or signature generation / verification algorithms - the algorithms used are not important to this question.
  • It is also possible to trust a (static) Diffie-Hellman public key, but you would loose forward secrecy - if the long-term private key of that key pair leaks the the adversary could replay the key agreement and decrypt all messages (and it also complicates the PKI).
  • Signature generation is not the same as signing a message or message hash and verification is not the same as "decryption with the public key" - the Diffie-Hellman public key would just be send in the clear along with the signature over it.
  • There may be additional access control required after the session is established - that's why the certificate used to create a connection is often passed to the back-end and used in an access control system of some kind.
$\endgroup$
2
  • $\begingroup$ To summarize what you said in order to ensure I am understanding, essentially the glue here is the public key of the signer. If the signer's public key or as you said a set of public keys are the only one's trusted, if an adversary were to try and resign it he'd have to use a private key differing from that which the signer used and thus it would be rejected by the verifier. That makes sense. Now I just need to learn more about the Public Key Infrastructure you mentioned that is used to determine which public keys can be trusted by the verifier. $\endgroup$ Jul 3, 2021 at 22:00
  • 1
    $\begingroup$ Seems like you're getting it, great. You can just open the certificate store in your browser to get an idea, or click the little TLS lock item in the bar of your browser, then see the certificate details for a specific site, including the intermediate CA and root CA certificates. $\endgroup$
    – Maarten Bodewes
    Jul 4, 2021 at 0:37

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.