14.8 Encrypting File System Changes

Windows XP and Windows 2003 Server sport an updated version of the Encrypting File System (EFS) that was introduced in Windows Server. In this section, we include changes in the final release versions, as well as new vulnerabilities in the EFS ( courtesy of Steve Light).

Windows 2003 Server has enhanced its EFS since Windows Server. For example, Windows 2003 Server now has enhanced encryption of the Offline Files database. This is an improvement over Windows Server because cached files can now be encrypted. In addition, Windows XP no longer creates a default recovery agent. Lastly, XP/Server EFS now supports multiple users encrypting a single file.

This section describes the Windows XP/Server EFS and shows you how to manage this powerful security feature.

14.8.1 Background

Microsoft's EFS is based on public key encryption and utilizes the operating system's CryptoAPI architecture. The EFS encrypts each file with a randomly generated key that is independent of a user's public/private key pair. The EFS automatically generates an encryption key pair and a certificate for a user if they do not exist. Temporary files are encrypted if the original file is on an NTFS volume. The EFS is built in to the operating system kernel and uses non-paged memory to store file encryption keys so that they are never in the paging file.

In Windows XP/Server, encryption is performed using either the expanded Data Encryption Standard (DESX) or Triple-DES (3DES) algorithm. Both the RSA Base and RSA Enhanced software included by cryptographic service providers (CSPs) may be used for EFS certificates and for encryption of the symmetric encryption keys.

14.8.2 User Interaction

The EFS supports file encryption on a per-file or per-folder basis. All child files and folders in an encrypted parent folder are encrypted by default. For simplicity, users should be encouraged to set one folder as encrypted and store all encrypted data in subfolders of the encrypted parent folder. However, each file has a unique encryption key, which ensures that the file remains encrypted even if it moves to an unencrypted folder on the same volume.

14.8.3 Data Recovery on Standalone Machines

The EFS originally had a special account known as the Data Recovery Agent, or DRA, that allowed administrators to recover keys. However, this account is no longer included by default. Newer versions of Windows XP do not create a DRA on newly installed machines in a workgroup or in a domain. This effectively prevents offline attacks against the administrator account. If a machine is joined to a domain, all users ”including local users ”inherit the recovery policy from the domain. For workgroup machines, a DRA must be created manually by a user and installed. To manually create a DRA, the cipher.exe utility must be used as follows :

 CIPHER /R:filename /R  Generates a PFX and a CER file with a self-signed EFS recovery certificate in them. filename A filename without extensions 

This command generates filename.PFX (for data recovery) and filename.CER (for use in the policy). The certificate is generated in memory and deleted when the files are generated. Once you have generated the keys, import the certificate into the local policy and store the private key in a secure location.

Steve Light discovered a weakness in which XP clients may lose access to EFS files after a password reset. Users on an XP workstation that is in a standalone (workgroup) or Windows NT 4 domain environment may lose access to EFS-encrypted files after a password reset. The default behavior of XP's Data Protection API (DPAPI) is more restrictive when granting access to private keys. XP does not allow a user with a reset password access to that user's private keys.

There are several workarounds available. These include:

• Change the user's password to the value from which it was reset.

• Use a Password Recovery Disk.

• For XP Service Pack 1, enable DPAPI behavior similar to that of Windows Server by adding the following registry entry.

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0- 1501-11d1-8c7a-00c04fc297eb Name: MasterKeyLegacyCompliance Type: REG_DWORD Value: 00000001 

This behavior applies to non-Active Directory domain user accounts that have their passwords reset. All users changing their own passwords while on the client machine do not encounter any of the mentioned effects.

There are two kinds of Recovery Agents (RAs): an EFS RA and, in Windows 2000 (and XP), a DPAPI RA. The EFS RA is the one with which users are familiar; it is visible and configurable. The DPAPI RA offers the ability to recover from a password change.

The DPAPI RA is invisible; it is not really any user account. Imagine that every private key is encrypted with the owner's password and the DPAPI RA's key. When the password changes, the user cannot open the private keys. The DPAPI RA decrypts its copy of the private key and re-encrypts it with the current (new) password. Thus, a user with a reset password gains access to the EFS-encrypted files.

In XP, the local DPAPI RA is turned off. Instead, there is a "password recovery" disk. If a user forgets a password and there is no password recovery disk, the EFS data is inaccessible. In a standalone or NT4 domain environment, local or domain password resets prevent access to EFS-encrypted files. In a Microsoft AD domain, any password reset to a domain account will not prevent access to EFS-encrypted files.