In-Depth
Getting Started With PKI
Computer networks allow people to share resources, but computer security prevents access to resources. How to decide if you need PKI, and a step-by-step guide to installing PKI on your servers.
The phrase computer security is a bit of an oxymoron. Computer networks allow people to share resources, but computer security prevents access to resources. A proper balance allows the right people to access only what they need and nothing more.
This article deals with one aspect of a sound security program—encryption. Before diving deep into encryption, let's back up a bit and see where encryption and certificates fit with network security.
Depending on your network's size and use, you need various levels of security. It's a bit like the difference between securing a home and securing a bank. At home, you normally see only the basics of security—locks on the doors and windows, maybe an alarm system, and if you're lucky, nosy neighbors.
A bank, however, needs a far higher level of security. Not only do banks have locks on the doors and windows, they also have vaults, procedures for vetting employees, video cameras, and even armed guards. To be fair, a bank needs a higher level of security because "That's where the money is."
Networks have similar levels when it comes to their security. For a small network, normally only the basics of security are considered. These basics include evaluating all user accounts and ensuring that any guest access is removed. Strong password policies also play into this level, with history restrictions and duration limits. The first level of security also includes antivirus and spyware-detection software, with policies in place to keep those programs patched and up to date.
Administrators at the first level of security should also pay attention to file and share permissions, and should use NTFS or another secure file system. Another basic tenet of the first level of security is staying current with operating system patches and hotfixes. Finally, this level includes hardening of the network with firewalls and other border protection methods.
Larger networks or those with more sensitive data present an irresistible target for script kiddies and even professional espionage. The unfortunate truth is that the larger the network, the larger the permutations that must be considered for security. These more sensitive networks require the next level of security. The second level of security includes all of the basics, in addition to physical security considerations. Physical security includes limited access to servers and de-installing removable media such as floppy drives. Physical protection on the network includes removing unused network patch cables and locking telecom closets. Wireless networks bring their own challenges to the mix.
Just like the employees in a bank, higher security networks include user community training on security policies and procedures. Any open ports are examined carefully to ensure proper access. Servers are examined to make sure that default administration shares are closed down. Even services and daemons in the second level of security are second-guessed because many of them are not C2 security certified.
Immense networks, or those dealing with national security, medical information, or large amounts of money, move up to the next level of security. Another reason to implement the highest level of security is that when sensitive data is moved through a "mixed" environment, it travels over several networks, or even on open networks such as the Internet.
Administrators at the highest level of security audit just about everything, from logs to login attempts. Often system administrators at this level remove the OS/2 and POSIX subsystems from Windows operating systems and harden remote access for UNIX varieties. Stronger methods of login authentication are often used, such as smart cards or even biometrics.
Network changes at the third level of security contain protocol enhancements such as implementing IPsec. A computer team in a highly secure network might also use "Honey Pots"—systems that are intentionally weakened to attract hackers to evaluate the attack methods and design protective measures for production servers.
You see encryption used most often at the highest level. Keep in mind that security needs are dictated not just by the size of the network but also by the sensitivity of the data. Even a very small network might need a high level of security. This is where Public Key Infrastructure (PKI) comes in.
PKI Described
A PKI is used for two general purposes: encryption and signing. Encryption is the application of mathematical formulas to scramble a message, such that a corresponding set of formulas are needed to unscramble it. Signing is used to prove the owner of the data, such as an e-mail message or even a login.
Let's examine encryption first. We all played with secret decoder rings hidden in boxes of breakfast cereal. These toys normally encode a message by simply shifting the letters of the alphabet a few characters one way or another. By adding or subtracting the number of characters that were shifted, the message can be restored to its original form. Until then, the message is useless to those who happen to see it.
This example shows us two things. The first is that a properly encrypted message can be trusted to be in "plain sight" and still remain secret. This is the premise we use on the Internet when we type in our credit card numbers on eBay. The second highlight from this example is that the encryption method used in this simple construct is quite weak. It's easily guessed by various methods including brute force or just trying combinations of letters until something works.
One of the reasons that this formula is weak is that it is based on a scheme called a "secret" or "symmetric" key. The method used to encrypt and decrypt the message must be known to both parties. If this key is broken the message is available to anyone. Even if the key is much more complex than just shifting the letters around, it's still just a single key and can be broken most of the time with current desktop computers using methods like simple XOR comparisons. This type of encryption isn't even trusted to log people on to computers anymore.
To safely transmit data in plain sight, we need a more secure method. That's where PKI comes in. In this scheme, two keys are used—called an asymmetric key pair. One is private and kept secret from everyone else, and the other is public, known to anyone who asks. The public key is used to encrypt a message, and the private key is the only one that can decrypt it.
Everyone's computer knows the public key—we'll find out how in a moment. When the message Tad is entered, the public key is used to scramble the message. The message that travels across the network is something like ^y7. On the receiving side, the computer knows how to reverse the encryption using the private key, showing us the message. We don't mind everyone knowing the public key, because without the private key, it won't reveal the message to prying eyes. We can also be assured that the message was only meant for us because it was encrypted with our public key.
Keep in mind that using PKI, the public and private keys are sufficiently long enough to frustrate even complex computer systems.
Even so, the encryption method often goes a step further. Because asymmetric keys are a bit less efficient for large messages, a symmetric hash is used to encrypt the content, and the asymmetric keys are used to hash the symmetric key. To read the message, the receiver decrypts the symmetric key with the asymmetric keys, then uses the symmetric key to decrypt the rest of the message.
The other use for PKI is to "sign" a message. When you write a letter, you put your signature at the bottom so that the reader can verify the author. They are presumably aware of your signature, or at least can find another letter for comparison.
When you send a digitally signed message, PKI creates a short hash transformation of the message. Using the private key, the source system encrypts the hash, and includes the public key. The message, along with the hash value and the public key, is sent to the intended user. That user can use the public key to decrypt the hash, showing the signature message. It's a simple matter to compare the decrypted string with the original string to prove you sent the message. This is how secure e-mail works. You'll often see both encrypted and signed messages in really sensitive transaction.
How is PKI Used?
So how is PKI used in the real world? We've seen that PKI is used to sign or encrypt messages, and those two methods are used in several areas.
One of the places you'll see PKI encryption is in secure Web communications. If you've ever used the https:// lead-in on a URL, then the site is probably using PKI for the communications security. It's actually the Secure Sockets Layer where the PKI is used, but https:// is normally how that's implemented. The Web traffic on these sites is encrypted, and data such as e-commerce and other sensitive data can be sent with reasonable safety.
Yet another application for PKI encryption is the Encrypting File System, or EFS. The public and private key pair is used to encrypt files or even directories, and those files can't be opened by anyone else. Windows 2000 and later operating systems, as well as Linux and other UNIX-based systems, all have EFS capabilities. In the Windows environment, PKI is used in the encryption.
PKI signing can be used for login authentication. Smart cards, key tokens, and security dongles are all examples of a "signed" login. In this application, PKI sits in front of the security subsystem of the operating system. The security subsystem waits for the proper response from the PKI mechanism, and passes the login through as a "trusted" source.
Another application of PKI signing involves digital signatures in e-mail. The process works the same as other types of signing, but it's important to keep in mind that simply signing an e-mail doesn't make it secure. To properly secure the mail it needs to be encrypted as well.
Certificates
Now that we know what PKI is and what it's used for, how is it implemented? A PKI is set up in the Windows operating system using Certificate Services. Certificate Services are a series of programs, files, Application Programming Interfaces, and Microsoft Management snap-ins. They are used to obtain, create, manage, and distribute certificates.
You can think of a certificate as a passport. The passport isn't me, but it contains pictures, numbers, and other information that prove to various authorities that the person handing it to them is me.
The information contained in the document isn't what makes a passport valuable. After all, I could gather all the same pictures and other information into a folder and hand that to the authorities in France, but that doesn't mean they'll let me come to Paris. What really sets the passport apart is who issues it. The reason the French authorities allow me to visit Paris is that the passport I hold was issued by the United States government. The combination of the information in the passport and the format it's offered in gives the French authorities enough confidence to allow me to visit.
Certificates are a lot like that. They are a system of files and messages that contain the public key and other data that implement the PKI architecture. Just like a passport, certificates are only good for a limited time, and you'll have to renew them when they expire.
With certificates, hierarchies are used to identify who trusts whom. In commercial uses, agencies such as VeriSign will create a certificate for you. Anyone who trusts VeriSign will also trust your certificate. It's sort of like introducing yourself at a meeting by referencing a trusted name—"Tish told me to bring this message to you."
You can also set up your own server to create certificates. This is normally the most "trusted" device in the network, and is set up to be highly secure. That server creates and manages certificates for the rest of the network in a process called self-certification.
However you obtain the certificate, there are several places that you install these certificates so that they can be used by the applications we saw earlier.
The certificate holds a few items, the most important of which is your public key. People request your certificate, and that's how they encrypt a message for you, prove your identity, and verify your signature.
Just like a passport, the certificate is only as good as the authority that issues it. In the case of a passport, the document is backed by a governmental agency. In the case of the certificate, an agency such as VeriSign might mean more to an external client than a server you set up in your company. On the other hand, a server you set up in your firm might be all you need within your firm.
Setting up Certificate Services
To implement PKI and certificates, you'll need to do a bit of planning. The first decision involves how you'll use certificates in your environment.
If you're providing certificates for external clients on a Web server for secure traffic, then a firm such as VeriSign might be your best choice to create a certificate for you and provide help with its installation. There's a fee for creating the original certificate and you'll need to purchase a renewal certificate when the old one expires.
If you want to create your own certificates for secure mail or high encryption, you can use your own Certificate Authority (CA) by installing Certificate Services. Before the installation, there are a few more decisions you'll need to make.
One decision involves how many CA servers you wish to install. Each CA can create a certificate for a different purpose if desired. One server might create a certificate for e-mail, another might be used to secure Web traffic, and yet another might secure logins. All these certificates might have separate properties including expiration and cipher strength.
In the Microsoft environment, there are two types of Certificate Authorities: enterprise and stand-alone.
Normally, you employ the enterprise CA when you issue certificates to users or computers inside an organization that is a native Windows 2000 domain. It doesn't require a native domain, but it does require Active Directory to work. You'll also need Microsoft Windows DNS server to be installed, which might be a limitation if you're in a mixed network environment with BIND DNS servers. The CA can be installed on a domain controller or a member server.
Use a stand-alone CA when you will issue certificates outside of Active Directory domains. You won't need Active Directory for this type of CA. The server can be a stand-alone-server (SAS) or a member server of an NT or Active Directory domain.
This type of server is also called a "locked-closet" server because it can be disconnected from the network. Some firms place these servers in a secure environment and make Certificate Services its only job.
Even within the choices of enterprise or stand-alone, there are two types of Certificate Authorities: root or subordinate.
A root CA is used as the "master" server for a particular certificate. While the root CA creates the certificate, the subordinate distributes and manages those certificates.
Step-By-Step Installation
Let's install Certificate Services on a test system. My server will be a root, stand-alone CA used to issue certificates in a mixed network.
My server runs Windows 2000 in a SAS configuration. The service packs are up to date, and the server lives behind a firewall.
- Log on to the server with an administrative account. Note that if this was an enterprise CA, I'd need to have Enterprise Administration rights in Active Directory.
- Open the Control Panel applet and then select "Add/Remove Programs."
- Select "Add/Remove Windows Components."
- Check the box marked "Certificate Services." You'll get a pop-up warning about joining a domain. Click "Yes" to continue.
- Click the "Details" button to select the capabilities of your server. The system in this test is set up to serve as a CA (it can create certificates), and it is also set to use certificates in its Web services. Click "OK" when you've made your choices.
- Clicking the "Next" button brought up a choice regarding Terminal Services on this system, which isn't related to Certificate Services. Click "Next" if that choice pops up on your system as well. The next screen prompts the selection of a stand-alone root CA or a stand-alone subordinate CA. The Enterprise options are grayed out because this system isn't participating in Active Directory. The "Advanced options" checkbox will prompt you for things like hash strength, but you don't normally need to change them. Click "Next" to continue.
- Next, you're asked to fill out information about your organization. The most important item is the CA name because this will identify your certificate and public key to the world. You also set the duration here. It's important to keep the duration short so that the public can trust that the certificate is reviewed for accuracy often. I left the default value for this system. Click "Next" to continue (see Figure 1).
- The next panel sets the location for the database files, and it sets whether the location is shared. If Active Directory isn't involved, it's automatically set to a shared location. The reason for this is that other CAs need to access the same location.
- After pressing "Next" to continue, this test system popped up a warning that IIS would be stopped so that the changes could be applied. After answering "OK" to this warning, the progress of the process is displayed. You might also be asked for the source CD for Windows 2000.
Once the files are copied, the installation is complete. Anytime I copy files from the Windows 2000 CD, I reapply service packs and hot fixes.
PKI Management
Now that you have a CA, your users can request certificates for use with e-mail signatures and encryption. Let's install a browser certificate as a test of the CA installation.
- To request a certificate for your browser, simply open a Web browser and enter http://NameOfYourCA/CertSrv.
- Selecting "Next" allows you to select a Web certificate or an e-mail certificate.
- Once that choice is made, selecting "Next" requests information to be included in the certificate. After you fill in the information, click "Submit" to send the certificate request to the CA server.
- Now that the request has been made, you're informed that the server has received the request, and that the administrator has to approve it. You're told to come back later to retrieve your certificate.
- Back on the administrative side of things, open the "Programs/Administrative Tools/Certification Authority" MMC.
- Once you're inside, drill down to the "Pending Requests" object.
- Right-click on the certificate that has been requested and then select "All Tasks" and then "Issue" from the menu that appears (see Figure 2).
- Notice that the certificate disappears from the "Pending" object and moves to the "Issued" object. Once there, you can right-click on the certificate to read it.
- Over on the user's side, open the server location again (http://NameOfYourCA/CertSrv). This time, select "Retrieve the Certificate or certificate revocation list," and then "Next."
- In this screen you're asked to install the certificate. Click "Install this CA certification path" to link the certificate to your browser.
- When the installation is complete, you'll see a message telling you that the server is trying to add a certificate to your system. Because you initiated the process, it's OK. Select "Yes" to continue.
- A Web page opens that gives you the status of the installation.
- If you'd like to see that the certificate is installed, you can open the properties of Internet Explorer (assuming that's the browser you're using) and access the "Content" tab, and click "Certificates."
- Following this process will install a certificate on your Web browser. If you had selected the radio button for a mail certificate, the process is similar, but is instigated in Outlook on the client's side.
As mentioned earlier, certificates must be managed. The Certification Authority MMC is the primary tool for starting and stopping the CA service, issuing and revoking certificates, displaying the log, and more. If you've set up a test server using this article, make sure to navigate through the various panels and right-click on the objects to experiment. Once you've deployed a few certificates, you can do a little more research using the references accompanying this article.