Designing a PKI Solution

Written by Neil Rerup, Security Alliance Member and Security Architect extraordinaire, originally posted on LinkedIn.

Over the last few months, I've had a number of recruiters approaching me about a contract they are looking to fill for designing a PKI solution. While I'm have done PKI design before and am interested in doing PKI design again, I'm finding more and more recruiters are trying to low-ball me for what I do and, considering how I value my time, I'm starting to resist responding to these recruiters. That, combined with the fact that I've shifted to the Fixed Fee, Security Architecture as a Service business model, has me finding going through recruiters less and less attractive. I'd much rather work with partners.

That said, there's quite a bit that people should understand about designing PKI solutions and, since I'm being asked to fill a contract, I thought I'd give some thoughts to those of you looking at PKI designs. And if you are looking to get a PKI designed, let me know and we can sit down and talk.

When you are designing a PKI solution, it's not as easy as just installing the Windows Certificate Services on your Windows server. In fact, with PKI, one of the worst things you can do is just look at it from a technology perspective. Remember, your PKI solution is going to hold the keys to your kingdom so you need to take a very professional, detailed look at how you are going to manage your certificates and public/private key pairs.

To start with, remember that all solutions have 3 core components; People, Process, and Technology. Those of you that know me understand I actually believe there's a 4th component and that's Governance. But I'll leave Governance out of this article otherwise this article will turn into a book.

Once you've gathered your requirements for your solution (and these should be from the business level, not from the technical level), start looking at your architectures layers. I'll start with the Business Architecture because that will contain both the people and the process architectures.

With the people architecture, you are going to want to create a RACI for all the people that are involved in your PKI solution. It's not just the administrators that have to be involved. Some of the other roles that you need to think about are:

  • Certificate/Key Requestor - This is the person that needs the output of the PKI solution. If left to their own devices, they will end up making use of self-signed certificates and, when those expire, you'll end up troubleshooting why solutions failed. So make sure you understand who your Requestor is and how they are going to make their requests.

  • Approver - Just because someone wants a certificate doesn't mean they should get one. This is typically tied to the governance of your certificates and keys. They may even be the owner of the PKI solution.

  • Auditors - There are going to be roles that need to audit your system to ensure the integrity of the PKI solution. Maybe you don't need a high level of integrity - if so, maybe this role isn't too important. But if you are looking at PCI or are in the Financial industry (or dealing with critical infrastructure), you'll want to make sure auditing is occurring.

  • Security Analysts - While the administrators are doing the care and feeding of the system, typically your Security Analysts are the End User of the PKI solution. Understand how they will interact with your solution and what processes they will be making use of in fulfilling the requests.

These are just some of the roles that you need to think about. And each role will have it's own processes that they need to deal with (some of which are hinted just in the descriptions that I provided).

Since we are talking about the Business Architecture, make sure you understand the financial model that the PKI solution is supporting. What are the volumes of certificates or keys that need to be managed? If they are of high enough volume, you may want to replace the human roles listed above with some sort of automated system like what Venafi provides (not an endorsement of Venafi). Or do you want to make use of a 3rd party service provider such as Entrust or Verasign? Sometimes, you'll want to have a trusted 3rd party for verifying one part of a Public/Private Key pair. But there are costs associated with this so balance the costs of using either Self Signed Certificates, Trusted 3rd parties (ie. Cloud Service Providers), or building it yourself. These are the keys to your primary assets so make the decision wisely.

Okay, let's move over to the technical components. PKI solutions are built around a concept known as a “Certificate Authority”. The Certificate Authority (or CA) is a central management point for an enterprise’s certificates and keys. Without the CA, you would not be able to efficiently track all implemented Certificates or Keys, you wouldn’t be able to ensure a trust relationship with Public/Private key pairs, and you wouldn’t be able to ensure that encryption within the enterprise is being applied according to your Security standards.

There are typically 4 components in a CA Hierarchy; the Root CA, the Subordinate Intermediate CA, the Subordinate Issuing CA, and the certificate. These are shown in a diagram on Microsoft's TechNet.

Digital certificates created by a Public Key Infrastructure (PKI) Certificate Authority (CA) are verified using a chain of trust. The trust anchor for the digital certificate is the Root Certificate Authority (CA), and any Certificate Authority (CA) which comes under Root Certificate Authority (Root CA) is known as a subordinate Certificate Authority (CA). The following figure shows the Certificate Authority Hierarchy.

Root CA: A Root CA is the topmost Certificate Authority (CA) in a Certificate Authority (CA) hierarchy. Each Certificate Authority (CA) hierarchy begins with the Root CA, and multiple CAs branch from this Root CA in a parent-child relationship. All child CAs must be certified by the corresponding parent CA back to the Root CA. The Root CA is kept in a secure area and it is usually a stand-alone offline CA (to make it topmost secure Certificate Authority (CA). The root CA provides certificates for intermediate CAs. The certificates can be revoked if they are compromised. I would recommend that you keep the Root CA offline, if at all possible.

Intermediate CAs: An intermediate Certificate Authority (CA) is a CA that is subordinate to another CA (Root CA or another intermediate CA) and issues certificates to other CAs in the CA hierarchy. Intermediate CAs are usually stand-alone offline CAs like root CAs.

Issuing CAs: Issuing CAs are used to provide certificates to users, computers, and other services. There can be multiple issuing CAs, and one issuing CA can be used for generating computer certificates and another can be used for generating user certificates.

There are also three other key components to be aware of in a PKI solution (some people may say more but I'm being simplistic for the purposes of this article. Those are your Active Directory (for the roles that are interacting with the PKI solution as well as where you can store your certificates/keys), your Firewalls (for protecting the CAs), and your HSM (storage of keys). BTW, set up your HSM to have one partition for each SubCA.

One recommendation that I would suggest is that you have a SubCA (issuing) for each domain. This allows you to establish trust relationships using key exchange if you are involved in higher levels of security.

If you are setting up a Windows based Certificate Server, you can make use of certificate templates. These are templates that allow you to duplicate the setting for certificates and keys whenever you need a new set of certificates. There is a standard list available through Windows Server that you can leverage if you so wish.

When it comes time to look at approved algorithms, I highly recommend that you leverage the work that NIST is doing. This way you don't have to keep on top of the different algorithms - let NIST do that for you. You can check for the approved algorithms at this NIST page.

There's one last set of details that you need to determine as part of your design (there's a LOT to deal with so don't let this article fool you into thinking this is all you have to deal with). The things that you want to consider are:

  • Key Length - typically, this will be set to 2048 but the longer the better (eg. 4096 bits)

  • Validity Period - how long the certificates or keys will be valid. This is dependent on the type of CA doing the issuing. You would want the Root CA certificates to be much longer than the Issuing CAs (typically is double the length of time) and dependent on how long the equipment that is using the certificates/keys will be in place. Utilities, for example, will put in place smart meters with lifespans of +30 years to the keys/certificates should be at least that long.

  • CRL Distribution Point - you need to be able to point to where the Certificate Revocation List (CRL) is stored. Typically it's your Active Directory, but it can be any location accessible by the devices receiving the certificates/keys.

  • Backup & DR Strategy - Your Certificate Authorities are extremely important to your organization so you need to be very clear about how you are going to backup the CA servers themselves and what the DR strategy is for them.

Like I said earlier, this is a very simplistic article on a complex subject matter. Make sure you have fully considered all areas associated with your certificate and key management. And if you need any assistance, make sure you ask someone that has done this before.

If you have need for a security architect or other security services, please get in touch.