Are you a technology junky is who is searching for a pdf converter for your business? For information about how to convert pdf to doc, PDF to HTML conversion and a pdf to word converter, the web is a good place to begin.

Recovering Encrypted Data

By: Brien M. Posey, MCSE

Last week, I explained how you can encrypt files and folders on an NTFS version 5 partition. In that article, I also explained some of the rules that apply to encrypted files. However, any time that you encrypt files, you need to think about data recovery. For example, what would happen if a key employee encrypted all of their files and then quit their job? Likewise, what would happen if a hard drive that contained the encryption keys were to fail? As you can see, there are lots of situations in which you may find yourself having to decrypt files that don’t belong to you. In this article, I’ll discuss the issues involved in decrypting otherwise unusable files.

As I mentioned last week, 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.

Figure A

You can find the recovery agent through the Domain Security Policy console.

 If you need to add another user as the recovery agent, you can do so by selecting the Add command from the Action menu. Doing so will launch the Add Recovery Agent Wizard. Simply follow the wizard’s prompts to designate a new recovery agent. Remember that for this procedure to work, you must have administrative privileges, and the user that you designate must have an EFS Recovery Agent certificate. Published in the Active Directory (assuming that you’re working in a domain environment).

 Once you’ve got all of the pieces to the puzzle in place, you can decrypt the encrypted files. There are two ways of doing so. You can use the usual method through Windows Explorer, or you can use the Cipher command. The Cipher command allows you to use a few simple command line switches to verify or change a file or folder’s encryption status.

 As you can see, the process of decrypting a file who’s keys have been lost can be a bit complicated, but isn’t impossible. Next week, I’ll discuss some techniques that you can use to help you to keep encryption keys safe so that you’ll hopefully never have to use the techniques that I’ve discussed in this article.

If you've found this article helpful then please consider making a donation to help with the cost of keeping this site going. To make a donation, please click on the PayPal link below.