How does a digital certificate prove authenticity?

Question

Imagine the following scenario:

We have Bob that wants to send a message to Alice. Both have a public/private key. Bob uses his private key to sign the digest (hash of the message) with it's private key, and sends along it the plain text message. Alice receives the message, it uses Bobs public key to verify the signature, to verify if the message is from Bob, and it hashes the plain text message and compares the hashes/digests, and if they are the same, it means that the message was not altered with and the message is from Bob.

But the authenticity part is not entirely solid, that is where digital certificates come into place. I'm am failing to see how a digital certificate can proof the message comes from the person Alice expects it to come from. The digital certificate contains the name of Bob, and a public key. But what if a hacker intercepts the message, and has it's own digital certificate with the name "Bob" and his own public key in the certificate?

The question is: How can Alice verify the message comes from the real Bob and not the fake one? And how is the validation exactly done? In real life, I can use a passport to identify myself, that is because my face is unique... but with the information in the certificate, how is that even enough for authenticity?

Answer 1

I'll keep the explanation pretty simple using commonly known examples, in order to avoid complicating things. As such, there are many more details involved, but I won't go into them.

There are two main concepts that you should have in mind:

• Public Key Infrastructure: this is a centralized model where certificates are signed by a trusted third party (called a Certificate Authority - CA). This model is used frequently with TLS certificates that, in turn, are used to secure communication channels (e.g. web/http)
• Web of Trust: this is a decentralized model where each person has a public and a private key and uses them to communicate with other peers. The public key of each person is not signed by any trusted third party but is exchanged among participants using secure means. This model is mainly used by PGP and GnuPG. One way to let know others of your public key is to upload it to a public key server (e.g. pgp.mit.edu) where others can find it. Another way is go to key exchange venues (parties) where people exchange public keys (old school - I'm not aware whether this still takes place).

Here's the trick with the web of trust: if I were to meet you and you gave me your public key, I would sign your key with my private key because I know that your public key is valid. Hence, by me signing it, I vouch for its validity. A third person that knows me and trusts me and my keys, will see that I've signed your key and she will immediately start trusting your key too (transitive trust). This is how the web of trust works.

Now, having in mind all of the above, the answer to your question is the following:

• In the PKI model, a certificate is coupled with a server's FQDN (keeping the concepts simple here for the sake of this explanation). As such, when you get the certificate that is signed by a CA that you trust, you trust the certificate and the certificate refers to a single domain. Since you cannot have two different IPs be assigned the same FQDN (again, keeping things simple), you are certain that you communicate with the expected peer
• In the WoT model, a public key is coupled (usually) with a user's email address. Other things that can be put in the public key info are the owner's full name, mobile phone, residence etc. All this info is protected from tampering by using integrity protection (cryptographically secure hashing), so when you use the public key you know that you send messages to the specific email address

Whether you trust that email address, the info on the public key or you trust a public key without any of these pieces of info is where the WoT model may fail to protect you from an impersonator.

Answer 2

In asymmetric cryptography there is a notion of a root of trust.

In OpenPGP for instance it's not terribly uncommon to exchange keys face to face. And then trust all online communication because it can be verified cryptographically by a key you got when meeting the person face to face. A trusted contact may even say "This is the public key of so and so who I met in person" in a signed message. Thus giving a reason to trust it.

In many IOT update schemes the root of trust is a key that was placed in the device at manufacturing time. If an update comes through and it's signed by a key that is signed by a key that was installed at the factory, well, it's trusted. Because it can be traced back to the root of trust.

In the broader internet context, this is Certificate Authorities. A browser installs a set of CA certificates and if a website's certificate can be chained back to a CA it's valid. A CA is trusted because they haven't been known to do anything out of line. They only sign a certificate for google.com when google comes asking, and no one else. CA's that break this trust get removed from browsers root of trust.

So, if one wants to design an asymmetric system, it's best designed with some root of trust that everything can descend from. Bob knows Alice by exchanging keys face to face or by trusting a central authority to never sign a key as being from Alice when it's not.

Answer 3

It does not prove authenticity.

When I applied for a digital certificate as the developer of software I had to send an image of my passport. Of course it is possible for people to fake such an image.

An entity that controls john.com can prove it. For example the certificate authority can send something to john.com or ask for something to be sent from john.com. Whether you trust john.com depends. If a business that you trust is named "Jon" and you accessed john.com you have no assurance that you are dealing with Jon.

Answer 4

But what if a hacker intercepts the message, and has it's own digital certificate with the name "Bob" and his own public key in the certificate?

When applied to Internet's PKI - Certificate Authority requires you to prove that you are Bob. For example when you request SSL cert for your website, f.e. from LetsEncrypt, they will ask you to prove that you own that domain, by adding a specific DNS record with specific payload.

Alice derives the root of trust from CA, who verifies Bob's identity and issues his cert, and ensure security of Alice<=>Bob communication.

If Bob got his cert from shady CA (or self-signed), Alice is not going to trust it. if Bob's private key is compromised, then his cert will be in Certificate Revocation List, or it will not pass the Open Certificate Status Protocol check.

Answer 5

The digital certificate contains the name of Bob, and a public key.

And it's signed by a trusted third party, commonly known as a Certificate Authority.

CA's have procedures in place to ensure that only Bob will get a certificate that say's he is Bob, so that no third parties should be able to get one.