]]>
http://zh.wikipedia.org/wiki/鐢熸棩鏀誨嚮
]]>
]]>
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.
]]>