Recently, a couple of security experts claimed that Windows NT 4.0 lacks secure private-key storage. They had developed a simple program that could grab a user's private keys and store them wherever the experts told it to. Anyone who knows this trick can embed code in a Web page and grab the private keys of the people connecting to the page. Is getting a user's private keys really that simple? If so, what can I do to block these malicious programs?
By default in Windows OSs, private keys reside in an OS-level-protected part of the system registry. A special service called the Protected Storage service protects this registry portion. To answer your question fully, I need to first discuss two private-key-protection options: marking the private key as exportable and adding an extra level of password-based software protection.
At key-generation time, Microsoft lets the certificate requester set a special flag that marks the private key as exportable from the protected storage area. The requester can set this flag either programmatically or from the UI. Figure 2 shows the Microsoft Certificate Server enrollment page on which you can set this flag. (To access this page, you click Advanced on the certificate enrollment form.) You can set the same flag when you use the Certificate Import Wizard to import a certificate and private key from a Personal Information Exchange (PKCS #12) file.
You can export private keys marked as exportable through the CryptExportKey CryptoAPI function. You can call the CryptExportKey function from any piece of mobile code that you execute from your browser. In other words, if your keys are marked as exportable, you risk your private keys being exported without your consent and sent out to an intruder machine somewhere on the Internet. In NT 4.0, this flag is disabled by default, which means that by default, your private keys aren't exportable. When you set this option, be aware that you're seriously compromising the protection of your private keys.
Many administrators are confused about this flag because in Windows 2000, Microsoft enables it by default for some automatically generated keys. An example is the Encrypting File System (EFS) private key. Microsoft enabled exportation to enable key roaming between different machines and to provide a way to back up the EFS private key to another medium.
Microsoft also has an option to provide additional password protection when a process tries to access your private keys. As Figure 3 shows, the Private Key Container Wizard lets you set three security levels:
- High—When you select the High option, the system prompts you to grant or deny access and enter a password each time a process wants to access your private key.
- Medium—When you select the Medium option, the system warns you when a particular process accesses your private key. Medium is the default setting. You then can grant or deny access to your private key for that process.
- Low—When you select the Low option, your keys can be exported without your consent.
You can set this software-protection option programmatically or from the UI. On an NT Service Pack 4 (SP4) system running Microsoft Internet Explorer (IE) 4.0, you can set the option from the UI only by using certmgr.exe command. From certmgr.exe, you can set this option only on keys that you've marked as exportable. The command
first lists all the certificates in your personal certificate store. Then, the utility prompts you to select a particular certificate whose private key you want to secure, as Figure 4, page 14, shows. If you've marked the key as exportable, certmgr.exe starts the Private Key Container Wizard. Click Set Security Level in the first wizard dialog box; the wizard then prompts you to select one of the three security options.
Be aware that selecting the Enable strong private key protection check box in the Certificate Import Wizard on an SP4 IE 4.0 machine won't bring you additional private-key protection. To enable the Private Key Container Wizard, you must first run certmgr.exe on the MY certificate container. Fortunately, upgrading to IE 5.x resolves this problem. When you've installed IE 5.x, selecting Enable strong private key protection automatically brings up the Private Key Container Wizard (i.e., you don't need to run certmgr.exe beforehand). Because IE 5.x fixes this problem, Microsoft no longer distributes the Certmgr tool. (You can download a copy of the tool from the Code Library on the Security Administrator Web site at http://www.secadministrator.com.)