Chapter 20: Encrypting File System 511 Figure 20-1 The EFS encryption process 1. A user must choose to encrypt a file. This can be done by enabling an individual file for EFS encryption or by creating a file in a folder that is enabled for EFS encryption. 2. The local security authority (LSA) on the computer generates a random encryption key, called a File Encryption Key (FEK), to encrypt the file. The symmetric encryption algorithm used by the FEK depends on the version of the computer’s operating system: ❑ For Windows 2000, the Data Encryption Standard XORed (DESX) algorithm is used to encrypt the file. ❑ For Windows XP with no services packs, the Triple DES (3DES) algorithm can be used to encrypt the file, instead of DESX. ❑ For Windows XP Service pack 1 and Windows Vista, the Advanced Encryption Standard (AES) algorithm with a 256-bit key is used to encrypt the file. Note For more information on how these encryption algorithms work, review Chapter 1: “Cryptography Basics.” 3. The LSA retrieves the user’s designated EFS certificate and obtains the user’s public key from the certificate. 4. The LSA encrypts the FEK by using the Rivest Shamir Adleman (RSA) asymmetric encryption algorithm with the user’s public key and places the encrypted FEK in the Data Decryption Field (DDF) in the file’s metadata. Note In Windows XP or Windows Vista, the DDF can contain multiple entries, allowing multiple users to share an encrypted file. In Windows 2000, it is possible to create only a single DDF through the user interface. 5 3 2 EFS FEK EFS Public Key DRA Public Key DRA 6 4 DRF DDF Encrypted Contents 1 Encrypted 512 Part III: Deploying Application-Specific Solutions 5. The LSA retrieves the certificate for each EFS recovery agent, also known as the data recovery agent (DRA), from the local computer configuration for workgroup members, or by determining the resultant set of policy for Active Directory Domain Services (AD DS) or domain members, and extracts each EFS recovery agent’s public key. 6. The LSA encrypts the FEK by using the RSA encryption algorithm with the retrieved EFS recovery agent’s public key and places the encrypted FEK in the Data Recovery Field (DRF) in the file’s metadata. Note If multiple EFS recovery agents are designated, multiple entries will be stored in the DRF, one for each defined EFS recovery agent. Remote Encryption The EFS encryption process changes when you attempt to encrypt a file on a remote server. The process used by Windows 2000 and Windows XP clients is different from the new process implemented for Windows Vista clients. Remote EFS Encryption for Windows 2000 and Windows XP Clients When you perform remote file encryption from a Windows 2000 or Windows XP client using Server Message Block (SMB) or Common Internet File System (CIFS), the file is encrypted at a remote file server in a share created on the file server. Encryption is performed by allowing the remote file server to impersonate the user. Important The computer account of the remote file server must have the Trusted For Delegation option enabled for its computer object in AD DS. This allows the computer to impersonate any user through Kerberos delegation. For this reason, many organizations consider enabling the Trusted for Delegation option a huge security risk. When the computer account impersonates a user, it loads a user profile for the user account on the local file system and follows the same process to determine whether an EFS certificate exists for the user account. A different EFS encryption certificate is implemented at each file server where EFS encryption is enabled. In fact, the remote EFS encryption certificates are different that the EFS certificate used for local EFS encryption. Important The same process is used by a Windows Vista client when it connects to a share hosted on a server computer running Windows 2000 Server or Windows Server 2003. An alternative to allowing EFS encryption on file servers is to implement Web-based Distributed Authoring and Versioning (WebDAV), or Web folders, at the remote file server. Chapter 20: Encrypting File System 513 Rather than connecting to the file server on TCP port 445 (or TCP port 139 for the older SMB protocol), the server allows connections through the Hypertext Transfer Protocol (HTTP) port, TCP port 80 (or TCP port 443 if Secure Sockets Layer [SSL] is implemented). The benefit of using WebDAV is that a Windows XP client performs file encryption on the local computer rather than the remote file server. This provides better data protection as the file is transmitted from the client’s computer to the remote file server. When a Windows XP client connects to a WebDAV access point on a remote server, files are encrypted locally on the client and then sent to the WebDAV server as an encrypted file using an HTTP PUT command. Likewise, when a Windows XP client connects to the WebDAV access point to open a previously encrypted file, the encrypted file is transmitted to the Windows XP client via an HTTP GET command and then decrypted locally on the client. Remote Encryption Changes for Windows Vista Windows Server 2008 changes the behavior for remote EFS encryption. The encryption process was modified to work the same way as remote WebDAV encryption in Windows Server 2003. ■ Certificates and keys are stored on the client rather than generating profiles on the server. ■ The file server no longer needs to be trusted for delegation. This setting is no longer required because the server no longer impersonates the user. ■ The files are now transmitted as encrypted data to the remote file server. ■ Users can share files between workstations if Credential Roaming Service is implemented Note Credential Roaming Service is discussed in Chapter 15, “Issuing Certificates.” If a client is running Windows 2000 or Windows XP, it can perform remote encryption on a file server computer running Windows Server 2008, as long as the server is trusted for delega- tion. The Windows 2000 and Windows XP clients will continue to perform remote encryp- tion as described earlier in this chapter. EFS Decryption When an EFS-encrypted file is opened by a user with access to the FEK in the DDF information, EFS decryption process takes place, as shown in Figure 20-2. 514 Part III: Deploying Application-Specific Solutions Figure 20-2 The EFS decryption process 1. When the user attempts to open the encrypted file, the LSA retrieves the private key of the certificate used to encrypt the FEK in the DDF. The private key is retrieved from the current user’s personal store. Note As long a user has access to a private key associated with the public key used to encrypt the FEK in a DDF, that user can open an EFS-encrypted file. The user’s name does not have to match the user name stored in the subject of the certificate. Note The user attempting to open the EFS encrypted file must be assigned the Read & Execute and Read NTFS permissions to open the file. 2. The LSA uses the private key from the user’s store to decrypt the FEK from the DDF. 3. The LSA uses the FEK to decrypt the file. The file is decrypted in memory so that the application accessing the file can read the unencrypted file. The version of the file stored on the hard drive remains encrypted. EFS Data Recovery When a designated EFS recovery agent attempts to access an EFS-encrypted file, a process similar to the EFS decryption process takes place. (See Figure 20-3.) The only difference is that the FEK is retrieved from the DRF rather than the DDF. 1 2 EFS Private Key FEK FEK User Profile DRF DDF Encrypted Contents 3 Chapter 20: Encrypting File System 515 Figure 20-3 The EFS recovery process When the recovery agent attempts to open the file: 1. The LSA retrieves the private key of the certificate used to encrypt the FEK in the DRF. Note It does not matter if the name of the user does not match the subject name in the EFS certificate. As long as the user has access to a private key associated with the public key used to encrypt the FEK in a DDF, he or she can open the EFS-encrypted file. Note The recovery agent’s user name does not have to match the user name in the EFS Recovery Agent certificate’s subject. The recovery agent only requires access to the Public Key Cryptography Standards (PKCS) #12 file containing the Recovery Agent’s certificate and private key and import the certificate and private key into his or her user profile. 2. The LSA uses the private key from the EFS recovery agent’s user store to decrypt the FEK from the DRF. 3. The LSA uses the FEK to decrypt the file. One Application, Two Recovery Methods In Windows Server 2003 PKI and Windows Server 2008 PKI deployments, EFS allows two methods to recover an EFS-encrypted file when a user no longer has access to his or her EFS-encryption private key: 1 2 DRA Private Key FEK FEK DRA’s Profile DRF DDF Encrypted Contents 3 516 Part III: Deploying Application-Specific Solutions ■ Data recovery An EFS recovery agent decrypts the file. Once the file is decrypted, the user can open the plaintext file and then reencrypt the file using a newly issued certifi- cate with the Encrypting File System OID. ■ Key recovery The user’s original certificate and private key are recovered from the CA database and restored to the user’s profile. Recovery of the user’s certificate and private key allows the user to access the FEK stored in the DDF of the EFS-encrypted file, returning access to the file to the user. The following sections discuss some of the design decisions an organization faces when choosing between data recovery and key recovery, or a mix of both. Data Recovery Data recovery allows a designated EFS recovery agent to decrypt all EFS-encrypted files on a computer. By default, the location of the default EFS recovery agent’s certificate and private key is dependent on the domain membership of a computer. If the computer: ■ Is a member of a domain The EFS recovery agent’s certificate and private key are stored in the Administrator’s profile of the first domain controller in a domain. When the first domain controller is promoted as a domain controller for the newly created domain, the local administrator’s EFS Recovery Agent certificate is designated as the domain’s EFS recovery agent. ■ Is a member of a workgroup The EFS recovery agent’s certificate and private key are stored in the user profile of the first member of the local Administrators group who logs on at the computer running Windows 2000. Typically, this is the local Administrator account, but it can be another account. Caution Deploying EFS in a workgroup environment is risky. The storage of the EFS recovery agent’s key pair on the local file system makes the computer subject to alternate operating system attacks, such as the Nordahl attack, that attempt to gain access to the key pair through other operating systems. It is recommended to deploy Syskey.exe with the system set to require either a password or a disk with the system key password at startup before allowing access to the local hard disk. For more information on the system key, see Chapter 13, “Securing Mobile Computers,” and Chapter 14, “Implementing Security for Domain Controllers,” in 2nd Edition Microsoft Windows Security Resource Kit, by Ben Smith and Brian Komar (Microsoft Press, 2003). A common misconception is that the Administrator account is the EFS recovery agent. Remember that EFS is a PKI-enabled application and has nothing to do with the user account. It depends only on who has the EFS Recovery Agent certificate’s associated private key. You can lose access to the EFS recovery agent’s private key in the following circumstances: ■ If you remove, rebuild, or retire the first domain controller in a domain environment Chapter 20: Encrypting File System 517 ■ If you overwrite the Administrator’s profile with a roaming profile created at another computer ■ If you delete the Administrator’s profile on the first domain controller in the domain or on the local computer in a workgroup Important If you have overwritten or lost the EFS recovery agent’s private key, you must designate a different EFS recovery agent to allow data recovery and update the EFS recovery agent information for each encrypted file. In Windows Vista, you can use the EFS Re-Key Wizard to update the EFS recovery agent information Defining EFS Recovery Agents Defining an EFS recovery agent involves two steps: 1. Obtain a certificate with the File Recovery application policy OID. 2. Designate the certificate as the EFS recovery agent (in domain or local group policy). Obtain an EFS Recovery Agent Certificate This is the first step to ensure that the user assigned the EFS recovery agent role acquires an EFS Recovery Agent certificate. An EFS Recovery Agent certificate includes the File Recovery application policy OID (1.3.6.1.4.1.311.10.3.4.1). There are four ways this type of certificate can be obtained: ■ Request a certificate based on the EFS Recovery Agent certificate template. You must modify the default template permissions to assign Read and Enroll permissions. ■ Request a certificate based on a custom version 2 certificate template based on the EFS Recovery Agent certificate template. The advantage of a version 2 certificate template is that you can require CA certificate manager approval before issuance. Note For Windows Vista and Windows Server 2008, you can store the EFS Recovery Agent certificate on a smart card. Windows 2000 and Windows XP are limited to software-based EFS Recovery Agent certificates. ■ Use the cipher /R:filename command to generate a certificate file and a PKCS #12 file containing the private key on a computer running Windows XP or Windows Vista. ■ In a Group Policy Object (GPO), right-click the Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypting File System policy, and then click Create Data Recovery Agent. Note The Create Data Recovery Agent option requires that the EFS Recovery Agent certificate template be available for enrollment at an enterprise CA in the forest and that the user performing the procedure is assigned the Read and Enroll permissions for the EFS Recovery Agent certificate template. 518 Part III: Deploying Application-Specific Solutions Designate the EFS Recovery Agent Once you issue the certificate with the File Recovery application policy OID, you must import the certificate, as follows: ■ In a domain environment, you can import the EFS recovery agent’s certificate into the Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypting File System policy of a GPO. The GPO must be linked to the organizational unit (OU) where the user’s computer account, not the user account, exists. The certificate can be imported from either a Base-64 or DER-encoded certificate file, or from AD DS if the certificate template enables publication of the certificate file. ■ In a workgroup environment, you can import the EFS recovery agent’s certificate into the Computer Configuration\Windows Settings\Security Settings\Public Key Policies\ Encrypting File System policy (of the local computer). In this scenario, the EFS Recovery Agent certificate must be imported from a file. Note If you generated the EFS Recovery Agent certificate by using the Create Data Recovery Agent option in Group Policy, you do not have to import the certificate. The EFS Recovery Agent certificate is automatically added to the GPO policy. Choosing EFS Recovery Agents If you work for a large organization, provide the private key associated with the EFS Recovery Agent certificate to the internal audit department. Members of the internal audit department can then import the certificate and private key, allowing them to open any file stored on the corporate network without intervention by network administra- tors when performing an audit. Removing control of the private key from the network administrator also prevents the network administrator from opening encrypted files. Large organizations may also require more than one EFS recovery agent. In forests with multiple domains, an organization may implement a different EFS recovery agent for each domain. Rather than having disjoint EFS recovery agents, consider implementing two EFS recovery agents at each domain: one EFS recovery agent that is unique to the domain and another EFS recovery agent that is common to all domains in the forest. The common EFS recovery agent provides centralized recovery, and the unique EFS recovery agent provides decentralized recovery to the organization. Securing the Private Keys If you issued a software-based EFS Recovery Agent certificate, it is recommended that you remove the EFS recovery agent’s private key from any user profile. This protects against an attacker attempting to log on as the EFS recovery agent and accessing the private key. Chapter 20: Encrypting File System 519 To remove the EFS Recovery Agent certificate and private key from the user’s profile, you can export the certificate and private key and enable the options to Delete The Private Key If Export Is Successful and Enable Strong Private Key Protection. These options ensure that the private key is removed from the user’s profile and that the PKCS #12 export file is protected with a password. Once removed, you should store the PKCS #12 on removable media and store the media in a secure location, such as a safe. If you stored the EFS Recovery Agent certificate on a smart card, the private key never leaves the smart card chip. The smart card allows you to perform EFS recovery operations on any computer running Windows Vista or Windows Server 2008 with a smart card reader. When the recovery operation is complete, the smart card can be stored in a safe to provide physical security. Key Recovery You can enable key recovery for EFS encryption certificates. This allows the recovery of a lost EFS encryption private key without the intervention of an EFS recovery agent. A certificate manager extracts the encrypted private key from the CA database, and a key recovery agent decrypts the private key and distributes the resulting PKCS #12 file to the original user, allowing the original user to import the private key back into the user profile. Note Enabling key recovery at an enterprise CA running on Windows Server 2008 Enterprise is covered in Chapter 18, “Archiving Encryption Keys.” Once your recovery methods are defined, you can start deploying EFS encryption certificates to users. Implementing EFS The deployment scenario that follows assumes that you implement key recovery and data recovery for an organization’s EFS implementation. To deploy this solution, you must define the necessary certificate templates and plan how to deploy certificates to users. Enabling and Disabling EFS An organization might not want to allow EFS encryption on all client computers, preferring instead to enable EFS encryption for specific OUs or domains. Enabling EFS To enable EFS encryption on a computer running Windows 2000, you must ensure that an EFS recovery policy is implemented at the domain or OU containing the computer account that designates one or more EFS Recovery Agent certificates. Windows XP and Windows Vista can implement EFS encryption without designating an EFS recovery agent. 520 Part III: Deploying Application-Specific Solutions Note In a Windows 2000 domain, EFS is enabled by default. The EFS Recovery Agent certificate’s private key is stored in the first administrator’s profile on the first domain controller installed in the domain. Disabling EFS To disable EFS encryption on a computer running Windows 2000, you must implement an empty EFS recovery policy, where an EFS recovery policy is designated with no EFS Recovery Agent certificates. Note Enabling an empty EFS recover y policy is different from implementing no EFS recovery policy. If no EFS recovery policy is implemented, the client computer implements the EFS encryption settings defined in the local security policy. To disable EFS encryption on a computer running Windows XP or Windows Vista, you must configure Group Policy to block EFS encryption. This is accomplished with the following procedure: 1. Link a new GPO to the OU where the computer accounts of computers running Windows XP exist. 2. Open the GPO in the Group Policy Editor. 3. In the console tree, navigate to Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypting File System. 4. In the console tree, right-click Encrypting File System, and then click Properties. 5. If editing the policy for Windows XP or Windows Server 2003, in the Encrypting File System Properties dialog box, clear the Allow Users To Encrypt Files Using Encrypting File System (EFS) check box, and then click OK. 6. If editing the policy for Windows Vista or Windows Server 2008, in the Encrypting File System Properties dialog box, on the General tab, set File Encryption Using Encrypting File System to Don’t Allow, and then click OK. Certificate Templates for EFS Encryption Three certificate templates are required when deploying an EFS encryption solution with both data recovery and key recovery: ■ An EFS Recovery Agent certificate template ■ A Key Recovery Agent certificate template ■ An EFS user certificate template The sections that follow describe the specific configuration recommendations for each certificate template. [...]... (http://www .microsoft. com/traincert/syllabi/ 282 1afinal.asp) ■ Microsoft Windows Security Resource Kit, by Ben Smith and Brian Komar (Microsoft Press, 2003) ■ “Key Archival and Recovery in Windows Server 20 08 (http://go .microsoft. com/fwlink/ ?LinkID=92523) ■ “Encrypting File System in Windows XP and Windows Server 2003” (http://www .microsoft. com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx) ■ “The Windows. .. the Enrollment Agent certificate and private key ❑ Smart card authentication The smart card authentication certificate must include the Client Authentication (1.3.6.1.5.5.7.3.2) OIDs in the certificate s Enhanced Key Usage (EKU) or Application Policies extension for Windows Vista and Windows Server 20 08 clients For Windows 2000, Windows XP, and Windows Server 2003 clients, the certificate must also... the Certificates MMC console is the biggest change in behavior from previous versions of Windows Prior to Windows Vista, you had to request a smart card certificate by using the Certificate Services Enrollment Web Pages Windows Server 20 08 removes the smart card enrollment pages from the Certificate Services Enrollment Web pages and supports only requests that use the Certificates console 1 Open the Certificates... user certificate store, the enrollment attempt of a Company EFS Recovery Agent certificate will result in the EFS Recovery Agent certificate being archived in the user certificate store If you are using Windows Vista clients, you can optionally change the cryptographic service provider (CSP) to a smart card–based CSP Only Windows Vista and Windows Server 20 08 clients can access the EFS Recovery Agent certificate. .. Recovery Policy in Windows 2000” ■ 315672: “How To: Use Cipher.exe to Overwrite Deleted Data in Windows ■ 320166: “How To: Identify Encrypted Files in Windows XP” ■ 32 489 7: “How To: Manage the Encrypting File System in Windows Server 2003” ■ 329741: “EFS Files Appear Corrupted When You Open Them” ■ 81 4599: “How To: Use Cipher.exe to Overwrite Deleted Data in Windows Server 2003” ■ 81 8200: “An Attacker... Authentication certificate installed Smart card authentication requires mutual authentication of the user and the domain controller involved in the Kerberos authentication Both Windows Server 2003 and Windows Server 20 08 enterprise CAs meet these requirements Alternatively, a third-party CA can issue a smart card certificate, as long as the requirements are met Note The requirements are detailed in Microsoft. .. using Windows Vista, consider storing the EFS encryption and EFS Recovery Agent certificates on smart cards Windows Vista allows you to implement the EFS encryption and EFS Recovery Agent certificates on smart cards Smart cards provide stronger protection of the private keys and portability of the keys Additional Information ■ Microsoft Official Curriculum, Course 282 1: “Designing and Managing a Windows. .. options Deploying Smart Cards with Windows Vista Windows Vista and Windows Server 20 08 allow you to deploy smart card certificates using the native tools available in the core operating systems To deploy smart card certificates in this environment, you must perform the following steps: ■ Designing an Enrollment Agent certificate template ■ Designing a smart card certificate template ■ Restricting the... (http://www.elcomsoft.com/ aefsdr.html?r1=pr&r2=efs_vista3) ■ 2 980 09: “Cipher.exe Security Tool for the Encrypting File System” ■ 302093: “How To: Prevent Files from Being Encrypted When Copied to a Server ■ 30 787 7: “How To: Encrypt a File in Windows XP” ■ 3 089 89: “How To: Encrypt a Folder in Windows XP” ■ 3 089 91: “How To: Share Access to an Encrypted File in Windows XP” ■ 3094 08: “Troubleshooting the Data Protection API... the smart card In addition, the smart card may require middleware to perform advanced functions such as resetting PINs and loading application code Note In Windows Vista and Windows Server 20 08, Microsoft introduces the Microsoft Base Smart Card Cryptographic provider Similar to the Windows printer driver model, the base smart card CSP is a universal model where smart card vendors provide only a mini-driver . Note For Windows Vista and Windows Server 20 08, you can store the EFS Recovery Agent certificate on a smart card. Windows 2000 and Windows XP are limited to software-based EFS Recovery Agent certificates. ■. the FEK to decrypt the file. One Application, Two Recovery Methods In Windows Server 2003 PKI and Windows Server 20 08 PKI deployments, EFS allows two methods to recover an EFS-encrypted file. 15, “Issuing Certificates.” If a client is running Windows 2000 or Windows XP, it can perform remote encryption on a file server computer running Windows Server 20 08, as long as the server is trusted