How does an attack on a digital signature work?

Question

In our IT Security class we have been told that you need CA's to prevent attacks on a digital signature. Sadly, our docent didn't elaborate how such attack would be performed - I can only guess that someone would try to do a MitM:

1. Alice wants to authenticate towards Bob, so she writes him a message and signs that with her private key. She also appends her public key.
2. Eve intercepts the message and verifies the message with Alice's public key, then signs the message with her own private key and forwards it to Bob, appending her own public key instead of Alice's.
3. Bob receives the message assuming it's from Alice, verifying it with the appended public key (from Eve) and is now sure to communicate with Alice.

So if Bob would just have looked up Alice's public key at some CA, he would have known that the appended key was wrong.

Is that the scenario people are generally referencing to when it comes to why you need CAs?

Answer 1

A digital signature, like all cryptographic algorithm, does not solve problems, it just moves them around.

Take care that signatures are NOT encryption. If someone tried to explain signatures as a kind of encryption, then go find them and hit them in the teeth with a wrench, repeatedly. Tell them that they are unworthy, and I am disappointed with them. This flawed explanation does not work, never worked, and spreads only confusion.

In a signature system, there is a message m, a public key k_p, a private key k_s, and a signature s. The signature generation algorithm computes s from m and k_s. The signature verification algorithm takes m, s and k_p, and returns either "true" or "false". When it returns "true", what this means is that whoever owns the public key (i.e. knows the corresponding private key) was involved in the generation of signature s on the specific message m.

The important point is in the key ownership: the signature verification algorithm does not tell you "yep, this is signed by Bob"; it only tells you "yep, this is signed by whoever owns that public key". This guarantees that the signer is really Bob only if you have a way to make sure that the public key you see is really Bob's public key. If Bob simply sent his public key along with the signed message, it would be easy to impersonate Bob by simply saying "hello, I am Bob, here is my public key, and here is my signed message". It would prove nothing at all. The attack here is simple, it is called "lying".

While signatures are useful (indeed, they reduced the problem of verifying the provenance of several messages to the problem of associated a single public key with its owner), they don't magically guarantee ownership out of thin air. This is where Certification Authorities come into play. The CA is an organism whose job is to make sure that Bob really owns his alleged public key; presumably, the CA does that by meeting Bob in person, or some other mechanism of that kind. When the CA has duly verified Bob's ownership of his key, the CA puts Bob's identity (his name) and his public key in a certificate. The CA then signs the certificate.

Alice's machine can then verify the signature on the certificate, thereby making sure that the certificate contents are really from the expected CA. At which point Alice has some guarantee about the fact that the public key she sees in the certificate is really Bob's key, and she can use it to verify signatures which have purportedly been computed by Bob.

At this point you should say: "But how can Alice verify the signature on the certificate by the CA ? She would have to know the CA public key !" And, indeed, the problem has again been moved, to the question of CA key ownership. We can move it yet another time, with another CA. And so on. But it must stop somewhere. That "somewhere" is the root CA. A root CA is a CA whose pubic key you already know, absolutely. That's the magic part. In practice, your computer comes with an operating system that already includes the public key of a hundred or so of root CA, who made a deal with Microsoft to the effect that their public keys are inherently known (and trusted) by all Windows systems.

Answer 2

Kind of, although a CA isn't the only solution to the problem.

A certificate authority provides a third party assurance that a public key belongs to a given entity by essentially saying "I have looked at this public key, and this entity, and I am stating that they are linked, and since I am a trusted entity, you can believe me". They do this by signing the key with their own private key, which you can verify if you have their public key.

This is all well and good, but doesn't actually prevent a MitM attack - if Bob doesn't verify the signature, or the CA doesn't actually verify that Alice owns the key, or if Eve is able to convince the CA that her name is Alice, so her key appears to be valid, or if Eve operates a trusted CA, Bob still doesn't know that the message was signed by Alice. CAs know this, so, in general, try to be good citizens and actually perform the checks they claim to do.

What would prevent a MitM attack then? Well, if Alice and Bob have another communication channel that they trust (maybe they actually meet up, examine each other's passports, and otherwise prove their identities to one another), then swap public keys, they can send messages safely in the future, since Bob knows with certainty that he has Alice's correct public key, and Alice knows the same about Bob. Eve can try and swap the content if she likes, but without the private key to sign the modified message, the recipient will know that something isn't right. In this case, you don't need a CA at all - you have direct trust.