Asymmetric
encryption can be
used to provide
several of the
security principles,
such as
confidentiality,
authentication,
non-repudiation, and
(when coupled with
one-way hashes)
message integrity.
As pointed out in
the thread
"Asymmetric
Encryption", it is
imperative the
private key remains
private. Once the
private key is
exposed, the
benefits of
asymmetric
encryption are lost.
As important as the
private key is, it
is not the only key
in the pair worthy
of protection. For
asymmetric
encryption to work
properly, you must
be certain that the
public key you have
for someone really
is their public key.
Think back to
digital signatures.
If you are able to
validate the
signature attached
to the email I sent
you, then you know
the email hasn't
been tampered with.
You also know that I
must have been the
one to sign the
message. These
things are true
because you used my
public key to
validate the
signature, which
means only the
corresponding
private key could
have been used to
create the
signature. But what
if the public key
you think belongs to
me isn't actually my
public key?
Suppose for a moment
that I originally
sent my public key
to you through
email, and someone
was able to
intercept my public
key and replace it
with his own. No
method was used to
ensure the integrity
of the email, so you
have no way of
knowing you received
the wrong key.
If successful in
swapping out my
public key, the
attacker could
intercept and
decrypt messages
encrypted with my
private key.
Sender <---> Attacker <---> Recipient
When the attacker
intercepts my
message, he decrypts
it, alters any
portion of it if he
chooses to, and then
re-encrypts the
message with his own
private key. When
the message arrives
at the recipient,
the recipient is
able to decrypt the
message with the
public key provided
by the attacker. The
recipient thinks
he has the sender's
public key, but in
reality he has the
attacker's key. This
allows the attacker
to spoof the
sender's identity,
even though the
attacker doesn't
have the sender's
private key
The solution is to
provide a means of
ensuring the
integrity of the
public key. Digital
certificates do just
that.
A digital
certificate is a
public key that,
along with the
identity of the
key's owner, has
been digitally
signed by a trusted
third party. The
third party is known
as a Certificate
Authority, or
CA. Some well-known
CAs include Equifax,
Thawte, and Verisign.
In order to validate
the digital
signature within the
certificate, you
must have a copy of
the CA's public key.
The CA's public key
is sent in a
certificate signed
by the CA, and is
known as a
self-signed
certificate. A
self-signed
certificate isn't
signed by a third
party; instead, it
is signed by the
owner of the public
key. This presents a
potential problem in
knowing if the
certificate has been
tampered with or
not. If you've
figured out the
problem and want to
know more (like the
solution, for
example), let me
know.
A CA's certificate
is also known as a
root certificate.
A root certificate
that you believe to
be genuine and are
willing to trust as
authentic is a
trusted root
certificate.
Okay, back to the
example before I
babble too much.
Instead of sending
you my public key, I
send you a copy of
my certificate
(signed by VeriSign).
First, you check the
name on the
certificate to make
sure it has my name
on it. Next, you
validate the
signature on the
certificate using
VeriSign's root
certificate. The
signature is valid,
indicating the
certificate hasn't
been altered (the
identifying
information and
public key are
intact). If someone
had altered the
certificate before
it arrived to you,
the digital
signature on the
certificate would
have indicated as
much.
As with all my
tutorials, I have
glossed over a few
details for the sake
of brevity. Feel
free to post any
follow-up questions
to my posts; I'll be
happy to answer
them.
