Protect your CAs from being lost or destroyed
With the growing emphasis on information security, many companies turn to digital certificates to help increase the level of security on their networks. If your network relies on digital certificates, however, you need to implement some disaster-prevention and recovery techniques to protect your digital certificates and the Certificate Authorities (CAs) that issue them. A brief review of public key infrastructure (PKI) and an introduction to digital certificates and their CAs will get you started. Then, let's examine some methods designed to help you better guard your certificates, your CAs, and the certificate databases that contain your CAs.
A Brief Anatomy of Public Key Encryption
You use digital certificates in conjunction with a public key infrastructure (PKI). The idea behind a PKI is that you use two keys—a public key and a private key—to protect data. The public key, which encrypts data and verifies a digital signature, you make widely available. After the public key has encrypted data, only the corresponding private key can decrypt that data. Therefore, you must closely guard private keys, usually storing them either on the computer of the user who owns them or within the user’s roaming profile.
To illustrate how a PKI works, suppose that user A must send an encrypted message to user B. User A downloads user B’s public key—either directly from user B or from a public-key database. User A then uses user B’s public key to encrypt the message. After user B’s public key has encrypted the data, only user B’s private key (which, under most circumstances, no one except user B should have) can decrypt the message. (For information about configuring a PKI in Windows 2000, see Shawn Porter, "Security Considerations for Migrating from NT to Win2K, Part 3," July 2001, InstantDoc ID 21300.)
PKI encryption works well but has a significant drawback. When user A must send an encrypted message to user B, another user—C—can pretend to be user B and send his or her public key to user A. After user C sends his or her public key, only user C can decrypt the message. Therefore, secure PKI use requires strong positive public-key identification, which digital certificates can provide.
Understanding Digital Certificates and CAs
A digital certificate is basically an electronic signature. A certificate’s primary purposes are to bind a public key to an identity and prove that the binding is authentic.
Digital certificates are small binary files that a CA usually issues to users. (Certificates on a root CA are an exception. They’re self-signed because in Win2K—which takes a hierarchical approach to CAs—no higher CA exists to issue them.) The binary files contain information such as the certificate’s issuer, the certificate’s holder, and the certificate’s public key. The information in the file is formatted to conform to the X.509v3 standard.
Administrators can configure the network to use the built-in Win2K CA or any of several third-party CAs, such as VeriSign and Baltimore Technologies’ CyberTrust, formerly GTE CyberTrust. (To find a list of CAs you can trust, go to the Microsoft Internet Explorer—IE—Tools menu, select Internet Options, select the Content tab, click Certificates, and select the Trusted Root Certification Authorities.) Regardless of certificates’ origins, all machines involved must trust the CA. (Trust in the issuing CA creates trust in a certificate’s identity.)
In certain ways, a digital certificate resembles a driver’s license. If a police officer pulls you over, unless the same officer has pulled you over before, he or she probably has no idea who you are. The officer first asks you for your driver’s license, which acts as evidence that you are who you say you are and that your state has granted you the right to drive.
Why does the officer basically trust your driver’s license? First, in most states, driver’s licenses tend to be difficult to reproduce. (An experienced police officer can usually spot a fake license.) Second, the officer knows that he or she can generally trust the issuing agency, the Department of Motor Vehicles (DMV). Before the DMV issues a license to someone, the department must exert due diligence to verify the applicant’s credentials, thereby confirming an applicant’s identity. Because the officer trusts the DMV, he or she trusts the license.
Suppose that user A needs to prove his or her identity to user B. To do so, user A attaches a digital signature to an email message and sends the message to user B. Because user B knows that the digital signature is difficult to tamper with and is based on a certificate that a trusted CA issued, user B can be relatively certain that user A is who he or she claims to be.
Protecting Your CAs
As you’ve seen, the CA plays an important role in your network’s overall security. Therefore, you must protect the CA from tampering and physical damage. Before I explain various protection methods, however, keep in mind that if you issue your own digital certificates through Win2K Certificate Services, you might have more than one CA to protect. Remember that although an Enterprise root CA is the most critical CA in Win2K's hierarchy, you should also give Enterprise subordinate CAs, Standalone root CAs, and Standalone subordinate CAs adequate attention. Because all these CAs can issue certificates, they must also be guarded. (For detailed information about Win2K Certificate Services, see John Howie, "Securing Win2K with Certificate Services," September 2001, InstantDoc ID 22113.)
Protection for root-level CAs. Root-level CAs offer a unique security challenge. Two main concerns make tampering with root-level CAs a significant threat to security. First, root-level CAs don’t obtain their certificates from a higher authority; their certificates are self-signed. Second, all lower-level CAs trust the root-level CA. Therefore, if someone were to exploit a root CA, the security breach would compromise lower-level CAs as well.
To guard your network against a root-level CA security breach, I recommend that you use your root-level CA to assign certificates only to subordinate CAs, never to users. If you reserve the root-level CA for this purpose, you’ll use this CA infrequently and can safely take it offline until you need to add a subordinate CA. Note that no one can bring a subordinate CA online unless he or she has access to the root CA. Therefore, using the root CA only to assign subordinate CAs and otherwise keeping it offline greatly reduces your risk of a security breach.
Protection for all CAs. Let’s consider some general techniques that you should apply to all CAs on your network. First, you need to protect your CAs from tampering. You might think that guarding against tampering is superfluous, given that digital certificates are based on public-key information, which anyone can access. However, although a user’s private keys typically reside elsewhere, the CA contains its own private key. You must protect the CA’s private key against theft to prevent anyone from impersonating the CA.
The best way to guard your CAs from tampering and other damage is to implement strong physical security. If intruders or malicious users gain physical access to a server, they can easily use a utility such as Winternals Software’s ERD Commander 2002, intended for repairs in a console-mode Win2K or Windows NT environment, to completely bypass any security that you might have assigned to the server. Therefore, you need to implement physical security for your CAs. Take advantage of measures such as door locks, case locks, and fire-suppression systems.