Chapter 17: Windows Server 2003 PKI-enabled Applications

In the previous chapters we introduced Windows Server 2003 PKI. In this chapter we focus on three applications that can leverage your PKI investment: the Encrypting File System (EFS), S/MIME for secure messaging, and smart card–enabled applications. Windows Server 2003 obviously supports many other PKI-enabled applications, some of which were covered in previous chapters (such as SSL/TLS for secure Web communications); others are out of the scope of this book (these include communication security solutions like IPsec, wireless authentication using 802.1x, and EAP-TLS).

One of the key messages you should remember from the previous chapters is that a PKI is an infrastructure, of which multiple applications can take advantage to provide strong public key cryptography–based security to their users.

17.1 Encrypting File System

The disclosure of confidential information to unauthorized parties is a serious threat from which any organization should be protected. The Encrypting File System (EFS), a feature of the Windows 2000, XP, and Windows Server 2003 NTFS version 5 file systems, provides file system–level encryption of files and folders stored on NTFS volumes. Before Windows 2000, NT users had to use the products of other vendors to implement an encryption solution.

17.1.1 The end user EFS experience

As in Windows 2000, Windows XP and Windows Server 2003 NTFS files and folders can be encrypted manually by checking the “Encrypt contents to secure data” box in the advanced properties or by choosing the Encrypt command on a file or folder’s shortcut menu. If you set the encryption attribute on the folder level, newly created files in the folder will be automatically encrypted. Unless you check the “Apply changes to this folder, subfolders, and files” checkbox, files that already existed in the folder before the encryption attribute was set will not be encrypted. The same is true for decryption.

The Encrypt/Decrypt shortcut context menu option for the Windows Explorer is disabled by default. To enable it, add the EncryptionContext- Menu value with REG_DWORD data value 1 to the HKEY_LOCAL_ MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\ Advanced registry key.

The cipher.exe tool can be used to automate and enforce encryption from the command prompt. You can include it in a user’s logon or logoff script or in a machine’s startup or shutdown script. In a Windows 2000 and Windows Server 2003 environment, you can automatically distribute these scripts throughout the enterprise using GPOs. Table 17.1 lists some sample cipher commands and their effect.

Table 17.1: Cipher Switches

Command	Effect
Cipher /E /A /I <path>	Encrypts all files and subfolders in the specified file system path and ignores possible errors.
Cipher /D /A /I <path>	Decrypts all files and subfolders in the specified file system path and ignores possible errors.
Cipher /E /A <path>/*.txt <path>/*.bat	Encrypts all txt and bat files in the specified file system paths.
Cipher /E /A /F <path>/*.*	Forces the encryption of all files in the specified file system path. Files that were encrypted previously are reencrypted.
Cipher <path>	Shows the EFS status (U or E) of all files and/or folders in the specified file system path.
Cipher /U	Updates all DDF and DRF fields of encrypted files to reflect the latest user encryption key and the latest recovery agent recovery keys.

When using EFS, do not forget that the account that can encrypt data is not restricted to the owner of the data. In order to encrypt a file, you don’t need file or folder ownership, but you need at least read/write permission to the file or folder.

17.1.2 EFS internals

The software technology behind EFS is a good example of a hybrid crypto- graphic solution combining the power of both asymmetric and symmetric ciphers. EFS uses a symmetric cipher (AES)^[1] to perform the bulk encryption and an asymmetric cipher (RSA) to provide secure storage of the bulk encryption key. The bulk encryption key is known as the File Encryption Key (FEK). The EFS operation is illustrated in Figures 17.1 and 17.2.

Figure 17.1: : How EFS encryption works.

Figure 17.1 illustrates an EFS encryption operation:

1. The EFS service opens the file for exclusive access.

2. The file data are copied to a temporary file for recovery purposes.

3. A file encryption key (FEK) is randomly generated and used to encrypt the file data blocks using a symmetric key cipher (in this example DESX).

4. A data decryption field (DDF) is created containing the FEK encrypted with the user’s public key.

5. A data recovery field (DRF) is created containing the FEK, this time encrypted using the recovery agent’s public key (this operation is done for every recovery agent).

6. The EFS service writes the encrypted data, along with the DDF and DRF, back to the file.

7. The temporary file is deleted from disk.

Figure 17.2 illustrates an EFS decryption operation:

1. When an application accesses an encrypted file, NTFS recognizes the file was encrypted and sends a request to the EFS driver.

2. The EFS driver retrieves the DDF and passes it to the LSA.

3. The LSA decrypts the DDF with the user’s private key to obtain the File Encryption Key (FEK).

4. The LSA passes the FEK back to the EFS driver.

5. The EFS driver uses the FEK to decrypt the file.

6. The EFS driver returns the decrypted data to NTFS, which then sends the data to the requesting application.

The processes behind EFS decryption and EFS recovery are identical. The only thing that is different is the private key used to do the decryption of the FEK. For decryption, the data owner’s private key is used (as illustrated in Figure 17.2). For recovery, the data recovery agent’s private key is used.

Figure 17.2: How EFS decryption works.

The encrypted FEK is stored along with every encrypted file or folder, in the NTFS $EFS attribute. The $EFS attribute is stored in a file’s Logged Tool Stream attribute ($Logged_Utility_Stream). Changes to this attribute are logged in the NTFS change log. EFS encrypts an NTFS file’s content, contained in the unnamed “$data” stream, but also every additional NTFS file stream. For more information on NTFS file streams, see the following sidebar.

EFS stores multiple encrypted versions of the FEK: one for the account that encrypted the information and one for every recovery agent. The first is stored in the Data Decryption Field (DDF) and the latter is stored in the Data Recovery Field (DRF). DDF and DRF are also known as key rings.

Both the DDF and DRF can contain different key entries. The DDF can contain different user decryption key entries (in Windows 2000 the DDF can only contain a single decryption key). The DRF can contain different recovery agent key entries.

NTFS File Streams NTFS file streams are also referred to as alternate data streams. An NTFS file always includes a default data stream, the $DATA stream, which includes the file’s content. Every NTFS file can also have alternate data streams that Windows Explorer cannot see and that attackers can therefore use to hide malicious information or code on your system. The main reason why Microsoft included the alternate data stream capabilities in NTFS was to enable a Windows NT system to act as a file server for Macintosh clients. The Mac OS uses a similar feature, resource forks, to store file metadata (e.g., date and time information).

To set up an alternate data stream, type the following at the command prompt:

echo top secret > file.txt:stream1

This command adds an alternate data stream called stream1 to the file.txt file. To display stream1’s contents, type the following at the command prompt:

more < file.txt:stream1

NTFS alternate data streams are dangerous. You do not want a malicious person to hide anything on any of your organization’s core systems (e.g., file servers, Web servers, domain controllers). The first level of protection you should use is the NTFS access control settings. If attackers cannot access a file, they cannot create alternate data streams. If a malicious person manages to bypass the permissions you have set, you will need special tools to detect the existence of alternate data streams. System-integrity-checking software, such as the Tripwire integrity checker, can detect any changes (e.g., the addition of or changes to alternate data streams) that occur on a system. More information about the Tripwire is available from http://www.tripwiresecurity.com. To find out whether files have alternate data streams, you can use the Streams command-prompt utility, which is free and available at the Sysinternals Web site: http://www.sysinternals.com/ntw2k/source/misc.shtml#streams.

DDFs and DRFs contain, besides the encrypted bulk encryption key, information that facilitates the lookup of the account’s private key that is needed for the decryption of the FEK:

• The account’s distinguished name

• The CSP (Cryptographic Service Provider) used for encryption/ decryption

• The location that the CSP uses to store the certificates (certificate store container)

• The certificate thumbprint

To retrieve a private key from a user’s private key store, the Local Security Authority (LSA) will pass the certificate’s thumbprint and certificate store to the CSP. The $EFS file attribute (containing a file’s DDFs and DRFs) also contains a checksum that is used by the EFS system to detect integrity changes on the DDF and DRF level. This protects against tampering with the EFS data on the file system level.

To look at the content of the DDF and DRF fields, you can use the efs- info or the efsdump tools. The first one comes with the Windows Server 2003 operating system. The latter is available from the sysinternals Web site at http://www.sysinternals.com. Efsdump displays the contents of the DDF and DRF key rings. For each entry, it shows the account name and the Subject’s Distinguished Name. With efsinfo you can do the same and even more. Two interesting efsinfo switches are /C and /Y. The /C switch displays the certificate thumbprints of the encryption and recovery certificates, referred to in the DDF and DRF rings. The /Y switch displays the thumb- print of a user’s local EFS certificate. To look at both the DDF and DRF fields and the associated certificate thumbprints, use efsinfo /u /r /c <file- name> (as illustrated in Figure 17.3).

Figure 17.3: Using efsinfo.

All EFS operations (encryption, decryption, and recovery) are fault tolerant and are logged. During an EFS operation, a hidden log file (named efs0.log) is created in the hidden system volume information folder. Besides a log file the EFS system also creates a temporary backup of the file being encrypted in the file’s directory (named efs0.tmp). If your system crashes during an EFS encryption operation, the EFS operation will be rolled back and the original, possibly corrupted, file will be replaced with the backup file. To look at what is happening behind the scene on the file system level when using EFS, you can use sysinternals’ Filemon tool (available from their Web site).

For obvious security reasons, the FEK is never paged to disk. However, some applications dealing with an encrypted file might copy some of the cleartext to the paging file. Because the paging file is a system file and thus cannot be encrypted, Microsoft advises users to clear the paging file at system shutdown. This can be automated by setting the GPO setting “Clear virtual memory page file when system shuts down.”

The generation of a private-public key pair and a special EFS certificate happens transparently. When the users check the encrypted property, choose the encrypt option in the context menu, or encrypt a file or folder using the cipher command prompt tool, the system will automatically generate a private-public key pair and send a public key certification request to a Windows 2000 or Windows Server 2003 enterprise Certification Authority (CA). If no CA is available, a self-signed certificate will be generated by a CSP on the local machine. This enables EFS to function even in the absence of a CA.

Once the EFS certificate is created or downloaded to the local certificate store, a reference to it (the certificate hash) is put in HKEY_CURRENT_ USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\ CertificateHash. This value can be retrieved from the registry using the efs- info tool with the /Y switch.

The following certificate templates can be used for EFS operations: user, administrator, and basic EFS. EFS certificates can be issued by a Windows 2000 or Windows Server 2003 stand-alone or enterprise CA. EFS certificates can also be generated by third-party non-Windows CAs. How to do this is explained in the Microsoft Knowledge Base article Q273856, available from http://support.microsoft.com/default.aspx?scid=kb;en-us;273856.

Just like any other personal certificate, EFS certificates (and with them the EFS public keys) and EFS private keys are stored in the user’s profile. More information on the storage of certificates and private keys can be found in Chapter 13. Even though theoretically EFS certificates and private keys can be stored on a smart card, EFS cannot access them when they are stored on a smart card. This is because EFS is hard coded to only use the Microsoft Base, Enhanced or Strong Cryptographic Service Providers (CSPs —see Chapter 13).

17.1.3 EFS data recovery

A key feature of EFS is its ability to recover encrypted files or folders, when a user’s private key is lost or becomes inaccessible. Loss of private keys can occur because of hardware or software problems on a user’s computer. EFS data recovery can also be useful when an employee leaves the company, when his or her account and profile are deleted, or when access is needed to files previously encrypted by that employee.

Besides EFS data recovery the Windows Server 2003 CA can also EFS key recovery: this feature was explained in Chapter 15.

EFS data recovery means that a Windows account, known as the recovery agent, other than the original account that encrypted the data, can decrypt the FEK and recover the user’s data. The recovery agent can recover a file if his or her public key was used to encrypt the FEK and the resulting encrypted FEK is part of the encrypted file’s NTFS $EFS attribute; in other words, when the account was defined as a recovery agent on the moment the file was encrypted. A recovery agent needs to have a special key pair and a special certificate (an EFS recovery certificate) before the EFS encryption process takes place.

EFS recovery agents can be defined on the domain, site, organizational unit, or local machine level. You use the Windows 2000 or Windows Server 2003 group policy object (GPO) Encrypting File System entry to define them. This entry is located in the Security Settings\Public Key Policies container. The EFS GPO entry contains the EFS recovery certificates of Windows accounts that are designated as recovery agents by the GPO administrator. To facilitate the life of administrators, Microsoft provides a wizard to set the recovery agents (which is illustrated in Figure 17.4). In the wizard, the recovery certificates can be downloaded from the Active Directory or can be imported in *.cer format. You must publish the certificates manually to AD to make them available from AD; the Windows CA does not automatically publish them in AD.

Figure 17.4: Setting up an EFS recovery agent using GPOs.

EFS recovery certificates have File Recovery (OID 1.3.6.1.4.1.311.10.3.4.1) in the Enhanced Key Usage field. They can be generated by an enterprise or a stand-alone CA. They can even be generated without the intervention of any CA: The recovery certificates that are generated on a stand-alone machine are self-signed recovery certificates for the local administrator generated by the local machine. To manually generate a self-signed EFS recovery agent certificate and private key on a Windows XP or Windows Server 2003 stand-alone machine, use the cipher command with the /r switch.

Enabling EFS recovery does not necessarily require a CA. However, within an AD environment, the use of a CA for the generation of EFS recovery certificates will offer more flexibility and centralized control over EFS recovery:

• An organization can provide EFS recovery privileges (in the form of an EFS recovery certificate) to specific administrator accounts.

• An organization can control the validity of an administrator’s EFS recovery privilege because it has control over the lifetime and revocation status of EFS recovery certificates.

In Windows 2000 EFS, the default recovery agent is the administrator account. On a stand-alone machine, this is the local administrator account. On a machine member of a domain, it is the domain administrator. It is a best practice to change the default domain recovery account administrator to some other account. Windows Server 2003 EFS contains some important changes regarding EFS recovery are explained next.

The EFS recovery GPO settings are downloaded to the machine at startup, at the predefined GPO update interval, or when GPO application is enforced. Changes in the policy’s content are not applied immediately to every encrypted file or folder in the policy scope. EFS will enforce and apply the change the first time it is used following the policy change.

Remember that to define a new DRF, EFS needs access to the FEK, which is only available at decryption time.

This explains why you must always archive the private keys and certificates of old recovery agents. Doing so, you will always be able to access any encrypted file, even those that have not been opened since an EFS recovery policy change occurred. To archive a recovery agent’s private key and certificate, export them using the certificate export wizard. To find out which archived keying material you should use for a recovery, use the efsinfo tool with the /C switch to retrieve the recovery agent’s certificate thumbprint from the encrypted file.

Special care must be taken of the place where the archived recovery agent private keys are stored. They should be protected from unauthorized access. Anyone possessing the recovery private key can read any encrypted file or folder within the EFS recovery policy scope. A best practice is to put the private key on a floppy disk or on a smart card and lock it in a safe. Also, when requesting a recovery certificate using the CA Web interface, be sure to check “Enable strong private key protection” in the advanced request settings to provide another level of software protection.

Besides archiving the recovery agent’s private key, you should also delete it from the local system. “Delete the private key if export is successful” is an option that can be set in the certificate export wizard. The reason to do this is related to a fundamental security principle: Encryption keys should never be stored near the files they secure. This is a must-do for stand-alone machines; it is less critical for machines in a domain, where the recovery agent’s private key is almost certainly located on another machine. In mid- 1999 a hacker found this weakness and received lots of press attention. A less secure alternative is to use a dedicated highly secure workstation, preferably off the network, that has a local copy of the recovery private key and that is only used for EFS recovery.

The preferred procedure to recover an encrypted file is the following: Let the user back up the file using NTbackup or any third party backup solution that uses the NTBackup APIs (this is the only way that an encrypted file can be exported from a Windows system without decrypting it). Let him or her send it to a recovery agent using a secure channel. Let the recovery agent do the recovery, and let the recovery agent send the decrypted file back to the user, once more using a secure channel. A secure channel can be created by delivering the file out of band using a floppy, by copying it to a share across a VPN tunnel, or by sending it using a secured S/MIME mail message. Another way, less secure and thus less preferred, is to use a dedicated machine to perform the recovery of encrypted files.

17.1.4 Windows 2000 EFS: The bad and the ugly

Windows 2000 EFS is far from perfect from a security point of view when it is used on a stand-alone machine. Stand-alone in this context means a machine that is not a member of a Windows domain. Hackers have created tools to reset the user password of user accounts stored in a machine’s local security database. These tools even work when the syskey cryptographic SAM protection feature is enabled. If you succeed in obtaining a user’s credentials, you can obviously also access its encrypted files. If you get access to a local administrator’s account, you can access all locally encrypted files of all users. This is because by default in Windows 2000, the local administrator is the EFS recovery agent. A very popular tool in this area is the ntpasswd tool, which can be downloaded from http://home.eunet.no/ ~pnordahl/ntpasswd. This attack can be countered by using syskey encryption in an operation mode where the system key is not stored on the Windows system itself (this is mode 2 or 3).

Windows 2000 EFS also lacks several interesting features. A good example is EFS’s inability to let users share encrypted files with other users. The absence of these features together with the security issues made many enterprises choose solutions from other vendors to provide file encryption on their file servers, user desktops, and laptops. Popular examples are the solutions from F-Secure, SafeBoot, Utimaco, and Pointsec. In Windows XP and Windows Server 2003, Microsoft tries to remedy the obstacles encountered in Windows 2000 EFS.

17.1.5 New EFS features

The following sections provide an overview of the new features in Windows XP and Windows Server 2003 EFS.

EFS file sharing

Perhaps the most visible change to Windows XP and Windows Server 2003 EFS is the support for EFS file sharing. It enables users to share encrypted files with other users. From an administration point of view, things would certainly have been much simpler if Microsoft had let users share their encrypted files with Windows groups. Because EFS relies on X.509-based certificates that by definition honor the principle of individual accountability, this is impossible. EFS file sharing only applies to NTFS files, not to NTFS folders.

EFS file sharing is enabled in a file’s advanced properties. Before you can share an encrypted file, it must be encrypted. If a file is encrypted, you will notice that the Details button in the file’s advanced properties becomes available. Pushing this button brings up the dialog box illustrated in Figure 17.5, allowing you to share an encrypted file with other users. In Figure17.5, you can see that the projectstatus.doc file is encrypted and shared between users Jan, Katrien, and Wim. The sharing of an EFS encrypted file is not an explicit privilege of the user account that encrypted the file and shared it with another user. In the example of Figure 17.5, Jan may have encrypted the file and decided to share it with Katrien. Katrien on her turn may then have decided to share it with Wim.

Figure 17.5: Setting up EFS file sharing.

Let’s look now at how EFS determines whether a user is authorized to change a file’s EFS sharing properties and with whom he or she can share the file. To change a file’s EFS sharing properties, you need at least write permission to the file. To share a file with another user, you need access to that user’s EFS encryption certificate. From the Select User dialog box (illustrated in Figure 17.5), you can access the user certificates stored in the Other People and Trusted People certificate containers of your certificate store.^[2] If your machine is a member of a Windows Active Directory–based domain, you will notice that the Find User… pushbutton also lights up. Pushing this button lets you access the EFS user certificates published in Active Directory. If you want to share encrypted files with people whose EFS certificate is not available in one of the above repositories, you can always import it manually into your certificate store.

To better understand how EFS file sharing really works, it is worth looking at the cryptographic nuts and bolts of EFS file sharing. When a user shares an encrypted file with another user, an extra Data Decryption Field (DDF) is added to the file’s EFS-related NTFS file streams. At no point in the EFS file sharing process is the file itself decrypted. When Jan decided to share a file he previously encrypted with Katrien, EFS will decrypt Jan’s DDF with Jan’s private key in order to retrieve the File Encryption Key (FEK). The EFS system will then encrypt the FEK using Katrien’s public key and add the resulting DDF to the file’s EFS-related NTFS file streams.

Before a user may be added to the list of users who can access an encrypted file, the EFS software validates the user’s certificate. This happens when a user’s certificate is selected (as illustrated in Figure 17.5). During the validation, the EFS software will perform a complete certificate chain validation. This includes a trust and certificate revocation check for all certificates included in a user’s EFS certificate chain.

Web folder and WebDAV integration

An important Windows 2000 EFS design limitation surfaces when EFS is used to protect the confidentiality of files stored on file servers. The key problem here is that files are always decrypted locally on the file server and then transmitted in the clear to the user workstation. This setup also requires the file server to be trusted for delegation and to have access to a local copy of the user profile. The latter are consequences of the fact that EFS needs access to a user’s private key (which is stored in the user profile) in order to decrypt an encrypted EFS file.

Windows XP and the Windows Server 2003 Web server (IIS 6.0) come with an interesting alternative for the use of EFS on file servers. In Windows XP and Windows Server 2003, Microsoft embedded support for the transport of EFS metadata using the WebDAV protocol. WebDAV stands for Web Distributed Authoring and Versioning. It is an extension of the HTTP 1.1 protocol that allows for file metadata to be transported together with the file across an HTTP connection. Support for the WebDAV protocol has been available on the client side from Internet Explorer 5.0 (through the Web Authoring Components) and on the server side from IIS 5.0 on.

The WebDAV support makes Web folders a worthy alternative to file shares for the use of EFS on file servers. That is also why Microsoft strongly recommends the Web folder solution instead of file shares for remote storage of encrypted data on file servers. The combination of EFS file sharing, Web folders, and WebDAV makes the Windows Server 2003 platform a very interesting option for the setup of secure file servers. Table 17.2 compares the features of using file shares for remote EFS operations versus those of using Web folders.

Table 17.2: Comparison Between the Features of Remote EFS Operations on File Shares and Web Folders

Remote EFS Operations On…	…File Shares	…Web Folders
Where does EFS encryption/decryption occur?	Files are encrypted and decrypted on the file server.	Files are encrypted and decrypted on the user machine.
Are the files secured during transmission over the network?	Files are sent in the clear over the network connection.	Files remain encrypted while being sent over the network connection.
What technology is or can be used to secure the transmission of the files over the network?	Requires IPsec to secure the file transfer between file server and user machine.	Does not require IPsec to secure the file transfer; relies on the WebDAV EFS extensions to securely transmit the file.
Must the file server be “trusted for delegation”?	Requires file server to be “trusted for delegation.”	Does not require file server to be“trusted for delegation.”
Does the solution require a copy of the user profile on the file server?	Requires availability of user profile on the file server (local or roaming profile).	Does not require availability of user profile on the file server.
Where does EFS file sharing authorization process for users take place?	EFS checks for other user certificates on the file server and/or in Active Directory.	EFS checks for other user certificates on the local machine and/or in Active Directory.
What file transport protocol/method is used?	File sharing uses SMB. SMB supports streaming and block by block writeback, which is much more efficient and performs better than HTTP-based downloading.	Web folder-based sharing uses HTTP. HTTP requires the entire file be uploaded or downloaded before an application can have access to it.

Setting up a Web folder is relatively easy. Open up the properties of the file, select the Web Sharing tab, and click “Share this folder” (as illustrated in Figure 17.6).

Figure 17.6: Setting up a Web folder.

Offline files and folders EFS support

Windows 2000 introduced the concept of offline files and folders. It enables users to access files and folders on network shares even when the user’s machine is disconnected from the network. To do so, the offline files and folders system keeps a local copy of the files and folders shared on the remote machine and—even more importantly—keeps the remote and local copy of the data synchronized. All offline files and folders are stored in a Client-Side Cache (CSC) database, which is located in the hidden %systemroot%/CSC folder. In Windows 2000, offline files and folders do not preserve their EFS encryption attributes when they are copied to the local machine. Also, in Windows 2000 it was not possible to encrypt the CSC database.

From Windows XP and Windows Server 2003 onward, the EFS encryption attributes are preserved when a remote file or folder is made available offline. Also, the local client-side cache database can be encrypted.

To enable the encryption or the client-side cache database, open up My Computer or Explorer, and select Folder Options from the Tools menu. On the Offline Files tab, first enable offline files by checking the “Enable offline files” checkbox, then check the “Encrypt offline files to secure data” check-box (as illustrated in Figure 17.7). When setting this option, the offline files in the CSC database will be encrypted using a self-signed EFS certificate issued to <local_machinename>$ (as illustrated in Figure 17.8).

Figure 17.7: Enabling EFS encryption for offline files and folders.

Figure 17.8: Viewing the encryption details on the offline files and folders CSC database.

Preservation of the EFS encryption settings happens automatically when making a file or folder available offline. This is done by right-clicking the original file on the remote share and selecting “Make Available Offline.” An important detail is that offline files and folders functionality is not available when the XP “Fast User Switching” feature is enabled.

Cryptographic changes

Windows XP and Windows Server 2003 can both be configured to use the 3DES algorithm for EFS encryption and decryption operations. 3DES is compliant with the U.S. Federal Information Processing Security Standards (FIPS) 140-1 Level 1. The default encryption algorithm used by EFS in Windows 2000 and XP is DESX. The default encryption algorithm used in Windows XP Service Pack 1 and Windows Server 2003 is AES with a 256- bit key. Even after setting up Windows 2000, Windows Server 2003 and Windows XP to use 3DES, DESX or AES support (depending on the platform) is not lost. The platforms are still able to process files previously encrypted with DESX or AES.

There are two ways to configure EFS to support 3DES instead of DESX. A first way is to use a new Group Policy Object (GPO) setting called “System Cryptography: Use FIPS compliant algorithms for encryption.” This setting will affect not only the encryption-decryption operations of EFS but also of other Windows security solutions such as IPsec. The GPO setting is located in the Computer configuration\Windows Settings\ Security Settings\Local Policies\Security Options GPO container. The second way is based on a registry hack and makes the use of 3DES available only to EFS. To do so, create the AlgorithmID (REG_DWORD) registry value in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\EFS registry key and set it to 0x6603.

Windows Server 2003 also supports the specification of larger default RSA key sizes for keys that are generated for EFS. The default key size used in Windows XP and Windows Server 2003 is 1024 bits. In Windows Server 2003 the default size can be changed by setting the following registry key (REG_DWORD):

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\EFS\RSAKeyLength. The range of this key is 1024 to 16384.

Disabling EFS

In Windows Server 2003, the use of EFS can be disabled using a GPO setting that is available from the properties of the Encrypting File System GPO container. To disable the use of EFS for the users in a domain, site, or OU, or on a local machine, uncheck “Allow users to encrypt files using Encrypting File System (EFS).” This setting only works for Windows XP and later machines.

As in Windows 2000, if you want to disable EFS on the file or folder level, you can still do the following in Windows XP and Windows Server 2003:

• To disable EFS on the file level, set the system attribute.

• To disable EFS on the folder level, set the system attribute or create a special entry in the folder’s desktop.ini file: Add disable=1 in the (Encryption) section.

EFS recovery changes

As explained earlier, a unique feature of EFS is its support for data recovery and the facility for designated administrator accounts to decrypt user data. Some organizations, however, do not want an encryption solution that has recovery capabilities. This may be because of advanced confidentiality requirements or because organizations simply do not trust the EFS recovery feature.

That is why in Windows XP and Windows Server 2003, Microsoft has implemented EFS recovery slightly differently. In both operating systems EFS can function without the requirement of having an EFS recovery agent defined (as was the case in Windows 2000). Also, by default, Windows XP and Windows Server 2003 stand-alone machines and Windows Server 2003 domains do not have any recovery agents defined. In Windows 2000, the local administrator account was the default local recovery agent, and the domain administrator was the default domain recovery agent. This new EFS recovery option can be enabled from the GPO MMC snap-in by right- clicking the Encrypting File System container and selecting “Do Not Require Data Recovery Agents.” This is illustrated in Figure 17.9 for Windows Server 2003; most of these options are also available for Windows XP. An option that is not available in XP is the Create Data Recovery Agent option. Contrary to the Add Data Recovery Agent option, this option does not use the recovery agent wizard. Instead, it automatically requests and installs an EFS recovery certificate for the currently logged-on user.

Figure 17.9: Define an EFS data recovery policy.

To enable all of these EFS recovery changes, Microsoft has changed the key hierarchy that it uses to protect the EFS private encryption keys in Windows XP and Windows Server 2003.^[3] EFS private keys are stored in a user’s profile and are cryptographically protected using a key called the master key. The master key is securely stored using a key that is derived from a user’s credentials. Like private keys, master keys are stored in a user’s profile. By default, Windows XP and Windows Server 2003 also provide another level of cryptographic protection for security information such as private keys: the syskey option.

All this means that when a user changes his or her password, the master key has to be decrypted and reencrypted using the new key derived from the user’s new credentials. If the latter does not occur, the user loses access to his or her master key. Things can get problematic here when a user forgets his or her password and an administrator has to force a reset of the user password. From an EFS point of view, this basically means that a user’s master key and at the same time his or her private keys become inaccessible, and thus previously encrypted EFS data cannot be decrypted anymore. From a security point of view, this is also good, because it means that tools such as ntpasswd that force a password reset for a local account become worthless when one wants to access the account’s encrypted EFS data.

To remedy the problem of a user forgetting his or her password and losing access to his or her EFS data, Microsoft provides three solutions in XP: a Password Reset Disk (PRD), a backup of the EFS private key and certificate, and EFS recovery agents. The latter two options are really nothing new because they already existed in Windows 2000. A brand-new solution in XP to let a user deal with a lost password is the Password Reset Disk (PRD). However, as explained in the next section, this solution must be handled with extreme care. If you do not use it properly, it will not resolve the problem of losing access to your EFS data.

17.1.6 The challenge of authorized EFS recovery

A Password Reset Disk first and foremost allows a user to reset his or her password on a local machine without having to call on the local administrator. Indirectly it also protects a user from losing access to his or her encrypted files on a stand-alone computer because he or she forgot a password. Always remember that a PRD only works for the local accounts on a single machine. It does not work for global domain accounts, and the same PRD cannot be used on different machines. Because the PRD is the key to resetting the user’s password, the user should always keep it in a secure place so that nobody else except for the user can obtain it.

A PRD can be created from the User account properties in the control panel “User Accounts” applet. To start the PRD Forgotten Password wizard, you must click “Prevent a forgotten password” (as illustrated in Figure17.10). The wizard will then guide you through the rest of the PRD generation process.

Figure 17.10: Starting up the Forgotten Password wizard.

What is behind this PRD from a cryptographic point of view? When a PRD is created, XP first creates a public-private key pair and a self-signed certificate. The PRD logic then encrypts the user’s actual password using the newly generated public key and stores the result of this encryption in the HKEY_LOCAL_MACHINE\Security\Recovery\<user SID> registry key. Finally, the PRD logic exports the private key to a floppy disk and deletes it from the local system.

When you enter a wrong password on the XP logon screen, XP will prompt you “Did you forget your password? You can use your password reset disk.” Clicking this phrase will start up the Password Reset wizard, which will then guide you through the rest of the password reset process. During this process you will simply be requested to enter a new password and to supply the PRD floppy disk. Behind the scenes, XP will then retrieve your PRD private key from the PRD floppy disk and use it to decrypt the encrypted copy of your password on the local machine. The fact that you have supplied the correct PRD floppy proves to the system that your request to reset your password is authentic. Given this old password, it can then derive the key that is used to secure the master key. The master key can then give the EFS system access to your private keys, and finally you regain access to your encrypted files. Because the user’s password is changed during this process, the user’s master key also has to be decrypted and reencrypted using the new key derived from the user’s new credentials. The latter two processes happen automatically when you run the Password Reset wizard.

When using a PRD, you must take care that you update the PRD every time you change your password. Updating of the PRD happens exactly the same way as you create an initial PRD. Why is it so important that you update the PRD in this scenario? If you do not, you will lose access to your EFS encrypted files the next time you run the Password Reset wizard! The problem is that when you change your password, your master key is reencrypted using a new key derived from this new password. If you do not update your PRD, the PRD’s private key will unlock an old set of credentials when it is run. The key derived from this old set of credentials will not succeed in decrypting the master key that is now encrypted with the new credentials.

A similar problem occurs when a local administrator resets your password. However, in this case it is of no use to update the PRD. The only remedy to the latter problem is to import a copy of your EFS private key and certificate. This will obviously only work if you previously created a backup of the EFS private key and certificate.

All of this is illustrated in Table 17.3, which shows the effect of several user and administrator password-related actions on (a) the password hash stored in the local security database, (b) the password stored in the secured PRD recovery registry folder, and (c) the password used to secure a user’s master key. In Table 17.3, different password-related actions occur one after the other:

Table 17.3: Password Change Scenarios and Their Effect on (a) the Password Hash Stored in the Local Security Database, (b) the Password Stored in the PRD Recovery Registry Folder, and (c) the Password Used to Secure the User’s Master Key

Timing	Action	User Password	(a) Password Hash Stored in Local Security Database	(b) Password Stored in Secured PRD Recovery Registry Folder	(c) Password Used to Secure User’s Master Key
T1	User Runs “Forgotten Password” Wizard (Creates PRD)	A	A	A	A
T2	User Runs “Password Reset” Wizard from Logon Screen	B	B	B	B
T3	Administrator Resets Password from Control Panel“User Accounts”	C	C	B	B
T4	User Imports EFS Private Key and Certificate from Backup	C	C	B	C
T5	User Resets Password from Control Panel “User Accounts”	D	D	B	D
T6	User Runs “Forgotten Password” Wizard (Updates PRD)	D	D	D	D

• At T1 the user runs the Forgotten Password wizard to create a PRD.

At that moment his password is set to A.

• At T2 the user forgets about his or her A password. To remedy the problem he or she runs the Password Reset wizard from the logon screen using the PRD. In the Password Reset wizard the user resets his or her password to B.

• At T3 the local administrator performs a password reset on the user account’s password from the Control Panel. He or she sets the user password to C.

• At T4 the user imports his or her previously backed up EFS private key and certificate into his or her personal private key and certificate store.

• AT T5 the user performs a password reset from the Control Panel.

The user changes his or her password from C to D.

• At T6 the user runs the Forgotten Password wizard to update the password reset information on the PRD.

The problems that will make it impossible to access your encrypted EFS data occur at T3 and T5 (they are marked in bold):

• At T3 the administrator resets the user password. As a consequence, the password hash stored in the local security database and the password used to secure the user’s master key become out of sync and the user’s EFS data become inaccessible. The user corrects this situation in T4 by importing his or her previously exported EFS private key and certificate.

• At T5 the user resets his or her password without doing an update of the PRD. As a consequence, the password stored in the PRD recovery registry folder and the one used to secure the user’s master key are out of sync. The user corrects this situation in T6 by updating the PRD.

From the above, we can conclude that XP adds two EFS best practices:

1. Always export a copy of your EFS private key and certificate to a floppy disk.

2. It is absolutely necessary to update the PRD after your credentials have been updated.

From what you have read so far, you may conclude that Windows XP EFS now provides perfect protection against unauthorized EFS data access. This is not completely true. Even though XP uses a different key hierarchy to protect the EFS private keys and it comes by default with an empty EFS recovery policy, the risk still exists that a hacker can exploit the EFS recovery capabilities to get access to EFS encrypted data on a stand-alone machine.

A hacker can still use a tool such as ntpasswd (more information is available at http://home.eunet.no/~pnordahl/ntpasswd) to reset a local administrator account’s password and gain administrator access to a stand-alone system. If you have administrator access, you can define an EFS recovery policy. The hacker could add the administrator account to the recovery policy. Because Windows automatically updates all EFS recovery information anytime an encrypted file is accessed, from that moment on all encrypted files that are accessed will have an EFS data recovery field (DRF) holding the recovery account of the administrator account. As mentioned earlier in this chapter tools like ntpasswd can be neutralized by using syskey protection (in mode 2 or 3).

17.1.7 EFS alternatives

Even though EFS should be used carefully (as explained earlier), it is a very good solution for desktop encryption. Table 17.4 shows some EFS alternatives.

The products in Table 17.4 can be categorized in file system level encryption solutions, file and folder level encryption solutions, and disk encryption solutions. EFS is a good example of a file system level encryption solution. The solutions differ in the way they protect the encryption keys, the level on which the encryption and decryption take place, the support for single or multiuser access, and the way they implement recovery of the encryption keys:

Table 17.4: File Encryption Products

Company	Product Name
Utimaco	Safeguard Easy
Fsecure	FileCrypto
Entrust	Entelligence File Plug-in
PGP	PGP
WinMagic	Securedoc
PC Guardian	Encryption Plus Hard Disk Encryption Plus Folders
SafeBoot	SafeBoot
Pointsec	Pointsec File Encryption

• An encryption key may be protected with another symmetric key or with a public key.

• The encryption key may be stored on the computer system or on some special device (smart card or token).

• Recovery keys may be stored with every file (decentralized) or in a central database.

• Encryption/decryption can happen on the disk level, on the file- or folder-level, or on the file system level.

• Some encryption systems are single-user oriented, whereas others can give multiple users access to the encrypted files.

^[1]In Windows 2000 EFS used DESX for bulk encryption.

^[2]The Trusted People certificate store container is used for self-signed certificates that do not chain to a trusted root CA. The other people certificate store container is the general cache for certificates that do chain to a trusted root CA.

^[3]This is related to the introduction of the Data Protection API (DPAPI—see Chapter 13) for key protection in Windows XP and Windows Server 2003.