Security WatchDeploying EFS: Part 1

John Morello

By now, everyone has heard reports about personal or sensitive data being lost because of laptop theft or misplacement. Laptops go missing on a regular basis. With identity theft on the rise and regulatory compliance more critical than ever, the thorough protection of data on mobile computing systems is essential.

One answer is to use Encrypting File System (EFS), included in Windows® since Windows 2000, which provides built-in, high-performance, disk-based encryption. EFS integrates seamlessly with Windows Explorer so end users often won't even know when a file they're using is encrypted. Additionally, EFS works equally well with native Windows authentication and access-control technologies so that users don't need to remember separate passwords to access their data. Finally, EFS provides manageable options for recovering data in cases where a user may lose access to his encryption keys (such as if his user profile is deleted or damaged or his smart card is lost.)

EFS uses the built-in cryptography technology in Windows to generate, store, and deploy strong encryption keys to protect data. In Windows XP Service Pack 1 (SP1) and later versions, EFS utilizes the Advanced Encryption Standard (AES) algorithm with a 256-bit key to encrypt data on disk. These symmetric keys are then protected with an asymmetric (RSA) key pair. EFS encrypts each file with its AES key, then encrypts this key with the user's RSA key and stores the result in the file. For more information on EFS cryptography, see the "EFS Resources" sidebar. For now, I'll focus not on the technical underpinnings of EFS but rather on how to deploy it and make it viable in your environment. For this reason, the article assumes a prior knowledge of EFS cryptography concepts.

A Note on EFS Security

There are some applications that claim to be able to crack or break EFS encryption. None of these applications actually decrypt the AES (or Data Encryption Standard, DES, or Expanded Data Encryption Standard, DESX) encrypted ciphertext, but rather gain access to the user's EFS private key by brute-forcing the user's password. The important thing to keep in mind about EFS encryption is that the private keys used to generate and protect the encrypted data utilize the Data Protection API (DPAPI). DPAPI uses derivatives of a user's logon credentials to protect data so the end result is that data protection with EFS is only as good as the user's password. With Windows Vista™, you can now store EFS encryption certificates on smart cards, which changes this paradigm and greatly increases the relative security of EFS protected data.

How long does a password need to be to be resistant to these attacks? Given today's hardware capabilities and modern password attack algorithms, an 11-character or greater password (or, more correctly, passphrase) is recommended. An 11-character or longer passphrase is highly resistant to today's most advanced methods, including precomputed hash attacks (such as Rainbow Table; see the blog posting "Why you shouldn't be using passwords of any kind on your Windows networks" listed in the "Resources" sidebar for more information).

To PKI or Not to PKI?

One of the most common misconceptions about EFS is that it requires a public key infrastructure (PKI) to work. While EFS can easily integrate with and take advantage of a PKI should your organization already have one, it is by no means a requirement. That said, the decision regarding whether or not to use a PKI in your EFS deployment will impact many future deployment decisions, so it should be examined first.

The primary advantage of using a PKI with EFS is the ability to perform key archival and recovery. Whereas EFS alone will allow administrators to perform data recovery, automatic key recovery is only available with a PKI, and even then, only when running Windows Server® 2003 Enterprise Edition as your Certificate Authority (CA). Data recovery is the process in which a user who loses access to his encryption key can provide his encrypted data to a designated administrator known as a Data Recovery Agent (DRA), who can then either decrypt that data and return it to the user or re-encrypt it for use with a new private key. The DRA works as a shadow to the user's encryption process whereby everything that the user encrypts with his key is also encrypted with a copy of the DRA key. Thus, when the user's key is lost, the DRA can step in, get the ciphertext data, apply the DRA key to it for decryption (or re-encryption), and then return the data to the user. The DRA approach works well, but can be difficult to manage if the user has encrypted large amounts of data or does not have local IT staff to act as DRAs.

Key recovery, on the other hand, requires that the CA make a copy of the user's encryption key during the key creation process and securely store the copy of that key in the CA's database. Then, when a user loses access to encrypted files, the CA administrator only needs to go into this database and retrieve the user's key. At that point, the user will immediately have access to his data again without having to have a DRA recover it for him. When done this way, key recovery can be faster and more efficient. Note, however, that a best practice is to always have DRAs in place, even when using key recovery, to provide a backup mechanism for key loss events. This also allows large organizations to have a distributed recovery system where local IT administrators can recover users' data without having to ever involve the PKI administrators group.

Another potential benefit of using a PKI with EFS is to facilitate easier sharing of encrypted files. Recall that EFS is not limited solely to laptop systems; it can be equally valuable in any situation where the physical security of a computer cannot be guaranteed. In these situations, there may be a need for multiple users to access the same encrypted data. While Windows support for sharing encrypted files is somewhat limited because it only allows for sharing individual files, not directories, it can be a useful tool. To facilitate sharing of EFS files, the user who is sharing the file must have access to the public keys of the users he is sharing with (which is easiest if those users have a valid EFS certificate published to their account in Active Directory®). While it is possible to perform this publishing manually, using a Windows CA installed in Enterprise (Active Directory-integrated) mode makes the process fully automated.

EFS Key Management

If you have a Windows Server 2003-based PKI available to use, generating users' EFS certificates is a simple process. A Windows Server 2003 CA comes with a default set of certificate templates, including one called Basic EFS. However, this template is a version 1 template and does not support key archiving. So, before making it available on your CA, you will want to duplicate the template to create a new version 2 template (for example, you could call it EFS with Key Archive, as shown in Figure 1). On this new template, go to the Request Handling tab and select the option to archive the user's encryption key. Note that you'll need to have key archiving properly configured on the CA before enabling this option. The resources section includes an excellent walkthrough of the process. You should also set this template to supersede the Basic EFS template to ensure that clients will use this new version (see Figure 2).

Figure 1** EFS with Key Archive **(Click the image for a larger view)

Figure 2** Supersede the Basic EFS Template **(Click the image for a larger view)

Next, you'll need to set the proper permissions on the template to allow the right set of users to have enroll access to it. Because the EFS component in Windows will automatically request a certificate the first time EFS is used, you do not typically need to allow users to autoenroll against the EFS template. In fact, I'd recommend against enabling autoenrollment for EFS certificates unless you're sure that all autoenrolled users will be using EFS. Figure 3 shows the EFS enrollment settings. By issuing certificates to users who may never use EFS, you're increasing the size of your CA database for no benefit. Though the CA database itself isn't limited in size, it can become more difficult to manage (particularly through the Microsoft Management Console, or MMC) as you increase the number of certificates issued.

Figure 3** Setting EFS User Permissions **(Click the image for a larger view)

Finally, if you need to support the sharing of encrypted files, you may want to have the CA automatically publish the user's certificate to Active Directory.

Once you have configured the template properly on your CA, the first time a user goes to encrypt a file with EFS, he will get his certificate from your CA and your CA will automatically archive his private key.

DRA Key Management

The next question to consider if you have a PKI in place is whether or not to utilize CA-generated DRA certificates. Why would you not want to use DRA certificates from your PKI? Consider a scenario where you have an issuing CA with a fairly short certificate validity period (two years or less). That CA will not be able to issue any certificates with validity lifetimes longer than its own, which would mean that your DRA certificates would have (at most) a two-year lifespan. This can result in a significantly more complex data recovery scenario. This hypothetical example is illustrated in the following scenario.

1. A user encrypts a file in January 2006; the DRA certificates that are pushed down to her machine via Group Policy have a two-year span (they expire in January 2008).
2. The user continues working with EFS, encrypting new files.
3. In January 2008, the DRA certificates expire and the administrator then pushes down new certificates via Group Policy.
4. Any encryption operations from here on utilize the new DRA certificates (including any files she opens that were encrypted with the old DRAs; when they're saved, they'll utilize the new DRAs) but any files she does not touch going forward will still be protected only with the old DRAs.
5. The user accidentally damages her profile and requires data recovery.
6. The IT administrator must now have two sets of DRA certificates: the new ones for any files touched since Step 3 and the old one for any files not touched since then.

While it is possible for the IT administrator to run a script after Step 3 to update all files with the new DRA (using cipher.exe /u), this can be a time-consuming process. Also, to be clear, the DRA keypairs aren't useless after they've reached their expiration date, although the EFS component will not allow any new encryption operations if an expired DRA certificate is included in its recovery policy. Old files encrypted with expired DRA keypairs can, of course, still be recovered by them. Thus, DRA keypairs should never be discarded, even after their validity lifetime has expired; you simply don't know when you'll need to use them.

For these reasons, I recommend that environments that have CAs with short certificate lifespans employ self-signed DRA certificates with longer lifespans. The cipher utility includes a switch (cipher.exe /r) that automatically creates EFS recovery agent keypairs with a lifetime of 100 years (see Figure 4). The certificate from this keypair can then be attached to Group Policy Objects (GPOs) and used as a DRA throughout your organization. Because the EFS component does not check the trust chain of DRA certificates, these self-signed certificates will work without having to make any changes to the list of Trusted Root Certificate Authorities on your systems. Regardless of the lifespan of an organization's CA, I always recommend creating at least one long-lived DRA certificate and attaching it to a domain-wide GPO. This is the fallback data recovery option to use in case all other options fail. This is particularly vital if you're using CA-generated DRA keys in the absence of a CA key archive. Should a DRA certificate ever be compromised you can update the GPO with a new certificate and use cipher.exe /u as discussed earlier to update your files.

Figure 4** Running Ciquer /R **(Click the image for a larger view)

EFS Resource

You can get lots more information on EFS particulars and best practices by visiting the following sites.

• Why you shouldn’t be using passwords of any kind on your Windows networks
• Implementing Key Archival Walkthrough
• Encrypting File System in Windows XP and Windows Server 2003

KRA and DRA Deployment

Key archiving provides the ability for CA administrators to recover escrowed encryption keys on the user's behalf. Obviously, this is a very sensitive and powerful capability because it can allow a CA administrator to decrypt any data in the organization that utilizes a key signed by the CA. Thus, key archiving and recovery should be treated carefully and only a small number of trusted security personnel should be given this permission. Because of the sensitive nature of key recovery, if you'd like to rely on it as your primary mechanism for regaining access to EFS-encrypted data, it's important to have a clearly defined escalation process for recovery requests to be sent to your CA administration team. Only after the request has been carefully vetted should the recovery process be initiated. Then, once the key is actually recovered, it should be provided to the user via a secure method (in other words, not through e-mail) since the recovered key provides access to all the user's EFS-protected data.

Key Recovery Agent or KRA keys are generated and held by CA administrators and are not advertised via Group Policy. In fact, EFS itself can't determine whether or not a key it utilizes has been archived; it simply performs its encryption operations as it normally would. Additionally, the KRA keys created on the CA are not specific to EFS in any way. A CA using key archiving will have n number of KRA keys attached to it at the CA level that will be used to protect any key archived by the CA. These keys can include those used with EFS, secure e-mail, or any other certificate purpose that includes encryption. KRA keys should be securely stored by the individual key recovery agents and there should be at least two KRAs used to provide a fallback in case one of the keys is lost.

The first time an administrator logs on to the domain controller in a newly created domain, a default recovery policy will be created at the domain level using a self-signed certificate and keypair stored in the administrator's profile on the DC. This DRA certificate will have a validity lifetime of three years. The recommended approach is to remove this default certificate and replace it with longer-lived self-signed certificates or certificates issued from your PKI. If you do not remove this default self-signed certificate, three years after its creation EFS will stop encrypting new files throughout your domain. This is because the certificate will have expired and EFS will prevent the encryption of any further data when an expired DRA certificate is included in its recovery policy. While it is possible to operate Windows XP and later systems with no recovery agent policy in place, this is strongly discouraged. Doing so means that if a user loses access to his encryption key for any reason and key recovery isn't possible, all his data will be irrevocably lost.

As I've said, DRA keys can be either self-signed or issued from a CA. In most cases, a hybrid approach is best, with at least two long-lived, self-signed DRAs used enterprise-wide as a recovery agent of last resort. Because DRA certificates are deployed via Group Policy Objects, they possess the same inheritance capabilities as other GPOs. In other words, the standard Local, Site, Domain, organizational unit (OU) GPO accumulation and application algorithm that controls the application of other GPO settings also applies to DRAs. Thus, an organization can easily implement a tiered approach to DRAs, where the central IT group has DRA access to every part of the enterprise, but where local IT groups also maintain the ability for their specific areas of responsibility. This is a particularly valuable asset in large, geographically dispersed organizations since it alleviates the need to transfer large amounts of encrypted data over WAN links to facilitate data recovery. Figure 5 illustrates a typical DRA deployment with multiple tiers.

Figure 5** Multitier DRA Deployment **

In this case, a user in the Baton Rouge OU would end up with six DRAs for each encrypted file: two from his local administrators, two from the North America IT group, and two from the domain level. Thus, if the user was to lose access to his encrypted data, he could have it recovered by a local DRA in Baton Rouge or by the North America IT group. As a final fallback, if these four DRAs were unavailable or lost, the domain-level DRAs could take over and recover the data as well. Regardless of which DRA performed the recovery, the process would be essentially the same. The user would first make the data available to the DRA. It's important that the DRA take the necessary steps to ensure that the request is legitimate and coming from the true owner of the data. Once that is done, the DRA would load the DRA certificate, decrypt (and preferably re-encrypt) the data, and then send the data back to the end user. Some organizations also choose to perform local recovery, where the DRA would physically visit the problem user, load his DRA keypair into the profile, then decrypt the data and remove the keypair. The user would then have access to the data in plaintext form and could re-encrypt it with a new key. It should be noted that this approach is far less secure because the DRA keypair is copied (though temporarily) to the local machine, but it can save some time, particularly if a great deal of data must be recovered.

Note that if recovery were to be provided to the user through key archiving and recovery, the recovery request would be handled entirely separately from this process. Instead of utilizing a DRA at all, the user's key recovery request would go to the CA administrators, who must vet the request, then go into the archive and retrieve the user's private key. They would then make this private key available to the user securely, such as by placing it on a secure Web site for download. (If the user was taking advantage of a smart card to store his EFS key, available with Windows Vista, then that key should also be reissued.) The user would load this key into his profile and would then have immediate access to all his encrypted data.

Because the DRA and KRA keypairs can be used to decrypt sensitive data, it's important that they be properly protected. DRA and KRA keypairs should not be stored in the normal desktop profiles of administrators (the profiles in which they do their normal daily tasks). Rather, these keypairs should be safely stored offline on floppy, optical, or flash media kept in a physically secure location. Then, when recovery is needed, the recovery agent can load the keypair onto a recovery workstation from this media, perform the recovery operation, then remove the keypair. In some particularly security-sensitive organizations, dedicated workstations are designated for recovery to further increase the security of these keypairs, but this is not a requirement for all organizations.

Next Time

Now that I've examined the key management, data recovery, and Active Directory sides of EFS planning, I'll focus on client-side deployment questions in Part 2 of this topic, coming next month. There I will cover topics such as controlling EFS usage through Group Policy, choosing what to encrypt, automatically encrypting data through logon scripts, and client-side enhancements for Windows Explorer to make working with EFS-protected data even easier.

John Morello graduated summa cum laude from LSU and has been with Microsoft for six years in a variety of roles. As a Senior Consultant, he has designed security solutions for Fortune 100 enterprises and Federal civilian and defense clients. He’s currently a Program Manager in the Windows Server group working on security and remote access technologies.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.