VPNs and Public Key Infrastructure
Pages: 1, 2
Public Key Cryptography Basics
As mentioned previously, OpenVPN uses the SSL protocol for security. The SSL protocol relies on digital objects called X.509 certificates for authentication and encryption. Once your site has its PKI in place, you can provide many more services, including secure web services and email.
The technology that serves as the foundation for all of this security is public key cryptography. This is a complex subject, worthy of far more than this brief summary. Public key cryptography is a technique for secure communication that uses two different keys: public keys made globally available to the world, and private keys guarded secretly by individual parties. Both public and private keys are very large numbers generated simultaneously as a pair by sophisticated computer algorithms.
These key pairs have a very useful property: encrypting a message with one key requires the use of the other key to decrypt it. This is the most important property of these keys, and it bears repeating. After generating a public/private key pair, a user can decrypt a message encrypted by the private key only by using the public key. This also works in reverse; messages encrypted with the public key require the private key to decrypt.
Suppose that Alice wants to send a secret message to Bob, and Bob alone. Suppose also that Bob has generated a public/private key pair. First, Alice will create her message. Then she will encrypt it using Bob's public key. Finally, she will send the encrypted message to Bob. Bob can decrypt this message only by using the private key that matches the public key used to encrypt the message. As long as Bob keeps his private key secret, any message encrypted with his public key is safe. When Bob receives the message, he uses his private key to decipher it. He then can read the message from Alice.
For Bob to reply securely to Alice, she would need to create her own public/private key pair. Why? What if he encrypted his message to Alice using his private key thinking that Alice could then decrypt it using her copy of Bob's public key? Alice could indeed decipher Bob's message, but so could anybody else who had Bob's public key. That defeats the purpose of encrypting the message in the first place. Bob needs to encrypt his reply with Alice's public key to ensure that only Alice, the holder of her private key, can decrypt it. That's public key cryptography in a nutshell.
A gaping hole in the above scenario has to do with the management of public keys. How does Alice know that a given public key really does belong to Bob? You can imagine that an interloper may create a public/private key pair and masquerade the public key as belonging to Bob, thereby intercepting secured communications by tricking Alice into using the fake public key to encrypt her message. It is just this security hole that a digital certificate fills.
A digital certificate is a data structure that authenticates a public key and contains, at the minimum, the following pieces of information:
- The name of the holder of a public key
- The name of a party certifying that the contained key indeed belongs to the indicated holder
- The public key itself
- A digital checksum of the certificate itself, encrypted with the private key of the party issuing the certificate
An agency creating a digital certificate guarantees that the public key belongs to the party that requests the certificate. The requesting party is the subject, and the party issuing the certificate is the issuer. The X.509 certificate format encodes those names according to a special syntax, calling them distinguished names (DNs). The issuer creating the certificate collects information from the requesting party until it knows the requestor's identity sufficiently. Then it combines the name of the requesting party, the requesting party's public key, and its own name into a data structure, and calculates a digital checksum on that structure. The certifying agency encrypts the result of this checksum using its own private key and appends this encrypted checksum to the certificate's data structure.
After completing this process anyone can examine the digital certificate and verify that a certain public key does in fact belong to a particular individual. Of course, all parties involved in the transaction must trust the certifying agency.
Assume that Frank runs a reputable digital certification service and that both Alice and Bob trust him. Bob can contact Frank and ask him to issue a digital certificate. Frank will ask Bob to provide some kind of identification proving that he is indeed Bob. Once Frank is satisfied that Bob is indeed Bob, he will construct a digital certificate using a computer program. The inputs to this program are Bob's name as the subject, his public key, and Frank's name as the issuer. The computer program will calculate a digital checksum over the combination of these items and encrypt that value using Frank's private key. Now when Alice wants Bob's public key, she locates his digital certificate and validates it using Frank's public key.
For validation, Alice separates the encrypted checksum from the digital certificate and calculates a checksum on the remainder of the data structure. She then uses Frank's public key to decrypt the original checksum and compares it with her result. If the checksums match, Alice knows that Frank and no one else actually put his information into the certificate. How does Alice know that she really has Frank's public key? She can validate Frank's public key by using a digital certificate issued to Frank by some other trusted agency. Typically, this chain of trust will terminate at a well-known public entity that has saturated the Internet with a public key. A few such entities are VeriSign, Entrust, and GlobalSign, which have public keys built into many software products including Internet Explorer. Incidentally, the certificate at the top of the hierarchy is a "self-signed" certificate.
Public Key Infrastructure
Earlier, this article claimed that using a PKI could support access to and operation of our VPN. A Public Key Infrastructure is a set of computer programs, databases, and network services that allow an organization to issue, publish, and revoke digital certificates. I've described issuance and publication previously, but revocation is a new topic. (It's also one of the important new features found in OpenVPN-2.0--support for verification against a Certificate Revocation List or CRL.)
If a certificate issuer decides that a certificate is no longer valid, it will add that certificate to its CRL. As hinted by the name, the CRL is a list of revoked certificates. It is the responsibility of the party using the certificate to check the CRL and verify that a given certificate remains valid.
Suppose that you have implemented a VPN and secured it with your Public Key Infrastructure. You have given many of your staff members VPN access to your internal network by issuing them digital certificates. Everything works great, and your staff can now work easily from home and access electronic material stored locally from remote customer sites. Now, assume a member of your staff moves on to another job. You no longer want her to have access to your network. Revoke her certificate and add it to the CRL maintained as part of your PKI. Because OpenVPN-2.0 can validate against this CRL, you can immediately and easily terminate that staff member's VPN access.
This article has attempted to lay out conceptually all of the pieces required to put together a VPN using certificates for security. If you have followed along and want to see what it takes to put these concepts into action, the second part of this series will work step-by-step through a complete real-world implementation.
Scott Brumbaugh has worked professionally as a software/systems engineer since 1987.
Return to the Security DevCenter