Volume Number: 25
Issue Number: 06
Column Tag: Security
By Michele (Mike) Hjörleifsson
Public Key Infrastructure, or PKI, is a mature set of tools and technologies that serves as the basis for securing most network communications and dozens of other security technologies. It is one of the most misunderstood technologies in the IT arena. This series of articles presents a brief history of PKI, explains how it's currently used, and describes how you can implement PKI in both small and large OS X implementations for various types of security without breaking the bank or causing excessive brain strain.
Let's start at the beginning,. PKI has evolved from a theory and paper published in 1976 by Diffie-Hellman describing the use of asymmetric ciphers versus symmetric ciphers in a white-pages-like directory where you could pull down or validate an individual's public key. This theory was initially put into practice by a group of mathematicians from the Massachusets Institute of Technology (MIT), namely Ronald L. Rivest, Adi Shamir, and Leonard M. Adleman, more popularly known as RSA. RSA's premise was based on the understanding that when you multiply prime numbers together, there is no easy way to reduce the product back to its source. And, the larger the number, the more difficult it is to reduce, making this technique ideal for cryptographic operations that could be implemented to achieve Diffie-Helman's original and additional cryptography goals. Wow, sounds very technical. Under the hood it is quite technical mathematically but here's a more understandable explanation.
A symmetric key encryption scheme requires two or more parties to have a shared key. Think of this as a decoder ring you find in a box of cereal. As long as all the required parties have the decoder you can send encrypted messages back and forth to each other secretly. The big question about symmetric keys is how do we get the decoder ring to everyone in a way that prevents it from being compromised? Enter asymmetric key schemes that, in contrast, have two sets of keys, a private key (your secret key) and a public key (something you send about). The sender of a message uses your public key to encrypt or sign a piece of information and transmits it to you (we will get into the differences between encrypting and signing later). You use your private key to decrypt or verify the signature. Only the private key can decrypt making this a pretty good system, and quite secure.
Now that we have a basic understanding of asymmetric keys, let's talk about how this is implemented in today's technologies that you are most definitely familiar with. When you purchase an item at an online store you are normally directed to a secure page indicated by an https URL in the address bar, commonly known as an SSL protected, or secure sockets protected web page. Without your knowledge, in most cases, your browser has a very fast conversation with the server: the server presents its certificate; your browser checks this certificate against a set of accepted root signing certificates it has preloaded; your browser either accepts the certificate and starts an encrypted session or prompts you with the following message indicating it doesn't "trust" the certificate.
A quick word about "trust". With Mac OS X Server and other operating systems, you can create a self-signed certificate that you generate yourself, typically for internal use in your organization or on a test machine. This certificate in no way diminishes the encryption protection created between the browser and the server. The level of encryption is the same regardless of whether the certificate is publicly "trusted" or privately "trusted" (that is, generated by you on your Mac OS X Server). This "trust" (and I put "trust" in quotes for a reason) is created by the browser manufacturers and a group of companies that have established certain procedures and security measures that make them "trusted" by your browser's manufacturer and the public at large.
Now you see that you have been using PKI for several years and may not have known it. PKI is the technology behind the certificate: how it's generated; how it's validated; and who is or is not trusted.
Let's take another item we are all familiar with: a credit card. I assume anyone reading this article has at least one or more cards with either of the two major card issuer's logos on it. Why is this card accepted at retailers and online stores worldwide? Why do they "trust" your card? Well, you applied for the card, the card company verified your information and then issued you a card with a unique number on it. They also have established a trust relationship with millions of vendors in both brick and mortar and online stores. This concept is quite similar to how PKI works.
In the PKI world, you apply for a certificate to an RA (registration authority), the RA validates your information and, if valid, sends a request to a CA (certificate authority) to issue you a certificate. This certificate has information about you, your organization and a serial number, just like a credit card does. You receive the certificate and use it for one of a myriad of potential uses such as securing a website, signing email, signing documents, smartcard authentication, and perhaps opening a door at your office. When you use the certificate, a VA (validation authority), aka Online Certificate Status Protocol (OCSP) responder, validates your certificate similar to the way your card is validated and checked against your available balance when you use your credit card. Just like your credit card, your PKI certificate can have a PIN (personal identification number) assigned to it to lock or unlock it. Amazingly simple conceptually, yet, as you will see, it is quite powerful and useful.
So what can we do with these neat little certificates and how can we issue our own? For starters, almost all of the services provided with Mac OS X Server can be secured using SSL, also known as TLS (transport layer security). These include iChat Server, iCal Server, Mail, OpenDirectory, VPN Server, Web Server, and Collaboration Services (Wiki/Blog/Web Calendar). They all need a certificate to function properly. Additionally, you can secure access to your wireless through the RADIUS service and a technology known as 802.1x using a certificate to ensure only your users get on the wireless network, not just anyone that figured out some shared key that is probably on a post it note somewhere in your office.
You probably weren't aware of this but Mac OS X Server automatically generates a self-signed server certificate you can use for services during its install process. This certificate can be managed from the Server Admin tool by clicking on the Certificates icon. This is the most basic of certificate administration tools. There are several ways you can issue and manage certificates. For smaller environments, Apple provides the certificate assistant located in your /System/Library/Core Services folder. In next month's article, we will delve into setting up your own certificate authority and issuing certificates using this tool. Also, for larger installations, there is an open source project called EJBCA (Enterprise Java Beans Certificate Authority) that offers both free community support and paid for corporate support and training. To download and install EJBCA go to www.ejbca.org. Support, training, and customization are provided by PrimeKey Solutions (www.primekey.se). EJBCA will be described in detail in a future article. For now, just take a look at your Mac OS X Server and play around with the Certificate function to create some self-signed certificates and use them to test some services. Be careful not to delete the default certificate if it is already in use to prevent disrupting anyone's ability to connect to a given service.
So we have started down the wonderful road to public key infrastructure (PKI). With this basic understanding under our belt, we can build our own certificate authorities, generate our own web and other certificates and learn how to use PKI for some pretty neat security functions like email and document signing. Till next month, stay secure and happy computing.
Michele (Mike) Hjörleifsson has been programming Apple computers since the Apple II+, and implementing network and remote access security technologies since the early '90s. He has worked with the nation's largest corporations and government institutions. Mike is currently a certified Apple trainer and independent consultant. Feel free to contact him at mhjorleifsson@me.com
