http://www.carillon.ca/library/pkitutorial.php
In recent years, two of the main hurdles encountered when using data
networks for collaborative work and the transmission of sensitive
information have been, in no particular order:
-
data confidentiality, or ensuring that the information can only be read by the people who are supposed to read it; and
-
data integrity, or ensuring that the information received is exactly the information that was sent.
Basic encryption
Various techniques have been available to solve those issues, usually
through the use of cryptographical tools. The basic approach is to use a
specific mathematical formula (the cipher) into which a series of
numbers (the secret key) can be plugged; when this formula is applied
to some data (called the plaintext), this data is turned into an
unintelligible mass of characters (called the ciphertext).
The transformation of plaintext into ciphertext is called
encryption; the reverse process is called decryption.
Only someone who knows what cipher and what secret key were used can
return the ciphertext back to the original plaintext. Usually, the cipher
is well-known, but the secret key is, well, secret.
The cipher must guarantee two things:
- without the secret key, absolutely no part of the plaintext can be reconstructed from the cyphertext; and
- with the secret key, the entire plaintext can be unambiguously reconstructed from the cyphertext.
Let's put this in an example. May we introduce Alice and Bob, who are
trying to exchange information. But in the shadows lurks Eve, the
Eve-ildoer who is trying to Eve-sdrop on the information being exchanged
between Alice and Bob.
Alice and Bob, who know each other and plan on exchanging data in a
secure fashion, meet face-to-face and choose a secret key. At a later time,
when Alice wants to send Bob some confidential data, she takes that
plaintext and applies the cipher to it, using the pre-arranged secret key.
The resulting ciphertext is sent via the network to Bob, including some
information, such as which cipher was used. Bob receives the ciphertext,
applies the reverse cipher with the secret key, and obtains the original
plaintext.
Our eavesdropping Eve also manages to get a copy of the ciphertext;
however, she can't make sense of its contents. Even knowing which cipher
was used, without the secret key, she can't decrypt the captured data back
to its original plaintext form.
This takes care of data confidentiality; if Alice wants only specific
people to access a certain piece of encrypted information, she can give the
secret key to only those people. But how does it address data integrity?
It doesn't, at least not directly. If something interferes with the
ciphertext during transit, decrypting it will generate unintelligible data.
However, as far as Bob is concerned, the original plaintext might not have
been intelligible data in the first place, so he has no proof that the data
was or wasn't altered.
Another technique, data hashing, will help Alice with that objective.
Data hashing
To guarantee data integrity, a new mathematical tool is needed. A
hash function is another (and very different) mathematical formula
through which our plaintext will be processed, producing a fixed-length
result called a hash sum. This hash function presents the following
characteristics:
- a specific plaintext produces a specific hash sum;
- the hash sum cannot be used to reconstruct any part of the plaintext; and
- it is impossible to craft a different plaintext that produces the same hash sum.
How is that useful? Imagine Alice produces a hash sum for a specific
plaintext and then encrypts the hash sum with the secret key she shares with
Bob. If she joins that encrypted hash sum with her original message, Bob
can decrypt the hash sum sent by Alice and then calculate his own hash sum
from the plaintext. If both hash sums match, it means the retrieved
plaintext is indeed identical to what Alice sent. If the hash sums differ,
the message was modified at some point.
If Eve intercepts the message and tries to modify it, she can't create a
new encrypted hash sum that will correspond to the modified message, since
she doesn't have the secret key. Therefore, data integrity can be
achieved.
So, it would seem that encryption and data hashing solve our
confidentiality and integrity issues. There is, however, a major problem
with this approach. Our initial premise is that Alice and Bob meet before
any data exchange to establish a secret key. What if Alice and Bob are
halfway around the world? That complicates the meeting. What if Alice
wants to communicate securely with Bob, but also with Charlie, Dennis and
Fred? That forces her to hold additional meetings. And if Bob also wants
to communicate with Charlie, Dennis and Fred? Even more meetings. And what
if they all need to communicate now, without having met before?
Enter public-key cryptography.
Public-key cryptography
A more complex but extremely useful approach is asymmetric
cryptography, also known as public-key cryptography (yes, this is
the same "Public Key" as in "Public Key Infrastructure"!), which will now be
the focus of our interest.
Public-key cryptography revolves around the use of a mathematically
linked pair of keys, one designated public and the other designated
private. This mathematical linkage is such that plaintext encrypted
using one of the keys can only be decrypted using the other key. A specific
individual has her own pair of keys, keeping the private key absolutely
private and the public key as public as possible.
How does this apply to our quandary? If Alice has in hand her own public
key (PubA), her own private key (PrivA), and Bob's
public key (PubB), she can do the following:
- encrypt the plaintext with Bob's public key (PubB);
- calculate the hash sum of the plaintext and encrypt it with her own private key (PrivA); and
- combine the ciphertext and the encrypted hash sum in a message and send it to Bob.
Upon receiving this message, Bob, who should have in his posession his
own public key (PubB), his own private key (PrivB),
and Alice's public key (PubA), can do the following:
- decrypt the ciphertext with his own private key (PrivB);
- decrypt the hash sum with Alice's public key (PubA);
- calculate the hash sum of the plaintext and compare it with the decrypted hash sum.
Bob therefore obtains the plaintext and, if the hash sums are the same,
the guarantee that it hasn't been altered in transit.
What if Eve intercepts the message sent by Alice? Eve has her own public
key (PubE), her own private key (PrivE), Alice's
public key (PubA) and Bob's public key (PubB).
Unfortunately for her, this doesn't do her any good; since she doesn't have
Bob's private key, she can't retrieve the plaintext, and since she doesn't
have Alice's private key, she can't modify the message and encrypt a new
hash sum.
Data confidentiality and integrity are therefore assured, without forcing
everybody to meet beforehand. All that's needed is a way to distribute
public keys.
Digital signature
Before we tackle the issue of distribution, there's an interesting
concept that deserves a little detour. When Alice applies a hash function
to a plaintext and encrypts the obtained hash sum with her private key, the
result is called a digital signature.
A digital signature guarantees two things:
- if the decrypted hash sum matches the hash sum of the plaintext,
the plaintext received corresponds to the plaintext sent by Alice
- if the hash sum can be decrypted with Alice's public key, it
proves the document was indeed sent by Alice (actually, it only proves the
document was sent by someone who has Alice's private key, which we take for
granted is Alice - we'll come back on this matter a bit later).
The latter is an important point - the digital signature proves the
document was indeed sent by Alice, and Alice cannot claim she didn't send
it.
Of course, this all takes for granted that Alice is the only one who can
access her private key. If a private key is compromised, i.e. if it falls
into someone else's hands, the associated public key becomes useless.
Worse, it becomes dangerous, because people might still think it valid and
believe that something signed with Alice's private key indeed comes from
Alice. In the other direction, plaintext encrypted with Alice's public key
will actually be readable by everyone who has access to Alice's private key.
The simple moral of this is - private keys are an extremely sensitive piece
of information, and must be kept utterly safe, at all times.
Certificates
There is one major problem left. For the system to work, Alice must be
absolutely sure that the public key with which she encrypts the plaintext is
indeed Bob's. Should she be tricked in using Eve's, for example, Eve would
then be able to decrypt the ciphertext and access the plaintext.
Or, if what Bob thinks is Alice's public key is actually Eve's, Eve can
sign a document that Bob will believe is coming from Alice.
Therefore, while the public keys per se are not meant to be secret, it is
imperative that the person the public key is associated with be ascertained.
This could be done through a face-to-face meeting, as we initially did at
the beginning of this conversation; however, this is no more practical now
than it was back then.
Back to the drawing board? Not quite. There might be an acceptable
compromise.
What if Alice and Bob have a common friend, named Charlie. Charlie
travels a lot, meets a lot of people, and is an all-around pleasant and
very, very reliable individual. If, during his travels, Charlie has met
with Alice and exchanged public keys with her, he now has a copy of Alice's
public key that he is sure belongs to Alice, and Alice has a copy of
Charlie's public key that she is sure belongs to Charlie. The next time
Charlie meets with Bob, they can not only exchange public keys, but if Bob
really trusts Charlie, he can also accept his copy of Alice's public key
with assurance that it is indeed Alice's.
Charlie can even take this one step further; he can take Bob's public
key, digitally sign it with his own private key, and send this to Alice.
Alice is sure of her copy of Charlie's public key, so she can trust that
this indeed comes from Charlie. And if she trusts Charlie to be a thorough
and reliable individual, she can also accept what she has just received as
Bob's public key.
If Charlie also meets Dennis and Fred, this process can be expanded even
further. All the people who trust Charlie to do a good job can now have
reliable access to each other's public key, just by meeting Charlie
once.
There's a specific name for a public key digitally signed by someone many
people trust; it is called a certificate. Usually, there is also
some additional information enclosed, such as the name, organisation, email
address, etc. of the person whose public key is contained within the
certificate.
And now to the core of the matter...
Public Key Infrastructure
So what is a Public Key Infrastructure or PKI? It is a system designed
to allow the creation and distribution of those certificates. In technical
terms, it is the combination of:
- a Registration Authority (or RA), in charge of verifying people's identity and associating that identity with their public key
- a Certification Authority (or CA), in charge of generating certificates, i.e. signing people's public key and identity information with its own private key
- a validation system that can confirm whether a specific
certificate produced by this CA is still valid or not (for example,
because the associated private key was lost or compromised, or because
some information contained within has changed)
In other words, it's a Charlie. It's someone who participants can have
direct contact with, who can validate people's identity and accept their
public key, who can generate certificates for them and who can distribute
those certificates. It's someone who is extremely meticulous and absolutely
trustworthy, and who people trust.
What makes it even more useful is that PKIs can trust each other, under
very specific conditions; when this occurs, a PKI's participants (or
subscribers, as they are officially called) can access and trust the
certificates of the other PKI's subscribers.
While it may not seem that way, the technical side of a PKI is fairly
simple. What is complex is that to be of any use, it must be trusted by its
subscribers, and must be deserving of that trust. This comes through the
creation of very specific and very strict sets of rules and guidelines, that
must be transparent, auditable and followed at all times. Those rules are
enumerated in a document called the Certificate Policy (or
CP), which states how the PKI must function.
So in a nutshell, a PKI is a system that guarantees that a specific
public key belongs to a specific identity. What can be done with it? A
lot.
For a more detailed yet still very reader-friendly look at PKI and its
underlying concepts, we encourage you to take a look at our world-renowned
PKI Fingerpuppet Theatre.