Leveraging EFS with Your PKI

Recover encrypted data from your systems

In "Securing Win2K with Certificate Services," September 2001, InstantDoc ID 22113, I described how Microsoft's public key infrastructure (PKI) product, Certificate Services, worked and showed you how you can improve your network's security by leveraging the service as an Enterprise Certification Authority (CA). Now, I show you how to leverage the features that Encrypting File System (EFS) offers by tying it into your PKI.

The Security of EFS
EFS, which Microsoft introduced in Windows 2000, is a surprisingly powerful and robust technology that lets users protect their sensitive data from unauthorized eyes by encrypting it. Although EFS doesn't replace the safety you get through physical security and file and folder permissions, it does offer an additional safeguard in the event that an intruder defeats these mechanisms. For example, I use EFS to protect sensitive documents on my laptop when I travel on business. If someone steals my laptop and uses a tool such as Winternals Software's NTFSDOS Professional or a disk-sector editor to analyze the hard disk, the data in my files is encrypted and therefore unusable to the thief. You can also use EFS in your office network to further protect sensitive documents from prying eyes.

How EFS Works
Before I show you how to improve on the default EFS configuration, you need to understand how EFS works. (For EFS resources, see the Web-exclusive box "For More Information," which you can access at http://www.secadministrator.com, InstantDoc ID 23946.) When a user requests that a file be encrypted, EFS generates a symmetric key, called a file encryption key (FEK), which it uses to perform that encryption. To protect the FEK, EFS encrypts it with the public key from a certificate that supports EFS issued to the user. EFS stores the encrypted FEK and identifying information about the user with the now-encrypted file. When the user opens the encrypted file, EFS uses the private key associated with the user's certificate to decrypt the encrypted FEK. EFS then uses the decrypted FEK to decrypt the file. EFS performs data encryption and decryption on a user's behalf whenever he or she opens or saves a file.

To encrypt a file or folder, right-click the file or folder in Windows Explorer, select Properties, then click Advanced on the General tab. In the Advanced Attributes dialog box, which Figure 1 shows, select the Encrypt contents to secure data check box, then click OK. After you've marked a folder for encryption, EFS will encrypt any file written to that folder.

Like most CryptoAPI-generated certificates and keys, EFS certificates and their associated private keys are stored securely in your user profile, which has some important implications. For example, users with mandatory profiles can't take advantage of EFS because they can't save changes—including EFS certificates issued to them—to their profile. If you use Win2K in a workgroup environment or use local system accounts to log on, your profile is local to each system, and you'll have an EFS certificate on each machine. Thus, if you back up an encrypted file on one system and restore it to another, you won't be able to open the file because the EFS certificates are different.

You face a similar problem when you use domain accounts in Win2K domain environments without using roaming profiles. Each time you encrypt a file on a system for the first time, an EFS certificate with a public key and associated private key is issued to you. If you don't have a PKI in place, EFS issues a self-signed certificate (i.e., a certificate that has context only on the system that issued it). If you back up encrypted files on one system and restore them to another system, you won't be able to open the files. Similarly, if you've backed up encrypted files to a file server that subsequently fails, you won't be able to open the files restored to that server because your EFS certificates will have been lost (unless you backed up and restored your user profiles, too).

If you use roaming profiles, only one EFS certificate is issued to you, and each system trusted for Kerberos delegation can impersonate you and open your roaming profile to obtain both the EFS certificate required to encrypt an FEK and the private key required to decrypt it. (For the security implications of maintaining a copy of a user's certificate and private key on a central file server, see the Web-exclusive sidebar "What's the Downside to EFS?" which you can access at http://www.secadministrator.com, InstantDoc ID 23927.)

EFS encrypts files on the file system only. Also, EFS works only with NTFS 5.0 (NTFS5), so if you've upgraded your systems from Windows NT 4.0 or use a file system other than NTFS (e.g., FAT, FAT32), you can't take advantage of EFS. Data from encrypted files held in memory that applications have allocated isn't encrypted. Furthermore, if you access an encrypted file over a network, the encryption and decryption processes take place on the file server and all data is sent across the network in plaintext. If you need to secure the network to protect data in transit, consider using IP Security (IPSec) instead of EFS.

Using EFS with a PKI
Many organizations can realize significant benefits by using roaming user profiles and a PKI. For example, if you delete a roaming user profile or it becomes corrupt, you can recover that profile, complete with EFS certificate and associated private key, from another system that the user has logged on to either locally or over the network.

If you use a PKI that integrates with EFS, EFS automatically obtains certificates from the PKI instead of issuing self-signed certificates. Certificate Services has three types of certificate templates that support EFS: Basic EFS, User, and Administrator. However, EFS requests only a Basic EFS certificate for users. The advantages of using a PKI to issue EFS certificates include the ability to control the validity period of the issued certificates and the ability to revoke certificates if they become lost or compromised.

The default lifespan for a self-signed EFS certificate is 100 years from the date you installed the OS. Given the growth trend in computing power, in just a few years, intruders will likely be able to crack the keys used to protect encrypting keys. (Although you can't control the lifespan of an EFS certificate that a PKI issues directly, a CA can't issue a certificate with an expiration date after its own. Also, you can use other, non-Microsoft PKIs, such as Baltimore Technologies' Baltimore UniCERT, that can integrate with the EFS and let you set the expiration date.) When a certificate expires, you can still decrypt a file. However, when you save that decrypted file, EFS will automatically request a new EFS certificate and private key. You can delete expired EFS certificates and private keys, but you should first archive those certificates and keys in case you need to decrypt an old file secured with an expired EFS certificate. Also, you should consider exporting valid certificates in case the corresponding user profiles become corrupt.

You can export certificates and private keys by using command-line tools (e.g., certmgr.exe) or, more easily, by starting Microsoft Internet Explorer (IE) 5.0 or later, selecting Tools, Internet Options, clicking the Content tab, then clicking Certificates. Select the certificate you want to export, then click Export to start the Certificate Export Wizard. Because an EFS certificate has a private key associated with it, the wizard gives you the option of exporting the private key, too. If you choose to export the private key with the EFS certificate, the only supported file format is Personal Information Exchange ­ PKCS #12 (.PFX), as Figure 2 shows. Select the Delete the private key if the export is successful check box. (This option is useful for recovery agent certificates, which I discuss in the next section.) The wizard prompts you for both a filename and a password to protect the exported certificate and private key. Click Finish.

EFS and Recovery Agents
One useful EFS feature is recovery agents. Recovery agents are users whose user accounts are authorized to decrypt a file when the user who encrypted that file can't (e.g., when the user has lost his or her private key). This feature is especially useful when you find an encrypted file belonging to a former employee whose account is no longer available or when a user's profile has been deleted or hopelessly corrupted and you can't restore it. When EFS encrypts a file, it encrypts the FEK used with the public key from a special recovery agent certificate; with the file EFS stores the symmetric key and recovery agent certificate alongside the FEK encrypted with the user's certificate in the EFS metadata. By default, in workgroup environments, the recovery agent account is the local Administrators account. In a domain environment, the default recovery agent account is the Domain Admins account.

Recovery agents can decrypt a file in three ways. They can

(When you copy or save a file to a new location, the new file inherits the compression and encryption attributes of the folder to which it's written.) For instructions about how to create a recovery agent, see the Web exclusive sidebar "Creating a Recovery Agent," which you can access at http://www.secadministrator.com, InstantDoc ID 24103.

EFS Recovery Agent Certificates
After you've created a recovery agent user account, you need to deploy the EFS Recovery Agent certificate to your systems. To do so, you use a Group Policy. For import into a Group Policy, you need to export the EFS Recovery Agent certificate to a file without its associated private key. Follow the export procedure I provided earlier, but this time, select the No, do not export the private key option in the Export Private Key dialog box and the DER encoded binary X.509 (.CER) option in the Certificate Export Wizard Export File Format dialog box.

The Group Policy setting for EFS recovery agent accounts can be domainwide or restricted to an organizational unit (OU). You can even have separate recovery agent accounts for each OU, which is useful if you group systems by the sensitivity of data stored on them and you need different recovery agents for each system. To specify recovery agents, follow these steps:

Now, every time a user accesses an encrypted file, EFS will update the list of recovery agent accounts that can decrypt the file. This failsafe lets you change recovery agents and their certificates on an as-needed basis. Be sure to keep the EFS Recovery Agent certificates and private keys for old recovery agents in case an infrequently accessed file has old recovery agent information associated with it and a recovery agent is required to decrypt it.

Securing Recovery Agents
EFS security depends on the security of the EFS Recovery Agent certificates and their associated private keys. You should never use recovery agent accounts for anything other than recovering files. Because EFS Recovery Agent certificates and private keys are stored in user profiles, consider using local rather than roaming profiles for recovery agent accounts. Using local profiles means recovery agents can decrypt files only on the computer from which the EFS Recovery Agent certificate and private key were requested or on a computer to which an exported certificate and key were imported. You should dedicate systems for recovery agent use and physically secure them. When you need to open an encrypted file, move it to a recovery agent system. I recommend using the NT Backup utility, which can read an encrypted file as raw data and store it to tape or another file for transport.

In environments with a strict need for security, export EFS Recovery Agent certificates and private keys to a floppy disk or smart card, then delete them from the computer on which they were requested. Keep the medium onto which you exported the certificates and private keys secure until you need to restore them to decrypt files. When you no longer need the certificates and private keys, delete them again.

Leveraging EFS with your PKI provides many administrative benefits. By using roaming profiles and assigning recovery agents, you can ensure that you'll always be able to access and recover encrypted files on your systems.