Part I design and Planning

Part I Design and Planning

I recommend reading the following MSPress books on PKI and Certificate Services before implementing a Windows PKI, or any PKI for that matter. Both books are written by Brian Komar.

Here is a link to the Windows 2003 Book: http://www.microsoft.com/learning/en/us/Books/6745.aspx

And a link to the Windows 2008 Book: http://www.microsoft.com/learning/en/us/books/9549.aspx

They are both excellent resources for anyone implementing, managing, or designing solution that use a Microsoft PKI. And both books go into far more detail then I can here.

Why Deploy a PKI?

There are a host of reasons to deploy a PKI; a few are listed here:

• 
  Control access to the network with 802.1x authentication
  
• 
  Approve and authorize applications with Code Signing
  
• 
  Protect user data with EFS
  
• 
  Secure network traffic IPSec
  
• 
  Protect LDAP-based directory queries Secure LDAP
  
• 
  Implement two-factor authentication with Smart Cards
  
• 
  Protect traffic to internal web-sites with SSL
  
• 
  Implement Secure Email
  

• 
  Active Directory
  
• 
  Exchange
  
• 
  IIS
  
• 
  Internet Security & Acceleration Server
  
• 
  Office Communications Server
  
• 
  Outlook
  
• 
  System Center Configuration Manager
  
• 
  Windows Server Update Services
  

The next thing you want to think about is cost. I understand how difficult it can be to get budgets approved in any business. Despite our wishes as technology professionals that we could implement the appropriate solutions, sometimes we are handicapped by the budget that we have to complete a project. How much money is your business willing to invest in the PKI solution? What are the costs for implementing a PKI? Here are some items that may need to be included in your budget:

• 
  Servers
  
• 
  Hardware Security Modules (HSMs)
  
• 
  Backup Devices
  
• 
  Backup Media
  

• 
  Windows Server Licenses
  

• 
  Paying someone to design, implement, and manage the PKI infrastructure.
  

While you are planning your budget, it is important not to forget the cost savings that a Windows PKI solution can provide. The two key areas of savings that I see in a PKI solution are:

Microsoft CA’s, especially Enterprise CAs, have a tight integration with Microsoft products. The integration makes managing and requesting certificates from Microsoft Operating Systems and applications fairly straight forward, to the point that you do not really need any PKI experience to be able to request a certificate.

The greatest advantage of the Windows PKI solution is automation. An Enterprise CA is tightly integrated with Active Directory. Using autoenrollment, a simple group policy can be configured to automate the deployment of certificates to computers and users. The deployment is so transparent, that users do not have to do anything to request a certificate.

In designing your PKI solution you will have to take into account the resources you have to manage the PKI solution. Day-to-day management for the most part is very limited, but you will need someone to provide the care and feeding of your PKI. You will need someone to issue and revoke certificates. You will need to have someone manage the hardware, apply patches, take backups. In other words, you need a Server Administrator. Also, you will need to have someone that publishes Certificate Revocation Lists and manages the CA itself.

You will need to determine the level of security required for your PKI. In order to determine the level of security it is important to step back and understand what a Public Key Infrastructure and the certificates associated with the Public Key Infrastructure can be used for. Certificates can be used for identification, encryption, non-repudiation, and in some cases authentication. In your organization you probably have some standard on how a user receives a user account. When hired there was some form indicating that he/she needs a domain user account and the manager approves this form; in other words, the manager was assuring the identity of the user. Since certificates can be used for identification the same standard should be used when issuing certificates, if they are going to be used for that purpose. If you are using certificates just for encryption, you may be less concerned with the user’s identity. If using the keys from the certificate for encryption, it would depend on what data is being decrypted. If a user is just encrypting his/her recipes you may perhaps not require the same level of protection of the private keys as you would if the user is encrypting top secret government documents. In other words the level of security is going to be determined by the level of risk. This determination should include any corporate security policies for PKI and certificates. When creating your PKI security policy, you should also consider any industry or government regulations.

The flexibility and scalability of your solution should be taken into consideration. If you have a high level of confidence that you will not need to change or adapt your PKI solution you can have a fairly simple design. However, if you need a solution that will need to support a variety of technologies, different levels of security, and a global presence, then your solution can get much more complicated.

When designing your PKI solution you will have to determine the hierarchy that you will use. There are generally three types of hierarchies, and they are denoted by the number of tiers.

A single tier Hierarchy consists of one CA. The single CA is both a Root CA and an Issuing CA. A Root CA is the term for the trust anchor of the PKI. Any applications, users, or computers that trust the Root CA trust any certificates issued by the CA hierarchy. The Issuing CA is a CA that issues certificates to end entities. For security reasons, these two roles are normally separated. When using a single tier hierarchy they are combined. This may be sufficient for simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility. The level of security can be enhanced if the CA’s keys are protected by an HSM, but at the expense of higher equipment and management costs.

A two tier hierarchy is a design that meets most company’s needs. In some ways it is a compromise between the One and Three Tier hierarchies. In this design there is a Root CA that is offline, and a subordinate issuing CA that is online. The level of security is increased because the Root CA and Issuing CA roles are separated. But more importantly the Root CA is offline, and so the private key of the Root CA is better protected from compromise. It also increases scalability and flexibility. This is due to the fact that there can be multiple Issuing CA’s that are subordinate to the Root CA. This allows you to have CA’s in different geographical location, as well as with different security levels. Manageability is slightly increased since the Root CA has to be brought online to sign CRL’s. Cost is increased marginally. I say marginally, because all you need is a hard drive and Windows OS license to implement an Offline Root. Install the hard drive, install your OS, build your PKI hierarchy, and then remove the hard drive and store it in a safe. The hard drive can be attached to existing hardware when CRLs need to be re-signed. A virtual machine could be used as the Root CA, although you would still want to store it on a separate hard drive that can be stored in a safe.