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

Demystifying PKI: Enterprise Environments

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

By Michele (Mike) Hjörleifsson

Last month we deployed a Certificate Authority using the built in tools on OS X Leopard (client or server). While this simple routine works well for smaller environments, it does not scale well. And, more importantly, it does not provide some key features an administrator would want to implement in a larger environment.

For instance, say you issued a certificate for a user to sign and encrypt their email. Later, that user has moved on to another company. How do you ensure the user isn't still using that certificate to sign emails as authentic your company emails? This is a key component in a certificate system and it is called revocation. Certificate revocation is typically performed in one of two ways. Certificate revocation lists (CRLs) are the traditional way of maintaining a list of which certificates are no longer valid. CRLs were provided or distributed to resources that validated the certificates. This method proved a bit inefficient and "offline" so a newer technology called Online Certificate Status Protocol (OCSP) was developed to allow for online validation and revocation of certificates in a more dynamic environment.

OpenSSL, which the internal OS X Certificate Assistant utilizes, though handy (and maybe a little clunky) isn't built for certificate management for medium to large infrastructures, nor does it provide effective mechanisms for validation of certificates for more than just website related uses. It does provide a quick and dirty way to create certificate requests, create certificates, sign and encrypt documents on a small scale. However, when you need to manage dozens if not hundreds or thousands of certificates, OpenSSL has major limitations, as it is not designed to be a full-fledged CA with all the associated management functionality. This limits the ability of administrators to effectively deploy a powerful set of digital signature and encryption tools readily and now freely available to them. Finally, OpenSSL has experienced some setbacks on the security-vulnerability-an-implementation front, casting additional shadows on utilizing it in mission critical and larger deployments.

As previously discussed, there are several roles that can be implemented in a PKI infrastructure even if only on one machine. This is a crucial concept and worth a quick review. The most recognized of the roles is the CA: an authority in a network that issues and manages security credentials and public keys for message encryption. As part of a public key infrastructure (PKI), a CA works with a registration authority (RA) to verify information provided by the requestor of a digital certificate. If the RA verifies the requestor's information, the CA can then issue a certificate. Depending on the public key infrastructure implementation, the certificate includes the owner's public key, the expiration date of the certificate, the owner's name, and other information about the public key owner.

An RA is an authority in a network that verifies user requests for a digital certificate and then tells the CA to issue it. RAs are part of a PKI a networked system that enables companies and users to exchange information and money safely and securely. The digital certificate contains a public key that is used to encrypt and decrypt messages and digital signatures.

Validation Authority (VA) offers a comprehensive, scalable, and reliable framework for real-time validation of digital certificates. In most implementations, one or more of the authorities will access ancillary information in an LDAP (lightweight directory access protocol) based directory service such as OpenLDAP, Open Directory, and Active Directory to tie a digital identity to a username or named account.

OpenSSL does not provide a user-friendly, or even administrator-friendly way to accomplish the RA and VA tasks and provides a basic level of CA functionality, which does not scale. More importantly, OpenSSL doesn't provide a straightforward OCSP function, which has become more and more of an issue. Once you issue a certificate, you will want these other services. When it comes time to move from a single server or small group of servers with just SSL certificates deployed to a more leveraged use of PKI for larger numbers of servers and other PKI-based technologies like digital signing, smart cards and encryption, it's time to look at a properly designed certificate authority infrastructure.

So how do you get started? We'll first we need to pick an enterprise certificate authority to use in our environment. This begs yet another question, how do we pick an enterprise certificate authority for our environment?

There are several commercial options and open source alternatives; let's give them each a quick review. Some of the players in the CA software landscape offer an optional managed service PKI that is designed so the manufacturer hosts the infrastructure and the client has web-based access to this system typically over a secure channel like SSL/TLS. While this option may be attractive to some, it has some implications to be aware of. First, your certificates will be stored in their facility on their equipment; this may or may not be acceptable to your project. Second, these services are typically designed for high volume customers and can bear a significant monthly recurring cost. Last, but not least, they may or may not provide the types of issuance services you need. For instance, one vendor may provide SSL certificate issuance and code-signing, but neither digital signature nor smart card identity capabilities. Among these vendors are VeriSign, Thawte, Entrust, Verizon, OpenTrust, ChosenSecurity, and each provide a different set of and different levels to there managed services.

Assuming you want to build your own PKI infrastructure your options are pretty limited on the Mac OS X Server platform. As such, I will point out the market leaders in the commercial CA space and the open source alternatives. Arguably, the industry leaders in the commercial CA marketspace are RSA, Entrust, Information Security Corp and Ascertia.

RSAs product is called RSA Certificate Manager or Keon. RSA is recognized as a leader in the PKI and authentication space. Unfortunately, their product only runs on Windows, RedHat and Solaris, not Mac OS X. Entrust's product is called Entrust Authority Security Manager and is designed to run on Windows Server, Solaris, HP-UX and IBM AIX. Information Security Corporation's CA called CertCA seems to be primarily targeted at U.S. government accounts (based on their client list from their website) and has the features expected in a full-scale commercial CA product. It is based on Java and in theory could work on Mac OS X but their website does not indicate that it is supported—only Windows and RedHat are supported. Ascertia's product, called TrustFinder CA, is a full-fledged certificate authority with all the functionality you would expect in an enterprise level product; it is designed to run on Windows Server, Solaris and Linux.

That doesn't leave a Mac OS X server administrator with a lot of choices to run a CA natively, so, lets take a look at our options. Option one is to run one of these servers in a virtual machine using Parallels Server or VMWare Fusion. This is a viable option though not a native OS X solution. Another option is to run OpenCA or Digi-CA (both are based on OpenCA) in a virtual machine. Digi-CA doesn't require any hard drive space and runs as a standalone bootable CD and is quasi-open source. Another option is to put one of these other operating systems into your environment, resulting in a little more administrative overhead.

Don't lose hope, there is an open source project called Enterprise Java Beans Certificate Authority (EJBCA) which runs using Enterprise Java and will run natively on the OS X platform. EJBCA is supported by a corporate entity called PrimeKey Solutions located in Stockholm, Sweden. EJBCA is similar to MySQL in that the software is provided at no cost, but PrimeKey is there to provide support, training and customization services for customers willing to pay for those services. Disclaimer: I oversaw the creation of the Mac OS X installer for EJBCA but I am not an employee of PrimeKey and as such, am not providing a biased view.

EJBCA, the largest open source CA project on SourceForge, is mature and platform agnostic making it a solid choice for managing certificates on the OS X platform. Add this to the fact that it is supported by a corporate entity available for consistent support and custom programming, EJBCA makes a good choice for the Mac OS X administrator. There are many "how to" and installation documents on the EJBCA website (ejbca.org) for deploying EJBCA and associated projects such as signserver.org and hardtokenmanagement.org for deploying specific PKI functionality for signing email, documents and smart cards.

You can download the EJBCA Mac OS X disk image (dmg) from ejbca.org the disk image will automount (double-click it if you have disabled auto-open of 'safe' downloads), and then just double-click and launch the installer. Currently, only Leopard Server on Intel is supported. OS X Leopard 'client,' Tiger and PPC supported installer development will depend on community response and demand. The install is very straight forward and installs the underlying jBoss and other required components, a good how-to is posted on their website, though none is really needed: the installer uses a true OS X meta-package.

With EJBCA installed you can refer to their extensive how-tos and documentation on administering your CA, all of which, thankfully can be done from their web interface, so you can get right to issuing your certificates.

So we have discussed various ways to issue certificates and keys for different purposes but what happens when an employee or member of an organization leaves or an entire organization goes defunct? How do we check to ensure the validity of their credentials? Enter certificate revocation lists (CRL) and the newer online certificate status protocol (OCSP).

CRLs are a list of certificate serial numbers that are no longer valid. These lists are distributed or made public so that outside organizations can verify the validity of a certificate. CRLs maintain one of two states for a certificate: hold or revoked. The revoked state is pretty obvious and is an irreversible state that tells outside entities to no longer trust the validity of that certificate. This can happen for several reasons: the CA may have become compromised and therefore had to reissue a set of or all certificates; the individual it was issued to is no longer employed or associated with the issuer; or the organization issued a certificate provided false information to attain a certificate and was found out and their certificate revoked. The most common reason is that a user lost their private certificate and needs to have a new certificate generated, voiding the original certificate. The hold state, on the other hand, is a reversible situation and is commonly used when an individual is on leave for an extended period of time, or thought the key was lost and then found it and has shown it was not compromised or accessed by unauthorized personnel.

A CRL is generated and published periodically, after a clearly defined timeframe, usually every calendar day. A CRL can also be published immediately after a certificate has been revoked, which is a very common situation in practice. The CRL is always issued by the CA that issued the corresponding certificates. All CRLs have a lifetime during which they are valid; this timeframe is often 24 hours or less. During a CRL's validity period, it may be consulted by a PKI-enabled application to verify a certificate prior to use.

To prevent forged or spoofed CRLs, CRLs usually carry a digital signature associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed, which can usually be found in a public directory.

This method works fine but has its limitations. OCSP was developed to provide a more online and robust system to verify the validity of certificates in an online and real-time fashion. Inherently, OCSP servers respond to validity requests and are most often referred to as OCSP responders. OCSP requests and responses do not contain as much information as a CRL and as such can be faster and more responsive than a CRL list, which is well suited to high volume transaction sites.

OCSP responders typically use the HTTP protocol as the mechanism for the request and response. OCSP discloses to the responder that a particular network host used a particular certificate at a particular time. The entire CRL is not disclosed making it more efficient, but also more open as it does not validate the identity of the requestor because this is typically seen as unnecessary. Here is an example of an OCSP transaction from wikipedia.org that illustrates the process in simple terms:

1. Alice and Bob have public key certificates issued by Ivan, the CA.

2. Alice wishes to perform a transaction with Bob and sends him her public key certificate.

3. Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that contains Alice's certificate serial number and sends it to Ivan.

4. Ivan's OCSP responder looks up the revocation status of Alice's certificate (using the certificate serial number Bob provided) in his own CA database. If Alice's private key had been compromised, this is the only trusted location at which the compromise would be recorded.

5. Ivan's OCSP responder confirms that Alice's certificate is still OK, and returns a signed, successful 'OCSP response' to Bob.

6. Bob cryptographically verifies the signed response. He has Ivan's public key on hand (Ivan is a trusted responder and ensures that it was produced recently.

7. Bob completes the transaction with Alice.

This may seem a little much for a simple transaction such as purchasing a book on amazon.com but don't let this fool you. These 7 steps happen in seconds and are typically handled by your browser or other software used to initiate a transaction, making them transparent to you.

OCSP responders are commonly referred to as the validation authority (VA), though some commercial manufacturers produce VAs that have additional functionality beyond the basic OCSP validation transaction.

Hardware Security Module (HSM) – a device used to generate cryptographic key pairs, keep the private key secure and generate digital signatures. It is widely used to secure the root key in a PKI system. Using the PKCS#11 programming interface, applications send a digest of the document to the HSM, which encrypts it with the private key, creating the digital signature. HSMs can be very sophisticated in order to keep intruders from gaining access to the private key." (source: http://dictionary.zdnet.com/definition/HSM.html)

This is a pretty technical sounding and obscure definition to the non-initiated PKI traveler, so let's simplify.

An HSM serves two primary purposes, which are stated in ZDNet's definition above. An HSM acts like a computational safe, protecting your private keys from prying eyes and preventing duplication through a hardware scheme that is usually unique to the manufacturer. Secondly, HSMs are designed specifically for this purpose so they can offload cryptographic mathematics from your servers (which can get very computationally intense in high volume installations) and provide better randomness when generating keys. Randomness is important, as it is the basis for ensuring the strength of the cryptography used to generate keys.

HSMs tend to be split into two camps: PCI cards that you insert into the server you are using for a certificate authority or other cryptographic use; and Net HSMs which are connected (typically on a closed private network) to a group of servers that can utilize the functionality of the HSM(s). There is a third, less popular method of using smart cards as an HSM for smaller installations. While this is a valid way to secure private keys for smaller environments, it does not scale very well for larger environments.

The National Institute of Standards and Technology (NIST) created a standard, called FIPS 140. FIPS is an acronym for Federal Information Processing Standards. 140 refers to the standard that accredits cryptography modules. You will commonly see a vendor state FIPS 140-2 Level 2. So, let's break that down to something understandable:

FIPS - This is the collection of all federal information processing standards.

140 - This is the standard under FIPS that deals with cryptographic modules.

-2 - This is the current revision of the standard.

Level 2 - There are currently four levels associated with the standard, these levels deal with the type of protection and amount of protection provided. Namely:

Level 1 – No specific physical security mechanisms are required

Level 2 – Requires tamper-evidence like tamper-evident coatings and so on.

Level 3 – Adds tamper detection and response to Level 2 requirements

Level 4 – Currently the highest level, it provides for deletion of keys to protect them in case of penetration or tampering by unauthorized persons or devices

Now that we know what an HSM is, and that the United States Federal Government has been nice enough to provide a ranking system for the security stance of each one, more questions arise that we need to answer. Why would you want to use one? Which level is right for your project? Who are the players in the HSM space?

There is a simple equation to determine whether you need to use one and the level of physical security the cryptography module you use in your environment should have. How much will it cost you and your organization in lost revenues, bad press, and customer perception if your private keys were to become compromised and that information made public? If the dollar amount is more than the cost of an HSM, then you should be using an HSM. It is quite simple; the HSM's sole purpose is to protect your keys and offload cryptographic functions for speed. If your private keys are lost, your entire PKI infrastructure is at risk or compromised. In my professional career, I have been asked several times whether a customer needs or doesn't need an HSM. The risk assessment equation is my typical answer but I always suggest at least a minimal HSM (such as a smart card HSM) as it doesn't make a lot of sense to spend the time to deploy PKI and then not protect your private root keys. It's akin to building a bank safe and leaving the combination on a post it note on a teller's computer terminal.

There are several players in the HSM space. The smart card HSM is an option for EJBCA provided by PrimeKey, which makes for a simple integrated basic solution for the most common uses of PKI in smaller organizations. nCipher, AEP Networks, Utimaco, and SafeNet are the major players in the commercial HSM space. Each has a different approach to protecting your keys and most have FIPS certification. If you are looking for a PCI-based HSM, SafeNet, and nCipher are your best bet. These products are mature and have maintained the federal certifications for one more certification cycle. For a network-based HSM, Utimaco, nCipher, SafeNet and AEP all have offerings and the decision comes down to your needs for redundancy and security level. AEP Networks' Keyper HSM offers optional load balancing so that you can provide intra or inter data center redundancy, which is of concern for larger deployments or for greater up-time requirements. Utimaco, nCipher and SafeNet all make decent network-based HSMs with varying certification levels. Be wary though of possible discrepancies between vendor claims and actual certification levels. To be sure of a vendor's certification level you can check the NIST's website directly at:

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2009.htm

For Level 4 protection, which is the highest level provided by the FIPS certification, your options are limited to the AEP Networks Keyper HSM, and IBM eServer zSeries 900 CMOS Cryptographic Coprocessor. These are the only two cryptographic modules that have obtained an Overall Level 4 certification by NIST at the time this document was written. The IBM product is typically used only in financial services devices such as ATMs and as far as I can tell is not for commercial PKI use. AEP Networks has a good case study on their website about how ICANN (the internet authority for the U.S.) used the Keyper in a DNSSec environment. I have worked with several of these HSM products and for the level of security and transaction capability versus the dollars paid, I prefer the PrimeKey HSM for small installations and the AEP Keyper for larger, more secure installations. They are both relatively easy to configure, have a reliable track record and good support from the manufacturers which are both focused on PKI technology and not just providing the HSM as an also have product.

In next month's installment, we are going to start putting all this knowledge to practical use in our Mac OS X environments. First stop, web site authentication with the certificates we issue from our newly installed CA.

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