1
$\begingroup$

I've just decided to start learning all about PKIs, and I have come across what seems like a paradox.

When fetching a public key from either a server or a CA, how can we be sure that the public key we receive back has not been intercepted and modified by a man-in-the-middle?

Isn't a public-key required to verify a digital signature? If so, wouldn't that public-key also need to have a digital signature so we can verify its legitimacy? It sounds to me like this would almost certainly lead to a never-ending chain of digital-signatures.

This has been an incredibly baffling concept for me, one that I have not been able to reason out on my own. If anyone could point out any flaws in my understanding, I would greatly appreciate it.

I have read some similar questions, one being: How does the sender obtain the receiver's public key? But, for me, this doesn't really explain how we can eliminate man-in-the-middle attacks from the channels used to fetch public-keys.

Thanks all.

TLDR; How exactly can we eliminate man-in-the-middle attacks from the channels used to fetch public-keys?

Improve this question
$\endgroup$
3
  • 4
    $\begingroup$ You usually assume that your OS is installed securely (if it's not you're screwed anyways). Then you get a secure basis for the OS root certificate store and also for code signing root certificates which then in turn secure software like browser installers. $\endgroup$
    – SEJPM
    Jun 30, 2019 at 11:35
  • $\begingroup$ Hey, thanks for taking the time to comment. However, I'm more specifically referrring to the reliable transmission of public-keys across the internet, rather than local OS stuff. $\endgroup$
    – invertedPanda
    Jun 30, 2019 at 12:23
  • $\begingroup$ @invertedPanda they tie into the OS keystore. The latter works because the former exists $\endgroup$
    – Natanael
    Jul 1, 2019 at 10:53

1 Answer 1

Reset to default
4
$\begingroup$

In a public-key infrastructure, there are two ways a public key can be trusted: either because it's signed by a certificate authority that you trust, or because you already have it in a list of trusted public keys. That's where the chain of signatures ends: in a list of pre-trusted public keys.

These pre-trusted public keys are usually called “root CAs” or “trust store”. They come with the operating system, with the application, or in a configuration.

Sometimes the OS/application/configuration might have its own special-purpose set of root CAs which are obtained via a different PKI provided by the operating system where the OS/application/configuration is installed. This might not be the same system where the application that relies on the PKI will run. For example, if you download firmware for an embedded device on your PC, then the PKI that your browser uses guarantees the authenticity of the firmware image. You trust the root CAs for PKI on the embedded device because they came as part of that firmware image that you trust.

But ultimately, it comes down to a public key that you trust, not because it has a digital signature made by a certificate authority, but because you obtained it from someone you trust by means that you trust. Usually it's the same entity that also provides the code that performs signature verification, and you have to trust that anyway: if the code to verify signatures might accept invalid signatures then it doesn't matter who didn't actually make these signatures. And often it's the same entity that also provides the hardware, and again if the hardware isn't executing the signature verification correctly then it doesn't matter whether the code and data are good.

For example, if you buy a computer with an operating system preinstalled that includes a web browser with HTTPS support, the reason you trust it to verify keys has nothing to do with cryptography. Cryptography is how that browser verifies the authenticity of connections, not why you trust it to do so.

That's in fact a general thing with cryptography: cryptography doesn't actually create security properties from scratch. Cryptography is a mathematical means to extend security properties to cover more ground. For example, encryption alone can't make data confidential: all encryption does is to extend the confidentiality of the key into the confidentiality of the data. A digital signature extends the confidentiality of the private key into the authenticity of the data. Likewise, a hash doesn't guarantee the integrity of data of its own, but extends the integrity of the hash into the integrity of the data. At the root, there has to be some non-cryptographic means of securing the key or hash.

I didn't find a duplicate question on this site, but this has been covered several times on Security Stack Exchange, in particular:

Improve this answer
$\endgroup$
1
  • $\begingroup$ Aha. I understand now. Thank you so much for your answer :P $\endgroup$
    – invertedPanda
    Jun 30, 2019 at 21:06

Your Answer

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

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