Modernizing Authentication — What It Takes to Transform Secure Access
Your company is negotiating a big deal with a partner, making you a bit nervous about the security of exchanging documents via email. There is a non-disclosure agreement in place, but you'd like to be absolutely certain that only the recipients can see the plans for your company's new product initiative. When the partner emails their agreement to the final version of the proposed deal, you also want to be able to prove absolutely that the email really is from them. Is there a proven technology that can fulfill both needs?
Public Key Infrastructure (PKI) can handle these requirements and more. You may already be using PKI without knowing it if you have relied on certificates or "certs" to identify a web server or to confirm the identity of external websites. It is a critical technology for the Internet and is used in applications as diverse as e-commerce and VPNs. Let's explore the world of PKI cryptography to learn about keys, signatures, and certificates, and to see how PKI can benefit you and protect your company's valuable digital assets.
You don't need to be an expert in encryption to deploy PKI in your operation, but there are a few key concepts and components to understand. PKI is a powerful technology that employs cryptography to provide two important capabilities, privacy and authentication. The cryptographic procedures, or algorithms, use two keys to encrypt information. This is called asymmetric cryptography. Compared with conventional (symmetric) cryptography, which uses only one key, it is easier to distribute keys, making PKI much simpler and more practical to deploy.
Keys are digital values used to encrypt and decrypt information. A PKI system uses keys in pairs. One key is private and kept secret by its owner. The other key is public and can be freely shared. When you encrypt a document with someone else's public key, only that person can decrypt it, since only he or she has the corresponding private key. This is how PKI provides privacy.
PKI keys are chosen and stored differently than computer passwords. First, a private key is created. The private key is a random binary number that is generated and used inside a computer or specialized hardware device. A private key is never chosen, seen, or created by its owner. Once the private key is determined, the corresponding public key is computed based on the value of the private key. PKI works because it is extraordinarily difficult -- impractical by any currently available means -- to go back the other way.
Keys can be as short or as long as needed. The length of keys is measured in bits. Long keys take more time to process, but offer correspondingly more protection. The most important considerations in choosing the length of the key are the overall value of the information to be protected and how long that information will have value. The greater the length of the key, the more computation would be required to determine the private key from the public key. A key should be long enough that the information would be worthless by the time the private key could be computed. As time goes by, and as computers become increasingly faster, it will be necessary to use correspondingly longer keys.
Signatures are digital values that are computed from a key and the information being signed. When you sign a document with your private key, anyone can use your public key to decrypt the signature. This proves the document is from you. It is how PKI provides authentication. If you signed a second document with the same private key, the second signature would be different, which means a would-be forger cannot simply copy a signature from one document to another.
In organizations or situations where security is a major concern and many documents are signed and/or encrypted, the key pair used for signing is different from the key pair used for encrypting. This is because a key pair used for signing may need to have a very long lifetime compared with a key pair used for encryption.
Certificates are a kind of digital ID card that use your public key instead of your photo. Being sure of the other party's identity is just as important online as it is in traditional transactions. The idea behind certificates is that if you trust the identity, honesty, and procedures of certificate issuer "Jean," and "Jean" vouches for the identity of "Chris," you can trust that "Chris" is really "Chris" and not an impersonator. In this example, Jean is acting as a certificate authority (CA).
In addition to a public key, the certificate includes other information to identify its owner, as well as a timestamp that says when the certificate will expire. In the example above, the certificate would be signed by Jean using Jean's private key. Decrypting the certificate's signature with Jean's public key would prove that it came from Jean, and thus authenticate Chris' public key. Anyone who trusts Jean can also trust that the public key belongs to Chris, not someone else.
A Certificate Management System (CMS) is used by a CA to issue and manage certificates. Certificates may be revoked for administrative reasons, or perhaps because the private key associated with the public key in the certificate has been compromised. In this example, Jean would invalidate Chris' certificate if Chris' private key was compromised in some way. Jean's CMS places Chris' certificate on a Certificate Revocation List (CRL) when Jean revokes Chris' certificate.
The two most critical things done by a CA are protecting its private key and creating and following a comprehensive, documented procedure for validating the information in the certificates it issues. If the CA's private key were compromised, nobody could trust it or the certificates purportedly signed by it. Just as important, Jean must make sure that Chris really is Chris. This is a matter outside the realm of cryptography and IT. Depending on its thoroughness, the validation procedure can be costly. A CA may issue different grades of certificates, corresponding to different procedures used to validate identity.
Protecting Your PKI Assets
Normally you obtain certificates by purchasing them from a CA. If you only need a few certificates, perhaps for a web server, this is certainly the preferred option. It is possible to become your own CA so you can issue your own certificates. If you want to deploy everyday-quality certificates for use inside your organization only, you need to determine the cost trade-off between this and buying the certificates. Generating certificates that are to be used or recognized by outsiders is another matter entirely. Don't even think about it unless you are a very large organization that can afford the cost of the expertise and operations, and you have a significant need to generate many strong-quality certificates.
PKI operation depends on protecting private keys. Sometimes keys are generated by a computer and stored in memory and on disk. This is acceptable for everyday security. However, it is possible for someone to break into the computer -- perhaps in person, perhaps over a network -- and retrieve the private key. As a result, very sensitive information or resources need greater protection. Specialized hardware peripheral devices can provide stronger security by generating keys, signing, and decrypting information, so the private key never leaves the device. Protecting the key then becomes a matter of protecting the device from unauthorized use. It may be carried by its owner, locked up, password protected, etc.
Most enterprises use PKI even without having their own certificates or keys. If you have ever received a message from your web browser about an invalid certificate, that was PKI in action. Many Virtual Private Networks (VPNs) use PKI for their security protocol.
SSL (Secure Socket Layer) can use PKI to authenticate the identity of a website. When you are making a purchase over the Internet, you want to be sure that the merchant really is who it says it is. The merchant's site certificate is the proof.
An alternative to SSL, S-HTTP (Secure HTTP), is another Internet protocol that uses PKI. As its name implies, S-HTTP is an extension to the Hypertext Transfer Protocol (HTTP), the protocol used by web browsers and servers. S-HTTP allows the client to send a certificate to authenticate the user, while in SSL only the server can be authenticated. S-HTTP is more likely to be used in large financial transactions and other situations where the server requires authentication from the user that is more secure than a user ID and password.
There are some widely-used applications that do require you to have a certificate and/or keys. One common application of PKI is to sign email. Another is if you own or use a website that requires you to supply a certificate to allow others to authenticate your website or client.
The ability to sign email is available on many popular email systems. For example, Microsoft Outlook includes the use of X.509 certificates to sign and encrypt email. X.509 is a widely implemented international standard. Outlook stores certificates you have installed or received from others. Once you get and install your certificate, you can sign email and include your certificate to authenticate that you are the author. Conversely, when you receive a certificate from someone else, Outlook learns and stores their public key. Then you can encrypt email to that person, assuring privacy.
You don't have to rely on Outlook or certificate authorities to use PKI with email. PGP (Pretty Good Privacy) is a technology for PKI-based security that was originally developed at MIT and has since been commercialized and standardized by the IETF. PGP lets you sign and encrypt information without relying on CAs for certificates. You can add this capability by purchasing PGP software for email systems from Microsoft, Qualcomm (Eudora), Apple, Lotus, and Novell. PGP will interoperate with X.509.
Drawbacks of PKI
PKI's privacy and authentication measures work well for any two-way communication. Authentication also works well for one-to-many communication, such as signing a document or an email that many people will read. However, privacy is another matter. Remember that privacy works by having the sender encrypt the information with the recipient's public key. What if there are multiple recipients on an email message that should be kept private? There is no simple answer for this.
Another drawback to encrypted email or any information is the possibility of losing your private key, which is required for decryption of information that is sent to you. The problem is worse with PKI than with symmetric encryption, because you are the only one who has your private key. A simple method to protect your private key is to back it up on a floppy. Then if you lose your hard drive, you have another way to get at your private key.
On the other hand, if someone else got access to the floppy, then your private key would be compromised. You would have to have your certificates revoked and get new ones issued, along with a new private key -- a major hassle. And what about documents that might have been forged before you discovered the problem?
Some systems offer stronger methods to back up keys. For example, a private key can be split into several pieces, called shares. The shares can then be given to different trusted people, or encrypted with each of their public keys and stored (perhaps on a floppy!) by the key's owner. In either case, it is impossible for one person alone to reconstruct the private key. If you plan to use PKI on a large scale or to protect information over a significant period of time, the ability to recover or reconstitute lost keys should be on your product requirements checklist.
Is "everyday" PKI security enough for your organization? If all you are doing is encrypting and signing email or authenticating your web server, everyday security is probably good enough. However, with PKI you have an opportunity to streamline your procedures for protecting and sharing sensitive and valuable information. Appropriate use of PKI can reduce costs, speed operations, and open up new business opportunities by allowing you to safely access and obtain that information via your internal network. If you access your data over the Internet, you will want to use a stronger level of PKI, with more sophisticated software, operations, and longer keys. You owe it to yourself to investigate what doors PKI can open for you and your organization.
ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection -- The Directory: Authentication Framework, June 1997. A widely deployed, international standard for certificates
http://www.ietf.org/rfc/rfc3280.txt -- Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile (RFC 3280)
http://home.netscape.com/eng/ssl3/draft302.txt - The SSL Specification
http://www.uk.pgp.net/pgpnet/pgp-faq - A PGP FAQ
http://www.ietf.org/rfc/rfc2440.txt - The PGP Standard (RFC 2440)
Applied Cryptography, Second Edition by Bruce Schneier, John Wiley & Sons, New York, 1996 -- Offers a detailed discussion of cryptographic techniques including PKI (also an impressive-looking addition to your bookcase)
Beth Cohen is president of Luth Computer Specialists, Inc., a consulting practice specializing in IT infrastructure for smaller companies. She has been in the trenches supporting company IT infrastructure for over 20 years in a number of different fields, including architecture, construction, engineering, software, telecommunications, and research. She is currently consulting, teaching college IT courses, and writing a book about IT for the small enterprise.
Debbie Deutsch is a principal of Beech Tree Associates, a data networking and information assurance consultancy. She is a data networking industry veteran with 25 years experience as a technologist, product manager, and consultant, including contributing to the development of the X.500 series of standards and managing certificate-signing and certificate management system products. Her expertise spans wired and wireless technologies for Enterprise, Carrier, and DoD markets.