the encryption process is based on keys. Therefore, the question that you’ll have to ask yourself before you begin the decryption process is “do the keys still exist”? For example, suppose that a key employee encrypted all of their data and then walked off of the job. In such a situation, there’s a good chance that the user’s keys still exist on the hard disk of their PC. If that’s the case, you can simply reset the user’s password, log on as the user from the user’s PC and then decrypt the files.
However, this technique won’t work if the keys are missing. For example, if the user knew the location of the keys and erased them, then logging on as that user wouldn’t do any good. Likewise, suppose that a legitimate user’s hard disk went bad. If this hard disk contained the user’s keys then there’s no easy way of decrypting the users files, even if the files were stored on a different hard disk or on a network partition.
The key to recovering from such a situation is to understand how the encryption process works. Remember that the encryption process is key based. When a user encrypts a file, the file itself is encrypted by using symmetric encryption. As you may know, symmetric key encryption works by using an algorithm to encrypt a file and then providing the user with a separate key that can be used to decrypt the file. However, since anyone who has the key would be able to decrypt the file, the key is also encrypted. Because symmetric encryption requires a key for decryption, Windows 2000 can’t use symmetric key encryption to encrypt the key. Instead, Windows encrypts the key by using the user’s public key, which is derived from the user’s certificate. Since the user’s machine already contains a copy of the public key, the user has no trouble decrypting the symmetric key and then using the symmetric key to decrypt the file.
Although this process makes for good security, the drawback is that unless an administrator is able to decrypt the symmetric key, they won’t be able to decrypt the user’s files. Fortunately, Windows actually makes two different copies of the symmetric key. The first copy, as you know, is encrypted with the user’s public key information. The second copy though is encrypted into a separate file, using the public key of something known as the Recovery Agent.
The Recovery Agent is a mechanism that allows the administrator to recover encrypted files when the user’s keys are lost. If files are encrypted on a stand alone machine, then by default the local Administrator account becomes the designated recovery agent by default. If the machine containing the encrypted files is a part of a domain, then the domain Administrator account becomes the designated recovery agent. You can designate a different user as the recovery agent. There are at least two situations when you might consider making another user the recovery agent. First, if you’re working in an extremely high security environment, then rotating who the recovery agent is will keep hack attempts at bay, since the hacker will have no way of knowing who today’s recovery agent is (unless you follow a pattern).
Another situation in which you’d want to switch recovery agents is if you wanted to encrypt a file while logged in as the Administrator. Remember that if you don’t switch recovery agents and you encrypt a file as the Administrator, then the user keys and the recovery keys can be identical and could seriously compromise your ability to recover the files in a disaster.
So how does the recovery process work? Remember that the recovery process uses the recovery agent’s public key to decrypt the symmetric key, which is in turn used to decrypt the file. Therefore, the trick is to bring the recovery agent’s key and the symmetric key together. Windows 2000 stores each user’s public keys in the user’s personal certificate store. This store is located in the Documents and Settings\<username>\ApplicationData\Microsoft\SystemCertificates\My\Certificates. As you can see by the location within the directory structure, this storage point is a part of each user’s profile. Any time that a user logs on, the certificates that are contained in this location are read into memory and are then copied into the registry for use. If your network uses roaming profiles, then the certificates will follow the user where ever they login.
As you can see, if your network uses a roaming profile, then getting the recovery certificates to the encrypted file is no big trick. To get the ball rolling, the recovery agent can simply log into the machine containing the encrypted files. From that point, they can begin the rest of the recovery process. However, if your network doesn’t use roaming profiles, you’ll have to figure out a way to bring the recovery certificates together with the encrypted files before you can begin the recovery process. There are two ways that you can do this.
The best way to bring the encrypted files together with the recovery certificates is to begin by backing up the encrypted files. Remember that the backup process preserves the files because it doesn’t attempt to decrypt or re-encrypt the file as a part of the process. Once you’ve made a backup of the secure files, send the backup file to the recovery agent via secure E-mail. When the recovery agent receives the E-mail, they can restore the backup file and begin the recovery process. Remember that the designated recovery agent must restore the backup onto an NTFS version 5 partition or the operation won’t work.
Another way to bring the recovery certificates and the encrypted files together is for the recovery agent to physically travel to the computer that contains the encrypted files and then import his or her recovery certificates. However, while this method does work, I don’t recommend using it because of the sensitivity of the recovery keys. You don’t want copies of the recovery keys to exist on end user’s PCs.
Which ever technique you use, the idea is to recover the data, without compromising your recovery keys. Even though the preferred method is to restore the backup of the encrypted files onto your own PC, there will sometimes be situations in which this proves to be impossible because of hardware limitations. If your PC’s hard drive is almost full, or your system simply isn’t up to par, then I recommend buying a PC that you can use solely for the task of recovering encrypted files. You should keep this PC in a secure location such as the server room, so that certificates that it contains won’t be compromised. When files need to be decrypted, you can send the backup of the files to this PC. You may then import your recovery keys to the PC and decrypt the files without fear of compromising your keys.
If you do decide to export the encryption keys to transport them to a different PC, the process for doing so is fairly easy. You can import and export certificates through the Certificates snap in for Microsoft Management Console. This snap in also provides you with a way to see which certificates are installed on the machine. Once you’ve loaded the snap in, you must locate the certificate that you want to export. Since a machine can potentially contain hundreds of certificates, the easiest way to locate a specific certificate is to right click on Certificates – Current User within the console and select the Find Certificates command from the resulting context menu. This will allow you to search through the certificates while looking for specific criteria such as a certificate number, or hash number.
When you’ve located the certificate that you need to export, right click on the certificate and select the All Tasks | Export commands from the resulting context menu. Doing so launches a wizard that will help you to export the certificate. The import process is just as easy. Simply select the container within the Certificates snap in that you want to import the certificate into. Right click on the certificate and select the All Tasks | Import command from the resulting context menu. Doing so will launch the certificate import wizard, through which you’ll be able to import the certificate.
Earlier, I discussed the possibility of you needing to change recovery agents. If you need to change the recovery agent before you begin the decryption process, or just want to verify who the recovery agent is, you can do so by opening the Domain Security Policy tool found on the Administrative Tools menu. When you do, you can locate the recovery agent by navigating to Windows Settings | Security Settings | Public Key Policies | Encrypted Data Recovery Agent, as shown in Figure A. |
