But before I start talking about backup and recovery for encrypted files, I need to give you a quick crash course in how the Windows Encrypting File System (EFS) works. EFS has been around since Windows 2000, and can be applied to files and folders stored on an NTFS file system, as long as those files and folders are not compressed.
The reason why EFS encryption requires the use of the NTFS file system is because encryption is actually an advanced file system attribute. Since other file systems do not support this attribute, moving or copying a file to a volume that is formatted as FAT, or to removable media, strips the encryption attribute from the file. Encrypted files are decrypted on the fly each time that they are accessed, so copying an encrypted file to non-NTFS media causes the file to be stored in a non-encrypted format.
So does this mean that encryption isn't a consideration for files and folders that you back up? Not exactly. The NTFS file system has existed in one form or another for well over a decade. As such, nearly every backup application in existence is capable of backing up NTFS volumes, and the extended file attributes that are used on these volumes.
The considerations for backing up encrypted files vary depending on the version of Windows that is being used, and on the backup software that you are using. For example, prior to the release of Service Pack 1, the Windows backup application that came with Vista was not able to back up encrypted files. In contrast, Windows Server Backup application -- which is included with Windows Server 2008 -- fully supports backing up encrypted files.
Since nearly every modern backup application supports NTFS backups, you might be wondering why not every backup application supports backing up encrypted files. Well, setting the encryption attribute on an encrypted file is only part of the encryption process.
When you tell Windows to encrypt a file or folder, EFS generates a File Encryption Key (FEK). Windows uses this key in conjunction with a mathematical algorithm based on Data Extended Standard X (DESX) to perform the actual encryption process. As such, the file cannot be decrypted without the FEK. Windows then uses your public key that comes from a certificate authority to encrypt the FEK, and then stores the encrypted version of the FEK with the corresponding file in special NFTS attributes knows as Data Decryption Fields and Data Recovery Fields. When you access an encrypted file, the system uses your private key to decrypt the FEK, and then uses the FEK to decrypt the file.
Back up your encryption keys
As you can see, the entire encryption process is based on the File Encryption Key and on a user's public/private key pair. If these keys are lost or damaged, then the files will remain permanently encrypted. Therefore, backing up the encryption keys is as important as backing up the encrypted files themselves. Windows designates the built-in Administrator account as a recovery agent (capable of decrypting files), but even the recovery agent is key-based, which underscores the importance of protecting the keys.
What all of this boils down to is that if the keys are not backed up, then they cannot be replaced should the system experience a hard disk crash, and this renders any encrypted files as permanently inaccessible. Therefore, backing up your keys is of vital importance.
The exact method of backing up the keys varies depending on your backup application. For many backup applications, the process is seamless, but you should test your backups to make sure that you are able to recover encrypted files.
As an added precaution, I recommend exporting the domain EFS recovery agent's private key, and storing it in a safe place. Again, the exact method for doing so varies depending on the version of Windows that you are using.
In Windows Server 2008, the EFS recovery keys reside on the first domain controller that was made a part of the domain. You should log into this domain controller using the built-in Administrator account (not another account with administrative permissions). Next, enter the MMC command at the Run prompt to launch an empty Microsoft Management Console.
When the console opens, choose the Add/Remove Snap-in command from the File menu, and click OK. When Windows displays a list of the available snap-ins, choose the Certificates snap-in and then click the Add button, followed by OK. When prompted, choose the My User Account option and click Finish, followed by OK.
Now, look through the list of certificates and find the certificate that lists File Recovery as its intended purpose. Right click on the certificate, and choose the All Tasks | Export command from the shortcut menus. When the Certificate Export Wizard starts, click Next to bypass the Welcome screen. Now, choose the Yes, Export the Private Key option, and click Next. On the following screen, choose the Personal Information Exchange -- PKCS #12 (.PFX) option.
This screen also contains an option that you can use to delete the private key from the domain controller if the export process is successful. Microsoft recommends removing the private key from the domain controller as a way of enhancing security, but if recoverability is of greater concern to you than security, then you should leave the key in place. To complete the process, click Next three more times, followed by Finish.
A backup of an encrypted file server is useless unless the encryption keys are also backed up. I therefore recommend exporting the private key for your built-in Administrator account, and regularly making a full system backup of the first domain controller that was brought online in your domain.
About the author: Brien M. Posey, MCSE, has previously received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.
This was first published in January 2010