Windows Vista : Using the Encrypting File System (part 1) - Understanding EFS, Interacting with EFS and PKI

Protecting user data while it is within the internal network is mostly a matter of providing proper protected storage for user data, but when the information leaves the office, then protecting it requires a bit more than central storage. Fortunately, Windows Vista offers several features in relation to data protection while in transit on portable computers. One of these, the Encrypting File System (EFS), will protect all user data, even temporary files, by encrypting them. To view the data, users must have the decryption key. No decryption key, no data. It's as simple as that.

EFS is an extension of the NTFS file system build into Windows. NTFS is in fact a database system that adds and controls extended attributes to file objects. These attributes include security elements as well as the ability to either compress or encrypt data. Both compression and encryption are transparent attributes that are tied to the file object, but that are self-eliminating; a file object can either be compressed or encrypted, but not both at the same time.

1. Understanding EFS

The encrypting file system uses public key infrastructure (PKI) encryption to provide access control protection to files and folders stored on either NTFS or Web-based Distributed Authoring and Versioning (WebDAV). EFS operates on most newer versions of Windows including Windows 2000, Windows XP Professional, Windows Server 2003 and, of course, Windows Vista. EFS is not supported on Basic or Home Editions or any other older version of Windows.

EFS requires the use of both symmetric and asymmetric keys to encrypt data. The symmetric key or file encryption key (FEK) is randomly generated by EFS and is used to encrypt the file. Then, the user's public or asymmetric key is used to encrypt the symmetric key. Because it includes the capability to add more than one public key to the encrypted symmetric key, EFS can support the sharing of encrypted files between multiple users. This also provides a path for data recovery in the event of a mishap. If EFS was based on symmetric key pairs alone, it would not provide a very efficient protection mechanism because anyone with the decryption key could open the file. By relying on a public key infrastructure, EFS provides a very strong level of protection to encrypted data. EFS uses standard X.509 certificates for encryption.

EFS uses a standard process to encrypt files (see Figure 1). But before it encrypts a file, EFS begins with a number of verification checks — making sure that the file isn't already encrypted, identifying if there is enough disk space to encrypt the file, identifying whether the file is a system file or not, and so on. By default, system files cannot be encrypted. Next, it generates the FEK and protects it with the user's public key and any other public key that is designated as authorized.

After the FEK is protected, EFS generates the required metadata. This includes the data decryption field (DDF) that will contain the FEK and any public key used to protect it. A second key field that is stored within the metadata is the data recovery field (DRF). If one or several recovery agents have been assigned, then the DRF will contain their public keys. Other information stored in the metadata includes the version of EFS used and the encryption algorithm used to encrypt the data.

At this stage, EFS is now ready to encrypt the data. To do so, it begins by creating a temporary file in the same directory as the encrypted file. This temporary file serves as a backup of the original in case the encryption process goes awry. Next, it takes the original file and basically empties it of content and writes the metadata to it. It then proceeds to read data from the temporary file, encrypt it, and store it back into the original file. After the writing is complete, the temporary file is deleted. The original file is now considered encrypted because it contains both its original data and the EFS metadata.

If at any time during the process something goes awry, EFS uses the temporary file to restore the file to its original state. This is one reason why EFS and compression are self-eliminating — both need to have access to temporary space during the process of writing the file. When decrypting a file, EFS uses the same process in reverse.

2. Interacting with EFS and PKI

EFS requires an asymmetric key pair to operate. If a proper PKI is already implemented and the user has a key pair, EFS will use the user's public key to encrypt the FEK. But, if no PKI exists, Windows will automatically generate a key pair and assign it to the user. This key pair can be assigned as valid at the workstation or workgroup level and within an Active Directory (AD), at the site, domain, or organizational unit level. Within AD, it is best to keep PKI scopes at the domain level. This reduces the number of policies to maintain.

When key pair scopes are managed at the workstation or workgroup level, each and every machine involved must be addressed manually. This is because a core portion of any EFS strategy must involve a recovery policy — a special PKI policy that provides support for the designation of recovery agents in the event of the loss or damage of the encrypting user's private key. When working with individual workstations or small workgroups, this policy must be duplicated on every machine. Active Directory eliminates this by providing support for a corporate infrastructure for public key management. This is one reason why it is best to use the features integrated with Windows Server 2003 or 2008 and Active Directory to implement and manage a Windows-based public key infrastructure.

In addition, using a proper PKI will allow you to perform automatic key recovery. If you do not use a PKI, then you will be able to recover data from encrypted files, but you will never be able to recover lost keys. In short, if a user has a lot of encrypted data and you do not use a PKI in support of EFS, you, as the Data Recovery Agent (DRA) will have to either decrypt each of these files manually or re-encrypt them with a new EFS key. Although it is more work to implement a PKI at first, using a PKI will save you lots of administrative overhead in the end.

Figure 1. The EFS encryption process

When you do use a PKI in support of EFS, the Certificate Authority in Windows Server will automatically create a backup copy of the encryption keys it assigns users. If a user loses this key, all you need to do — that is, you or the Certificate Authority administrator — is access the secure CA database to retrieve the user's lost key. After the user has access to the lost key again, they have access to all of their encrypted files, a much simpler process than relying on DRAs though you should have DRAs anyway. Finally, using PKI with EFS will make it easier for users to share encrypted files.

EFS can be applied to either folders or individual files. Because folder inheritance is an intrinsic part of both NTFS and WebDAV, it is a good idea to focus on the encryption of entire folders rather than on individual objects. In fact, encrypting the folder is the default behavior of Windows (see Figure 2). This way, documents are automatically encrypted when placed into special folders. If this strategy is used, it is important to back it up with a strong training policy because of the potential for inadvertent decryption of files as they are removed from an encrypted folder and placed into folders that do not automatically encrypt data. By default, Windows displays encrypted data in green in the file system so that it is easier for users to identify.

Figure 2. By default, Windows wants to encrypt entire folders

In addition, Windows offers support for the encryption of offline files and folders. This lets you combine your data management strategy with a data protection policy by encrypting all files that can be at risk.