Volume Number: 25
Issue Number: 09
Column Tag: Security

Demystifying PKI: Enterprise Environments - Part 4

A Series of Articles and How-Tos about PKI technology in the OS X environment m

by Michele (Mike) Hjörleifsson

Last month we discussed the deployment of an enterprise class Certificate Authority and how to protect your keys. This month we are going to put our PKI knowledge to practical use. Since you spent the time deploying a CA it's worth looking at what PKI can be used for. There are a myriad of security and assurance implementations that use PKI today, most of which work so well we barely give them any thought. It is worth a quick review to ensure you get the most out of your PKI infrastructure.

PKI implementations can be broken down into four general categories:

Digital signing is the utilization of a PKI key and an associated algorithm (such as SHA1 or SHA2) that is run against a piece of data to create a signature. Although it sounds complex, you may not realize that you use these all the time. Software Updates from vendors like Apple, Microsoft, Google and thousands of others use a signature to ensure that their update reaches your device (yep, that includes the iPhone) intact and untouched by outside forces. All applications on the iPhone have to utilize a digital signature to verify authenticity. Other common uses of digital signatures include the replacement of a physical signature in contractual documents such as PDF files with a digital signature and, digitally signing emails to assure recipients that the email in fact came from the titled author. More complex applications include digitally signing requests to modify DNS records, referred to as DNSSEC (DNS Security) or digitally signing network routing requests, referred to as SIDR (Secure Internet Domain Routing). A newer implementation is to utilize digital signatures to ensure the authenticity of video files such as video recorded depositions.

Encryption and digital signatures are commonly confused. A digital signature is a signature created by running a mathmatical formula against a piece of data with one of your keys to make changes evident. The original piece of data is not affected, whether it is an application, a PDF file, a word document and so on. Encryption on the other hand actually utilizes the PKI key to make the data unreadable to anyone without the corresponding keys and actually acts on the data in question. You can encrypt documents, e-mail messages and even network traffic to keep prying eyes from looking at sensitive information such as personal data and credit card information. If you have ever purchased something on the Internet from an SSL-secured site, you have used PKI-based encryption.

Smart cards have been around for some time. They utilize PKI credentials issued to an individual to allow that person to verify their identity to an operating system, or a website etc. The problem with smart cards to date has been the requirement of an external reader. There are several manufacturers that provide USB stick smart card solutions that include the reader and secured storage for your certificates on a small portable USB stick, without the requirement of an additional reader. Companies like BestToken, Gemalto, and Centrify provide OS X compatible smart card solutions. The drivers and underlying frameworks for these solutions are built in to OS X Leopard. That being said, you aren't limited to using smart cards for authentication. Once your credentials are issued you can simply store them in your keychain and use them to authenticate to websites, or web applications. When keys are created for you as an individual, they can be "permission'd" to act as authentication and signing credentials. Alternatively, two separate sets of keys can be issued depending on your preference. You can add protection to these keys by requiring a passphrase—I highly recommend this. Use a PIN code because they are easier to remember and without the physical key and PIN code the key is useless. We will examine protecting a website with PKI keys later in this article.

So what is the difference between authentication and authenticity? In this context, PKI can be used to authenticate the validity of a person, computer or other item. For instance 802.1x network authentication is a standard used for securing access to a network at the wired or wireless layer, prior to talking to any servers. You can issue PKI certificates to devices (such as laptops) to allow access to the network or you can do it by user. Printers commonly use PKI certificates to check the authenticity of the toner cartridge you put into the printer. Wireless providers utilize authenticity certificates to ensure the device connecting to their wireless network is an authentic device provided by that carrier (or allowed by that carrier). Sounds expensive right? In today's market the certificates that are needed to embed into product packaging or the electronics of a product can be bought in bulk for about a dollar or less depending on quantities. The business question is simple: Is it worth the dollar to ensure the authenticity of the device or product? Well, for things like cell phones, controlled pharmaceutical substances, toner cartridges and many others the answer is currently, "yes."

OCSP (Online Certificate Status Protocol) servers become crucial in larger environments or commercial implementations such as product authenticity. Companies need the ability to test and validate whether a certificate that has been issued is still valid, expired or been revoked. For instance, if you didn't pay your cell phone bill, in theory, the wireless provider could revoke your device's certificate or just suspend it until the bill is paid.

Now for the fun part, let's put this knowledge to use. Utilizing either the OS X Certificate Assistant or the EJBCA server you set up in either of the previous two articles, issue yourself a certificate and make sure to include your email address (as it appears in Apple Mail) in the appropriate field. Either method (Certificate Assistant or EJBCA) will create the certificate files. Double click the file to install it into your keychain. You will get a dialog that looks like this:

Figure 1 - importing a certificate into the login keychain.

The Keychain default is set to login which is the correct keychain.

Once installed you will need to trust the certificate. As you can see in the following image, you can trust the certificate for all the permissions provided by the certificate or select the items you want to allow the certificate to be used for. In our case we will just trust it entirely so change the top drop down list box to Always Trust and provide your credentials when prompted.

Figure 2 - Certificate trust.

If you had Apple Mail open, close it and then reopen it. Apple Mail is smart enough to detect the new certificate if the email address in the certificate matches one of your email accounts. Now, compose a message and you will notice two new icons on the left hand side of your message under the subject line. One looks like a lock and the other looks like a stamp you may have received as a 2nd grader for good work. The stamp will have either an X in it or a check mark. The lock represents the encryption status of your message (more on that in a minute).

Figure 3 - Mail.app with certificate support.

The stamp represents the digital signature status of your email. If the stamp is checked, you will be digitally signing your email with the certificate you just installed. You can always shut off the signature by clicking the icon. You will not see any difference in the email itself. Why not? Good question. The digital signature enables S/MIME (Secure MIME, or Multipart Internet Mail Extensions) which is embedded in the header of the email, not in the visible body. Most email clients (including Outlook, Notes, Thunderbird and Apple Mail) will automatically recognize digitally signed emails. However, be aware that fax services such as e-fax and myfax do not like digital signatures on outbound faxes so be sure to shut off digital signatures on any outbound faxes. That was easy, but what did we accomplish? Every signed mail you send from that point forward will assure the recipient that it was sent from you and no one else and that it wasn't tampered with since you authored it. This is pretty important in many scenarios.

Figure 4 - lock icon showing encryption.

The lock is the other item you can enable and disable, but only if you have previously accepted a certificate from the recipient you are sending the mail to. Seems confusing but let's review the concept. When you send your mail with a digital signature, the recipient can double click the seal icon and then accept your certificate and send you a signed email in which you will do the same. Now that you each have the other's public key, you can create an email and encrypt it with the public key of the recipient. Only the recipient can open the email because the recipient is the only one with the private key, which has not been shared with anyone. So what is the difference between signing and encrypting the email? Simple; signing just validates you as the sender and indicates whether the email was tampered with since you sent it. It DOES NOT hide (through encryption) any of the contents of the email. When you need to send private or sensitive information encryption is appropriate. When you are just sending standard emails, a signature should be enough.

You can also use the same infrastructure to issue certificates to users whom you want to have access to protected web content. First, you issue the certificates to the users and have them install the certificates (the same way you just did) or use Apple Remote Desktop (or any other tool) to deploy the certificate automatically to the client machines/accounts in question. Once installed and trusted you can modify the settings on your server and install a couple of files without changing a line of web code. You will need a copy of the CA root public certificate to accomplish this. You can export this easily in certificate assistant if that is how you are issuing your certificates or on EJBCA.Log on to the administration pages and then go to the configuration. You can download the certificate as a text file. From there, you want a PEM based file format and for our case here we will save the file as "ca.crt". Now that you have that file, log into your OS X Server or open Server Admin. Select the web service, and then select the Site you want to modify. Click the options tab (as shown) and turn on Allow overrides. Your website should already be using SSL, if not click on Security and change it to enable SSL and ensure you have a proper certificate installed.

Figure 5-Server Admin web site options.

Next copy the ca.crt file to your OS X server (if it is different than the server you have the file on now) and put it in a safe directory. For this example, let's use /Library/WebServer/. Create an empty file called .htaccess and place it in the root of the web directory of your site. Next, open it with an editor and place the following lines inside:

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCACertificateFile /Library/WebServer/ca.crt
SSLRequireSSL
SSLVerifyClient require
SSLVerifyDepth 10

That's all there is to it. Now if you try to access the site you may get a certificate warning message (that's if you are using a self-signed certificate and haven't installed that certificate on your local machine). Next, you are prompted to specify which certificate from your keychain to use for authentication. Select the appropriate certificate we installed earlier and voila. No more logons necessary, no realms to manage, no calls to the helpdesk to reset passwords. Single sign-on even from remote locations as long as the client has the appropriate certificate installed. Tip: I recommend that when issuing user certificates that you enable a passphrase and use a 4-6 digit pin. Users tend to remember pin numbers. And, if you are using EJBCA users can logon and self service their own PIN without your assistance. It adds another layer of security without another password which, as we all know, incurs helpdesk calls.

You can extend the functionality to perform live OCSP checks on the certificate and to check for immediate revocation status. That is a little bit beyond the scope of this introduction but more information is available at http://apache.org and http://www.askapache.com.

A quick note, the download information on EJBCA's OS X implementation in last month's article is incorrect. The version was removed from the site temporarily. It is being updated to utilize the latest version of EJBCA and provide an OS X client as well as server installation. Also, the underlying database is being switched from MySQL to Ingres due to the uncertain future of the MySQL database platform given the pending purchase of Sun by Oracle. Ingres is another powerful open source database platform that provides a similar licensing model, free community editions and paid for support and training. Ingres is actually designed from the ground up for deployment in the enterprise. For more information on Ingres see http://www.ingres.com

Thank you for spending time learning about the mystical world of PKI. I hope these articles have shed some light on what PKI is and how you can use it in your infrastructure.

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