PKI infrastrcuture

http://www.windowsitpro.com/WindowsSecurity/Article/ArticleID/47625/47625.html

In "Keep Your Secrets Safe" (August 2005, InstantDoc ID 46871), I introduced you to shared key and public/private key encryption. I pointed out that shared key encryption is good for bulk encryption of large amounts of data, that public/private key encryption is better for exchanging information between parties, and that you can combine the two to get the best of both worlds. I also discussed how you can combine public/private key encryption with hashing to create digital signatures that prove both the identity of a message's sender and that the data wasn't altered since it was signed. Public/private key encryption is a versatile and effective way to prove identity and share secure information between parties that might not know each other. But here's one important caveat: Users must have a way of obtaining other users' public keys and be fully confident that a user's public key really is the user's and not an impostor's. To ensure that confidence, an infrastructure that facilitates the publishing of public keys is necessary. The good news is that such technology exists. It's called public key infrastructure (PKI).

Certification Authorities
PKI uses certificates issued by servers called Certification Authorities (CAs) to vouch for the authenticity of a user and his or her public key. With PKI, two parties who are unfamiliar with each other can verify each other's identity and exchange information securely by trusting the CA. A CA has its own public/private key pair: This is the cornerstone of PKI security.

Let's look at an example. For Bob to take advantage of PKI, he must obtain from a CA a certificate similar to the one that Figure 1 shows. Bob's computer generates a public/private key pair, then contacts the CA. Bob must then authenticate to the CA. (The sidebar "Authenticating the Requester of a New Certificate" gives an overview of the authorization process.) For example, he provides identifying information that can include his name, email address, company, and department. Bob provides his public key to the CA, but he never shares his private key unless the CA is performing key escrow/backup services. That way, not even the CA can compromise information protected by Bob's private key. Next, the CA takes Bob's identifying information and public key and formats it into a certificate, usually according to Public-Key Cryptography Standards (PKCS), which RSA Laboratories defines. (For information about these standards, go to http://www.rsasecurity.com/rsalabs/node.asp?id=2124.) Finally, the CA adds a digital signature to the certificate by hashing the certificate and then encrypting the hash with its own private key. You can see the encrypted hash of a certificate and the hash algorithm the CA used (i.e., sha1) in the Thumbprint and Thumbprint algorithm fields in the certificate that Figure 2 shows. The resulting certificate can now be published in directories such as Active Directory (AD) or shared by Bob with other parties.

PKI in Action
Now, let's look at how Bob can use his certificate with a common application such as email. Let's say Bob wants to send an email message to Alice, and he wants to make sure that Alice can trust that the message came from him and wasn't altered along the way. Alice is Bob's broker and the message he wants to send to her is an order to buy stocks. Because Secure MIME (S/MIME) is an accepted protocol for email security, both Bob and Alice need an S/MIME-compliant email client such as Microsoft Outlook. Bob can optionally use the private key that corresponds to his certificate to sign his message. That signature is a hash of the message encrypted with Bob's private key. Bob's email client sends the message, signature, and certificate to Alice. Alice's email client sees that the message is in S/MIME format and proceeds to verify the signature. Using the same algorithm that the issuing CA used, her client computes its own hash of the message, decrypts the hash with the public key in Bob's certificate, then compares the two hashes. If the hashes match, Alice's client knows that the message was signed by the private key that corresponds to the public key in the certificate.

So how do Alice and her email client know that the public key is really Bob's? After all, the public key in the certificate could have been replaced by a malicious party in transit, or the entire message and certificate could be fake. Before trusting a message signed with a certificate, Alice's email client must verify the certificate. You might recall the point I made earlier that, in order for PKI to work, everyone using the system must trust the CA. To guarantee that trust, the CA has already given Alice its public key. (For example, Windows 2000 and later OSs include the self-signed certificates of all the major CAs on the Internet and automatically obtain the certificates of Enterprise CAs that you set up within your AD environment. You can use Group Policy to specify additional trusted CAs or remove default CAs.) Therefore, Alice's email client can verify Bob's certificate. Her client computes its own hash of Bob's certificate and uses the CA's public key to decrypt the certificate's digital signature hash. If the hashes match, the client knows that the CA used its private key to sign the certificate. Based upon that determination, Alice's email client is confident that the information in the certificate--such as Bob's name, email address, and public key--are really Bob's because the CA authenticated Bob before signing his certificate request. Thus, Alice knows that the stock buy order is legitimate.

Of course, Alice is only as confident in the message as she is in the CA. If a CA fails to protect its private key or fails to properly authenticate a certificate requester, the security of the PKI falls apart. In fact, third-party CAs such as VeriSign issue different certificate levels that correspond to the due diligence that they perform while verifying certificate requesters. For an interesting read about such procedures, see "4. VTN Certificates" on the VeriSign Relying Party Agreement, available for viewing at https://www.VeriSign.com/repository/rpa.html.

At the same time, the security of an individual certificate depends on the secrecy of the private key corresponding to the certificate. If Bob's private key is stolen, the thief can impersonate Bob. In a future article, I'll discuss how certificate revocation lists (CRLs) and PKI standards handle this situation and others that can arise from the use of certificates and private keys.