How Private Keys Are Stored

Private keys for the Microsoft RSAbased CSPs, including the Base CSP and the Enhanced CSP, reside in the user profile under RootDirectory \Documents and Settings\< username >\Application Data\Microsoft\Crypto\RSA. In the case of a roaming user profile, the private key resides in the RSA folder on the domain controller and is downloaded to the user's computer until the user logs off or the computer is restarted.

Unlike their corresponding public keys, private keys must be protected. Therefore, all files in the RSA folder are automatically encrypted with a random, symmetric key called the user's master key. The user's master key is generated by the RC4 algorithm in the Base or Enhanced CSP. RC4 generates a 128-bit key for computers with the Enhanced CSP (subject to cryptography export restrictions) and a 56-bit key for computers with only the Base CSP (available for all Windows 2000 computers). The master key is generated automatically and is renewed periodically. It encrypts each file in the RSA folder automatically as the file is created.

The RSA folder must never be renamed or moved because this is the only place the CSPs look for private keys. Therefore, it is advisable to provide additional security. The administrator can provide additional file system security for users' computers or use roaming profiles.

You should protect private keys for recovery, which is critical for backup, by exporting the certificate and private key to a floppy disk or other medium, storing the floppy disk or other medium securely, and then deleting the private key from the computer. This preserves the file from a system crash and makes it unavailable for cracking. To decrypt a data file, the recovery agent administrator inserts the floppy disk or other medium and imports the certificate and private key to the recovery agent account. For more information about how to secure recovery keys, see Windows 2000 Server Help.

Protect Folder

The user's master key is itself encrypted automatically by the Protected Storage service and stored in the user profile under RootDirectory \Documents and Settings\< username >\Application Data\Microsoft\Protect. For a domain user who has a roaming profile, the master key resides on the domain controller and is downloaded to the user's profile on the local computer until the computer is restarted.

The user's master key is encrypted twice, and each instance of encryption is stored in one of two parts of the Protect file. The first part, the password encryption key, is produced by the Hash-Based Message Authentication Code (HMAC) and SHA1 message digest function and is a hash of:

• A symmetric encryption of the user's master key produced by 160-bit RC4.

• The user's security identifier (SID).

• The user's logon password.

The second part is the backup/restore form of the master key. This is needed if the user's password is changed on one computer but the keys are in the user profile on another computer, or if the administrator resets the user's password. In either case, the Protected Storage service, which cannot detect password changes to update Part 1, uses Part 2 to recover the master key and regenerate Part 1.

To create the backup part of the file, the encrypted user's master key is sent on to the Protected Storage service on the domain controller. That service uses HMAC and SHA1 again to make a hash of the data it has received along with the domain controller's own backup/restore master key, and sends that back to the user's computer to store in the Protect file. These transmissions are authenticated (signed and encrypted) by way of remote procedure calls so that the user's master key never goes over the wire in plaintext.

The domain controllers backup/restore master key is stored on the system as a global local security authority (LSA) secret in the HKEY_LOCAL_MACHINE/SAM key in the registry and is replicated over the network by means of Active Directory. (Global LSA secrets are objects provided by the LSA to enable system services to store private data securely.)

Caution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

The System Certificates, RSA, and Protect folders have their system attributes set. This prevents the files in them from being encrypted by EFS, which would make them inaccessible.