The point of public key encryption
is that the public key component
is really public.
That is, any user can send his or
her public key to any other user or
just broadcast it to the world.
Although this approach is very
convenient, it has a major weakness.
That is, anyone can forge
such a public announcement.
Some user could pretend to be Bob,
and send a public key to another user
such as Alice, and tell Alice
that this is Bob’s public key.
The result is that when Alice
sends a private message to Bob
saying she encrypts it
using Bob’s public key.
But remember this Bob’s public key
is actually forged by the attacker.
Then the message can be
intercepted by the attacker, and
can be read by the attacker.
Now, at some point hopefully,
Bob can discover that there’s
a forgery going on and
a fake public key of his was being used.
But then what can Bob do?
Bob can send Alice another
message saying that,
hey, this is my real public key.
But how could Alice tell?
That is, how could Alice tell that the
previous key was a forgery and this key,
that Bob just sent, is real.
The solution to this problem of
public key forgery is to use
a public key certificate.
In essence, a certificate consists
of Bob’s public key and Bob’s
information such as the user ID, let’s
say his name and address and so on.
The certificate authority’s information.
And the whole blog is signed using
the certificate authority’s private key.
The certificate can also
include other information,
such as the period of validity of
this certificate, that is, for
how long this certificate is valid for
this public key, say, one year.
Now let’s see how certificate is
created, and how it is verified, and
how it is being used to
distribute public key.
Suppose Bob wants the certificate
authority CA to create a certificate for
his public key.
Bob would contact the CA and provide
authentication information such keys
driver’s license and so on, and
then he will send his public key to CA.
The CA will then put his ID,
his public key and
other information such as the period
of validity together and then hash it.
And then the CA will use his
private key to sign the hash.
So that creates the certificate
of Bob’s public key.
Now Bob can send this public key
certificate to anybody such as Alice.
When Alice receives this
public key certificate,
she can first extract the key types
of information of Bob’s idea,
public key, and all the information.
And then she will hash this data,
and then Alice will also use
the certificate authorities public
key to decrypt the signature or
verify the signature and
compare these two hash values.
If they match, that means this public
key has been properly signed by the CA.
In other words, this public key of
Bob’s has been validated by the CA.
So this is how public
key certificate works.
Now of course,
the underlying assumption is that.
The CA is a trusted party
by everybody involved.
In practice, the CA is a well-known
company such as Verisign,
Microsoft, Google, or Apple, and
the public keys are already stored in,
for example your web browser.
That is with these public keys already
configured on your system, they can
automatically validate public key
certificates signed by these entities.