Designing the Encrypted File System


Windows Server 2003 includes an Encrypted File System (EFS) capability that enhances the earlier EFS capabilities of Windows 2000. In this section, we ll discuss EFS in Windows Server 2003, including how it works and how to best use EFS in the enterprise. This section assumes you re familiar with the basic elements of cryptography.

EFS can be used to encrypt files and folders on an NTFS formatted volume. EFS provides additional protection over that of NTFS. The NTFS format allows you to set permissions on files and folders on an NTFS formatted volume. This controls access to the files and folders based on user rights and permissions. EFS takes it one step further and encrypts files and folders. Thus, an unauthorized user will first be denied permission to access a file or folder based on NTFS permissions. If for some reason the permissions are incorrect or someone has found a way around the NTFS permissions, the file itself is encrypted and can only be decrypted by the owner of the file, a user to whom share privileges have been granted or by a recovery agent. One common way NTFS permissions are circumvented is when laptops are stolen. Thieves can remove the hard drive and install it in a system on which they have administrative privileges, effectively granting themselves full access to the data on the hard drive. If the data is encrypted, the thief will still be unable to access the data. As the popularity and need for mobile computers continues to increase, file encryption will be increasingly important in securing corporate data.

EFS is transparent to the user ”files are encrypted and decrypted automatically in the background based on a process we ll review in a moment. However, as with all security measures, there is a trade-off between the use of encryption and system performance. EFS is notably slow the first time it is used because the encryption keys and certificates are being generated and checked. However, after the first instance, EFS is fairly fast and transparent, although it does take CPU cycles to encrypt and decrypt files and will have some impact on performance. Third-party programs are available that provide file encryption, but they are typically not as transparent to the user. These programs often require the user to encrypt and decrypt the files, requiring the user to remember to use the encryption program. This can create a security hole if users forget to encrypt important files. Every time security depends on a user taking a certain action, security is weakened. Automating security measures, such as using EFS, improves security by making the process transparent to the user rather than requiring the user to take action.

EFS uses keys for encrypting and decrypting data and can use certificate authority (CA)certificates, if available. However, one of the powerful features of EFS is that it does not require that a CA be available to use certificates. When one is not found, EFS will self-sign a certificate for use with file encryption. EFS can therefore be used on stand-alone systems as well as on members of a domain.

EFS uses the CryptoAPI (cryptography application programming interface) architecture to provide cryptographic functions. It encrypts files using a randomly generated key that is independent of a user s public/private key pair. This is the File Encryption Key (FEK), which is a symmetric encryption key used to encrypt the file. The FEK is then encrypted using asymmetric encryption for maximum security by using the public key from the user s certificate. (As you recall, a symmetric key uses the same key to encrypt and decrypt. An asymmetric key uses different keys, a public and private key set.) The encrypted FEK is stored along with the encrypted file and is a unique key for that file. To decrypt the file, the FEK must be decrypted, and this is done with the user s private key, which only the person that encrypted the file has. The combination of using a symmetric key to encrypt the file and an asymmetric key to encrypt the FEK provides an optimal balance between speed (symmetric) and security (asymmetric). The use of a symmetric key for file encryption/decryption speeds up processing time and is much faster than using an asymmetric key. The asymmetric key is used only for the FEK. Since the FEK protects the file, using an asymmetric key only for the FEK provides a good balance between performance and security.

There is another very important element of EFS called the recovery agent . Designated user accounts (typically domain Administrator accounts), called recovery agent accounts , are issued recovery agent certificates with public keys and private keys used for EFS data recovery operations. This is an important element because without the recovery agent function, a malicious user could encrypt files, denying others access to the data, or could encrypt files just before leaving the company, making important data inaccessible. With the EFS recovery agent accounts, encrypted files can be recovered. Recovery agent accounts are designated by EFS recovery policy and, by default, the recovery agent account is the highest-level Administrator account. EFS is designed so that only a system configured with one or more recovery agents can implement EFS, providing a failsafe method of data recovery. These credentials are called the Data Recovery Agent (DRA) certificates and private keys.

When a recovery agent certificate is issued, the certificate and keys are placed in the user profile of the user account that requested the certificate. The recovery agent credentials must be located on the computer on which the recovery action is to take place. The recovery agent certificate and private keys can be exported and stored in an archive or transferred to other user accounts and computers. In addition, there can be multiple recovery agent accounts for an EFS file, each with a different private key. If the recovery agent is used to recover a file, the data is unencrypted but the user s credentials are never exposed to the recovery agent. This maintains the security of the user s credentials while providing access to the encrypted data.

Test Day Tip  

Be sure to understand the EFS encryption process for the exam. You won t likely be tested on the specific process of encryption and decryption, but you ll need to understand the mechanics to correctly answer at least a few questions on the exam.

EFS Behavior

When implementing EFS, it s important to understand how EFS works so you can design a system that is appropriate for your organization. Some of the behaviors might not be as expected, so it s good to be familiar with these traits before implementing EFS.

  • EFS only works with the NTFS file system. It cannot be used with FAT or FAT32.

  • You cannot encrypt system files or folders.

  • EFS can be used to encrypt and decrypt files on a remote computer, but it does not encrypt data sent between computers (you d implement IPSec for that function, if needed).

  • You cannot encrypt compressed files and folders until you decompress them.

  • EFS does not run if there is no recovery agent certificate.

  • EFS will designate a recovery agent account by default and generate the certificate if you do not have a recovery agent certificate.

  • If a folder is encrypted, temporary files in that folder will be encrypted (recommended).

  • Copying a file into an encrypted folder will encrypt the file.

  • Moving a file into an encrypted folder will leave the file in its original state ”encrypted or unencrypted.

  • Moving or copying EFS files to another file system removes the encryption.

  • Backing up encrypted files preserves encryption.

  • File permissions are not affected by encryption. A user can delete a file that is encrypted if that user has permission to do so, even if that user does not have permission to decrypt the file.

  • Encryption is a file attribute and is listed with other attributes for that file.

    Exam Warning  

    In Windows Server 2003, users are identified by their account names , including the server name . If a user encrypts a file while logged on to a domain account, that user can only access the file when logged in to that domain account. If that user logs on to a local account, the file will be inaccessible. This type of problem might be a common help desk issue on the job and might show up on the exam as well.

EFS Best Practices

EFS is a helpful business tool, especially with mobile users. However, certain practices help ensure the EFS is properly managed across the enterprise.

Encrypt Entire Folders Rather than Individual Files

  • By encrypting folders, the files stored in those folders will be encrypted by default. This makes it easier to manage encrypted files. In addition, when a file is stored in an encrypted folder, the temporary files created during editing are also encrypted.

  • By creating files in encrypted folders, the files are never written in plain-text. Plain-text copies of files, even if temporary, could be a security problem.

  • Encrypting the My Documents folder is a useful practice when the user is connected to the same computer. Only encrypt the My Documents folder for roaming users if it is redirected to a shared network location.

Manage Private Keys to Maintain File Security

  • Keep the number of designated recovery agents to a minimum. The fewer keys that exist, the fewer targets there are. Fewer recovery agents will be easier to manage and track, reducing the chance of inappropriate or unauthorized decryption by a recovery agent.

  • Use Microsoft Certificate Services to manage EFS and DRA certificates and private keys.

  • The designated recovery agent should export the data recovery certificate and private key to disk, secure them in a safe place, and then delete the data recovery private keys from the system. The only person who can recover the encrypted files on that system is the person who has physical access to the data recovery private key. This reduces the likelihood that someone could access and use the DRA keys if they gain access to the system without having the DRA credentials.

  • If you use Certificate Services in Windows Server 2003 and a custom certificate template, do not select Prompt the user during enrollment and require user input when the private key is used . If selected, this will prevent private keys from being used for encryption and decryption, which reduces security for EFS.

Provide Security and Reliability of Data at All Times

  • Encrypt sensitive data on all computers that are members of a domain to protect against offline cryptographic attacks. Even if a computer isn t mobile, disk drives can be removed from servers and other computers to gain unauthorized access to corporate data.

  • Use IPSec to encrypt data as it travels the network, since encrypted files are transmitted in unencrypted form if IPSec is not used.

  • Use Server Message Block (SMB) signing with EFS to ensure the transmission and reception of files across the network is secure.

  • Regularly back up the entire server that stores server-based encrypted data. This ensures profiles with decryption keys can be restored. Selected backups might not preserve decryption keys in the event of a severe data loss caused by a disk crash or other problem.

start sidebar
Head of the Class
New EFS Features in Windows Server 2003

Windows Server 2003 contains several improvements to EFS over those in Windows 2000. To provide improved security, Windows Server 2003 EFS provides stronger encryption algorithms , sharing of encrypted files , and protection for locally cached files . Let s take a quick look at these features.

  • EFS in Windows Server 2003 allows stronger encryption algorithms with larger keys. EFS supports only Triple Data Encryption Standard (3DES) encryption algorithm for encrypting file data on NTFS formatted volumes . By default, EFS uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key in Windows Server 2003. In Windows XP and Windows 2000, EFS uses Data Encryption Standard Extended (DESX), a variation of the standard Data Encryption Standard. DESX uses additional 64-bit OR ing for both encryption and decryption. This improves security against a brute force attack (an exhaustive key search attack), although it does not improve security against other more sophisticated attacks including differential and linear attacks (the discussion of which is outside the scope of this book). Windows Server 2003 improves the security of EFS by implementing 3DES, which does provide improved security over all types of attacks including differential and linear as well as brute force attacks.

  • Multiple users can be authorized to share encrypted files . In previous versions of Windows Server, only one user could encrypt or decrypt a file, making file sharing of sensitive data impossible . EFS encryption keys are assigned on a per-domain-user basis to ensure each user s encryption keys are unique and secure. In Windows Server 2003, users can allow others to access encrypted files. In addition, the recovery agent mechanism provides a designated account (typically the Domain Admin account) the ability to recover encrypted files. This is done without the recovery agent having the user s private keys, increasing security at this level as well. Files that are decrypted using the recovery agent keys remain decrypted. This ensures that a rogue recovery agent does not decrypt files, read them, and re-encrypt them to cover his or her tracks. Users are added via the file s Properties dialog. We ll step through this process later in this chapter.

  • Offline files can be encrypted through EFS to protect locally cached documents. Windows Server 2003 allows users to store local copies of offline files in EFS folders, unlike Windows 2000. This is a major enhancement since so many users download corporate data to laptops for mobile computing. Now, sensitive documents can be encrypted and stored safely on a local computer. Offline files allow users to keep locally cached copies of files from a file server. These are automatically synchronized with the file server when it s available to ensure users always have access to the most current version. A common database on the local machine is used to store all offline user files and to restrict access to those files by enforcing explicit ACLs. In previous versions of Windows, there was no way to protect these files.

    Windows Server 2003 preserves the caching and synchronization mechanisms used to store local copies of documents typically stored on the network. When offline files are encrypted, the entire database is encrypted using an EFS machine certificate. In this scenario, individual files and folders cannot be selectively decrypted. Therefore, the entire offline files database is protected from attacks using EFS. This process is transparent to the user and increases security on mobile computers.

  • Web folders and files can now be encrypted with EFS. Windows Server 2003 provides the ability to encrypt Web folders and files. Although security could be applied in previous versions of Windows, the need for at least some public access of Web folders made security somewhat weak. Now, files stored in Web folders can be encrypted. Using the HTTP commands GET and PUT , raw encrypted files can be transmitted and used via the WebDAV function. Web-based Distributed Authoring and Versioning (WebDAV) is an extension of the HTTP protocol that allows users to collaboratively edit and manage files on a remote server. The Windows Server client maps a drive to a WebDAV server, and files encrypted on the local client are transmitted as raw encrypted files to the WebDAV server. Only public and private key pairs on the client are ever used in encrypting files, improving security while allowing Web files to be encrypted with EFS.

    These improvements to the EFS function in Windows Server 2003 address several weak points in EFS and provide additional functionality and flexibility in securing folders and files, especially for mobile and Web-based users.

end sidebar
 

Implementing EFS in Windows Server 2003 is a relatively simple process. It s important you try this a few times to understand how it works and how encrypted files and folders are displayed in Windows Explorer. In Exercise 9.05, you ll create an encrypted folder and file and add users so you understand how this works and how transparent it is to users.

Exercise 9.05: Implementing EFS on the Local Computer
start example

In this exercise, we ll step through encrypting a folder and file on the local computer. You ll see this process is transparent to the user and is relatively fast. We ll also add other users to the file to share the encrypted file.

  1. On your desktop, create a folder called EFSTest .

  2. Right-click the folder and select Properties .

  3. In the EFSTest Properties dialog, the General tab is selected by default. Click the Advanced button on the General tab.

  4. The Advanced Attributes dialog is displayed, as shown in Figure 9.23.

  5. There are two sections in the Advanced Attributes dialog. In the second section labeled Compress or Encrypt attributes are two check boxes. The first check box, Compress contents to save disk space , will compress the contents of the folder. The second check box, Encrypt contents to secure data , will enable encryption for the folder and all files in the folder. Notice that you cannot select both check boxes as the same time. You can select one or the other but not both (an unusual behavior for check boxes). This is because you must decompress a file before it can be encrypted, so you cannot use both simultaneously .

    click to expand
    Figure 9.23: Advanced Attributes for EFS Folder Encryption

  6. Click Encrypt contents to secure data , then click OK .

  7. In the EFSTest Properties, click OK to close the dialog.

  8. Right-click the EFSTest folder and then click Explore . In the left pane, click the Desktop node. In the right pane, the desktop items are listed, which should include the EFSTest folder. Notice that the EFSTest folder is listed in a different color and that the attribute is listed as AE. The E indicates the folder is encrypted.

  9. Select the EFSTest folder in the left pane. Click File New and select Text Document . A new document is created in the EFSTest folder called New Text Document.txt and it also has the AE attribute, as shown in Figure 9.24. Press Enter to access this new document name.

  10. In the right-pane of Explorer, right-click the New Text Document.txt file and select Properties . Click the Advanced button on the General tab of the document s Properties dialog.

    click to expand
    Figure 9.24: File Attribute Indicating Encryption

  11. In the Advanced Attributes dialog, click the Details button to display the Encryption Details for C:\ . The path displayed will depend on the location of the file to be shared. This dialog, shown in Figure 9.25, provides the ability to add users who can access the file. However, any users to be added must have a valid certificate.

    click to expand
    Figure 9.25: EFS File Sharing Dialog

  12. Click the Add button to display the Select User dialog. If you have additional users defined on the computer with certificates, they will be displayed. If the user is not displayed, you can click the Find User button.

  13. Type in the name of a defined user on the machine and then click the Check Names button to display the user account. In the example shown in Figure 9.26, user Rosie Black is added.

    click to expand
    Figure 9.26: Adding User for Shared EFS File

  14. If the user you add does not have a certificate, you will see an alert indicating the selected user cannot be added because a certificate does not exist for that user, as shown in Figure 9.27.

    click to expand
    Figure 9.27: No User Certificate Available

  15. If you receive this alert, click OK to close the Select User Alert. Otherwise, if you do not receive this alert, the user has a valid certificate and is added to the Select User list. Click OK to accept or Cancel to reject changes and close the Select User dialog.

  16. Click OK or Cancel to close the original Select User dialog.

  17. In the Encryption Details for C:\ dialog, any users you ve added are displayed in the upper portion of the dialog with User Name and Certificate Thumbprint displayed.

  18. Click OK or Cancel to close the Encryption Details dialog. Click OK or Cancel to close the Advanced Attributes dialog. Finally, click OK or Cancel to close the New Text Document.txt Properties dialog.

  19. If desired, drag the EFS Test folder to the Recycle Bin. If you do so, you can open the Recycle Bin and look in the EFS Test folder. The New Text Document.txt file is still encrypted, providing data security even when the file is deleted from the system.

  20. Close Explorer by clicking the X in the upper-right corner or by clicking File Close .

end example
 

EFS can be implemented on the local computer or on a remote server. You can do this in one of several ways. You can set recovery policy via Group Policy on the local computer or for the domain via the MMC Group Policy Editor snap-in. You can also use a command line utility, cipher.exe , to display or alter encryption on folders and files. We ll discuss the cipher.exe command-line utility in just a moment.

Certificate Storage

User certificates that contain the public keys are stored in the Personal certificate store for the certificate owner s user account. A certificate provides assurance that the public key is bound or attached to a specific entity (typically a user or computer) that owns the private key. Certificates are stored in plain-text. Since they are public information and are digitally signed, they are protected from tampering. Private keys, however, must be kept secure so that only the owner of the private key has access to it.

Certificates are issued by CAs, which can be native to Windows or third-party CAs. EFS issues its own certificates if it cannot contact a CA. However, you can deploy Certificate Services to issue EFS certificates. Doing so provides several benefits, including:

  • Centralized certificate management

  • Certificate revocation lists

  • Ability to issue alternate recovery agent certificates to designated user accounts

Each user s certificate store contains all certificates issued to that user. They are stored in the following location:

  Systemroot\  Documents and Settings\<  username  >\ApplicationData\Microsoft\SystemCertificates\ My\Certificates 

Each time a user logs on, the person s certificates in the user s profile are written to the user s personal store in the system Registry. If a user has a roaming profile, the certificates are located on a DC so that the certificates are available regardless of where the user logs on. Certificates can be viewed and managed in the Certificates Snap-in in the MMC. A user might have more than one certificate related to EFS. In the Certificates snap-in, there is a column labeled Intended Purposes. If the entry in that column is Encrypting File System, the certificate is used with EFS.

Recovery certificates appear in the personal certificate store for the recovery agent account. In the column labeled Intended Purposes, the entry will be File Recovery instead of Encrypting File System.

Private keys are stored in the following path:

  Systemroot  \Documents and Settings\ApplicationData\Microsoft\Crypto\RSA 

If a user has a roaming profile, the private keys will be stored on the DC in the RSA folder.

As mentioned earlier, private keys must be protected. Stolen or compromised private keys pose a serious security risk. All files in the RSA folder are automatically encrypted with a random, symmetric key called the user s master key . The user s master key is generated by the RC4 algorithm, which generates a 128-bit key for computers that support Enhanced CSP or a 56-bit key for computers that support Basic CSP. A CSP is a cryptographic service provider that is an independent software module providing actual cryptographic functions. The master key is generated automatically and is periodically renewed. Any file created in the RSA folder is automatically encrypted. Both EFS and CSPs look only in the RSA folder for private keys, which is why the RSA folder should never be moved or renamed .

As an additional security measure, certificates and private keys should be exported to a floppy disk or other removable media and stored securely. Private keys for recovery agents should be removed from the system. If the system crashes, the private key can be recovered. It also prevents recovery of the private key on a system that is stolen, as could be the case with a laptop.

Certificate Enrollment and Renewal

To encrypt files, EFS requires a certificate. EFS will use your current EFS certificate to encrypt files. If one is not available, EFS will search your personal store for an appropriate certificate. If one still cannot be located, EFS will enroll you for an EFS certificate with an online Windows Server 2003 CA that supports EFS templates. If EFS still cannot get a certificate for you, it will create a self-signed certificate. A self-signed certificate will also be used if you are logged in on an account that is not a domain account.

When a certificate expires , EFS performs a renewal by enrolling for a new certificate with a new key pair. EFS does not renew the current certificate, it enrolls your account for a new certificate. If you renew the EFS certificate and archive the old one (we ll discuss the importance of archiving certificates and private keys later in this chapter), EFS will continue to use the old certificate until its expiration date. When looking for a new certificate, EFS can grab a certificate that is different from the one you acquired through renewal if more than one EFS certificate exists in your personal store. After EFS begins using the new certificate, it can still be used to decrypt files encrypted with your previous certificate. EFS regenerates the metadata (file header) to use the new certificate.

Another note about EFS certificates is that EFS does not perform any revocation checking as is done with other types of certificates. This is one reason it is recommended you also use Certificate Services in Windows Server 2003, which does provide revocation checking. Revocation checking is an important security task that checks to see if the certificate is still valid. Typically, the authority that issues the certificate maintains a certificate revocation list (CRL). If a certificate is revoked and is on the revocation list, it is no longer valid. This can occur when the certificate s subject (user, computer, etc.) has a compromised (lost or stolen) private key, if it is discovered the certificate was obtained fraudulently, or when there is a change to the status of the certificate subject (such as an employee being terminated ). Clearly, then, maintaining a CRL can be an important enhancement to security. Since EFS certificates are not checked for revocation, it s more secure to have EFS request and obtain a certificate from a CA that to maintain a revocation list. However, when this is not an option, EFS will use a self-signed certificate. This certificate will not be checked for revocation and could pose a security risk.

Using cipher.exe

cipher.exe is a command-line utility that can be used to display or alter encryption on folders and files in the NTFS file system. If it is used without any switches, the cipher command will display the encryption state of the current folder and all files within the folder. A number of switches can be used with the cipher command, as summarized in Table 9.7. We ll go through a few of the commands, including the /r to generate a new recovery agent, which is used in a later exercise. The syntax for the cipher command is:

  cipher  [{  /e   /d  }][  /s  :  Folder  ][  /a  ][  /i  ][  /f  ][  /q  ][  /h  ][  /k  ][  /u  [  /n  ]][{  PathName  []]  [  /r  :  PathNameWithoutExtension   /w  :  PathName   /x  :[  PathName  ]  PathNameWithoutExtension  }] 
Table 9.7: cipher.exe Command-Line Switches

Cipher Switch and Parameters

Description and Use

/e

Encrypts specified folders. This will cause files added to the folder to be encrypted as well.

/d

Decrypts specified folders.

/s: Folder

Performs selected operation in the specified folder and all subfolders .

/a

Performs the operation for files and directories.

/i

Continues performing specified operation even after errors occur. By default, cipher stops when errors occur.

/f

Forces encryption or decryption of all specified objects. By default, cipher skips files that have been encrypted or decrypted already.

/q

Reports only the most essential information (quiet mode).

/h

Displays files with hidden or system attributes. By default, these files are not encrypted or decrypted.

/k

Creates a new file encryption key for the user running cipher . If this option is used, all other options are disregarded.

/u

Updates the user s file encryption key or recovery agent s key to the current ones in all of the encrypted files on local drives. This option only works with /n .

/n

This option only works with the /u switch. It prevents keys from being updated and this option can be used to find all the encrypted files on local drives.

PathName

This variable specifies the pattern, file, or folder in the various switches.

/r: PathNameWithoutExtensions

If you use this option, all other options for the cipher command are ignored. This switch generates a new recovery agent certificate and private key and then writes them to a filename specified in the PathNameWithoutExtensions .

/w: PathName

If you use this option, all other options for the cipher command are ignored. This switch removes data on unused portions of a volume. The PathName option can be use to indicate any directory on the desired volume.

/x: [PathName]
PathNameWithoutExtension

If you use this option, all other options for the cipher command are ignored. This switch identifies the certificates and private keys used by EFS for the currently logged on user and backs the certificates and private keys up to a file. If PathName is specified, the certificate and private key used to encrypt the file specified are backed up. Otherwise, the user s current EFS certificate and keys are backed up. Certificates and private keys are written to a file specified by the PathNameWithoutExtension parameter.

/?

Displays help at the command prompt.

Figures 9.28 and 9.29 show the command-line options and syntax (in two screens). One common use for the cipher command is to generate an EFS recovery agent key and certificate, using the /R switch. The command to create a recovery agent key and certificate is:

 cipher /R:salesdra 

In this case, the file name is salesdra (Sales Data Recovery Agent), which might be used for all sales users, for example. The file will be written as salesdra.pfx, which contains both the certificate and the private key, and salesdra.cer, which contains only the certificate. An administrator can then add the contents of the .CER file to the EFS recovery policy to create the recovery agent for users. The administrator can also import the .PFX file (both key and certificate) to recover individual files. Figure 9.30 shows the process of creating a recovery agent via the cipher.exe command. Notice that you ll be prompted to create a password for the .PFX file.

click to expand
Figure 9.28: cipher.exe Commands, Part 1
click to expand
Figure 9.29: cipher.exe Commands, Part 2

Once you ve created the .PFX and .CER files, you can list the directory contents ( dir command) and you should see salesdra.pfx and salesdra.cer in the directory.

click to expand
Figure 9.30: cipher.exe /R to Create Recovery Agent Key and Certificate
start sidebar
Head of the Class
Anatomy of an Encrypted File

Understanding the structure of an encrypted file will not specifically be covered on the exam. However, understanding this structure will help you when answering questions about EFS and recovery agents on the exam.

An encrypted file has three key parts , shown in Figure 9.31. These are the Data Decryption Fields (DDF), Data Recovery Fields (DRF), and the encrypted file data itself.

click to expand
Figure 9.31: Structure of an Encrypted File

Earlier, we discussed sharing an encrypted file, and Exercise 9.04 stepped you through setting up additional users on an encrypted file. As you can see from the file structure, the encrypted file stores each authorized user s public key encrypted in the FEK in the Data Decryption Field (DDF). An encrypted file s header will contain a unique DDF for each authorized user. This is how multiple users can share an encrypted file in Windows Server 2003. The header will always contain at least one DDF when the owner encrypts the file.

The header also contains Data Recovery Fields (DRFs) if the computer s security policy designates one or more data recovery agents (DRAs). If so, copies of the FEK are encrypted for each DRA using the DRA s public key. There will be as many DRFs as there are DRAs for each encrypted file.

Looking at the structure of an encrypted file shows how multiple users can access a file and how the data recovery agent can recover a file since all of this data is stored in the header of each encrypted file. While it seems like a lot of work for each file, using both symmetric and asymmetric keys in the process, files can be encrypted and decrypted quickly and transparently for users.

end sidebar
 

Objective 4.2.1: Creating a Strategy for the Encryption and Decryption of Files and Folders

An encryption strategy for files and folders includes an assessment of vital data, an assessment of the environment, policies for using EFS, and procedures for recovering encrypted files. Obviously, not all files are sensitive enough to warrant encryption. In most cases, files protected with two layers of security ”user authentication and ACLs ”will be safe. However, files that contain sensitive data such as social security numbers , credit card data, medical or health data, or corporate trade secrets (to name just a few) should be protected with EFS.

Increasing User Awareness

There are two aspects to user awareness: identifying sensitive files and using EFS appropriately. As an IT administrator, there s a good chance you (or your department) are not fully aware of which files are most sensitive for various departments. Each department should identify which files or types of files are most sensitive. This is a good opportunity for you to educate users on what EFS is and what its capabilities are (and are not). Then, users can make intelligent decisions about which folders and files should be encrypted and how they can best manage EFS files. These steps are delineated here:

  1. After sensitive data has been identified and encrypted folders have been created, sensitive files should be copied into the encrypted folders. Copying unencrypted files into encrypted folders will encrypt the files. The earlier unencrypted files should be deleted. New files should be created within the encrypted folder so they are encrypted by default.

  2. Users should understand that files moved to a non-NTFS volume will be unencrypted.

  3. Users might think that because they can read, modify, and save files that they are not encrypted. Explain to users that encryption is transparent to them, but that sensitive files should still be handled according to the guidelines established.

  4. Users should also understand that although individual files can be encrypted and decrypted (via the file s Properties dialog), it is highly recommended that folders be encrypted and that sensitive files be created and stored in encrypted folders.

  5. Users should clearly understand that encrypted files are not protected when transmitted across the network or Internet. Additional security such as SSL or IPSec should be used to transmit highly sensitive files. The IT administrator should work with users to determine how files are used and set up additional security for files that will travel across the network.

  6. Users should export their EFS certificates and private keys to removable media and store the media securely. Private keys should not be removed from computers because users will be unable to decrypt any files without importing the private key. The most common problem with EFS is that users lose access to their private key in their user profile.

  7. Encrypt user s My Documents folder. This is the default storage location for many user files (including Microsoft Office documents), and encrypting this folder will make sure that user files are properly encrypted without the user having to take any extraordinary steps.

  8. For users of stand-alone computers, use password reset disks in Windows XP so that if they forget their passwords, they can reset their password and recover the master key for the stand-alone computer. Without it, the user might be unable to access the system to import their EFS certificate and/or private key.

    Test Day Tip  

    Remember that EFS is not used to encrypt data traveling across the network, it does not authenticate users, it cannot be used to secure dial-in or VPN connections, and it cannot encrypt data on computers running other non-Windows operating systems.

There are additional steps you as the IT administrator should take to ensure EFS is security implemented within your organization. It s vital that you establish a safe, consistent, and methodical approach toward securing recovery agent certificates. Safely storing and archiving recovery agent credentials will ensure that you re always able to decrypt important files even after you ve changed recovery agents. Files that might sit dormant for some time might need to be decrypted long after the file s owner leaves the company, so archiving is a critical step. The steps you should take to manage EFS throughout the organization are:

  1. Export private keys for recovery accounts on secure media, stored in a safe place. Then, remove the private keys from the computers This prevents a user from using the recovery account to decrypt others files. This is particularly important for stand-alone computers where the recovery account is typically the Administrator account. For a laptop, this makes sense because if the machine lost or stolen, the data cannot be recovered without the recovery account keys. If the private keys have been removed from the system, they will not be available as a potential security liability.

  2. Only use the recovery agent account for file recovery. This keeps the credentials secure by limiting their use.

  3. Work with users of stand-alone systems to make sure their systems remain safe. The requirements for stand-alone systems are slightly different than for computers joined to the domain. Stand-alone systems should create password reset disk and configure Syskey for startup key protection for the EFS users private keys.

  4. Change the default recovery agent account as soon as possible. By default, the Administrator of the first DC installed for the domain is the default recovery agent account. Set a password for each recovery agent account. Set auditing for the use of the recovery agent account to monitor use of this account.

  5. Export each private key associated with recovery certificates into a .PFX file, protect it with a strong password, move it to secure removable media, and store it securely.

  6. Do not destroy recovery certificates and private keys when recovery agent policy changes (or expires). Keep them archived until you are absolutely certain all files protected with them have been updated with new recovery agent credentials.

  7. Create a recovery agent archive program to ensure files can be recovered via obsolete recovery keys. Export keys and store them in an access-controlled vault. Create a master and backup archive and store the backup archive securely offsite.

  8. Designate two or more recovery agent accounts per OU. Designate one computer for each designated recovery agent account and grant appropriate permissions to the administrators to use the recovery agent accounts.

  9. Never move or rename the RSA folder. The RSA folder is the only place EFS looks for private keys. (RSA stands for Rivest, Shamir, and Adelman, the inventors of a widely used encryption algorithm bearing the same name.)

In addition to implementing these practices both on users computers and for the organization as a whole, you ll need to understand and manage recovery agents, since the most common problem with EFS is lost or inaccessible user credentials.

Configuring File Recovery Agents

Data recovery is important when employees leave the company or lose their private keys. If you ever lose your file encryption certificate and your private key through disk failure or some other reason, the designated recovery agent can recover the data. This is why it s critical to export, save, and archive recovery agent credentials. This also provides the ability for a company to recover an employee s data after he or she has left the company.

EFS recovery policy specifies the data recovery agent accounts to be within the scope of the policy (OU, domain, site, local computer). EFS requires an Encrypted Data Recovery Agent policy be defined before it can be used. If none has been chosen , EFS will use a default recovery agent account. Within the scope of a domain, only the Domain Admins group can designate an account as the recovery agent account. Where there is no domain, the local Administrator account is the default data recovery agent.

In Exercise 9.06, we ll step through adding a recovery agent for the local computer.

Exercise 9.06: Add a Recovery Agent for the Local Computer
start example

In this exercise, we ll add a recovery agent for the local computer.

  1. Click Start Run , type mmc in the Open: text box, and then click OK .

  2. On the File menu, select Add/Remove Snap-in , and then click Add .

  3. In the Add Standalone Snap-in dialog, scroll down until you locate Group Policy Object Editor and then click Add .

  4. In the Select Group Policy Object screen, verify that Local Computer is the selected Group Policy Object and then click Finish .

  5. Click Close to close the Add Standalone Snap-in dialog, then click OK to close the Add/Remove Snap-in dialog and return to the MMC.

  6. In the left pane, click the + to expand the Local Computer Policy node.

  7. Click to expand the following nodes, in order: Computer Configuration Windows Settings Security Settings Public Key Settings .

  8. Right-click Encrypting File System to select it and then select Properties , as shown in Figure 9.32.

    click to expand
    Figure 9.32: Encrypting File System Properties Dialog

  9. To disable EFS on this computer, clear the check box labeled Allow users to encrypt files using Encrypting File System (EFS). To enable EFS, this check box must be selected.

  10. Click OK or Cancel to close the Properties dialog. Right-click the Encrypting File System node in the left pane and select Add Data Recovery Agent . This will launch the Add Recovery Agent Wizard . You ll need to provide the username for a user that has a published recovery certificate. You can also browse for .CER files that contain information about the recovery agent you re adding.

  11. Click Next to access the Select Recovery Agents screen in the wizard. You can browse directories or folders, as shown in Figure 9.33. Once you ve selected the users, click Next .

    click to expand
    Figure 9.33: Select Recovery Agents Dialog

  12. The final screen shows the users you ve added and the certificates used. Click Finish to close the wizard. The users you ve added should now be displayed in the right pane of the MMC.

end example
 

If you don t have certificates installed and you re working on a stand-alone system as the Administrator, you can complete this exercise by using the cipher command to create a certificate and private keys and then point the wizard to these files. These steps are described briefly in Exercise 9.07.

Exercise 9.07: Using the cipher Command to Add Data Recovery Agent
start example
  1. Click Start Run , type cmd , and then click OK .

  2. Type this command at the prompt and then press Enter to execute the command:

     cipher /r:testdra 
    Note  

    If you do not specify a filename when using the cipher /r: command, files named . CER and .PFX will be created ( essentially , no filename, just the extension). Instead, use a filename such as the testdra we used earlier. Once you ve added the DRA to the EFS policy, you can right-click on the DRA and edit the properties, such as giving it a user-friendly name and a description.

  3. When prompted, enter a password and then re-enter the password to verify the password. You ll be notified that the .PFX and .CER files have been created. Make a note of the folder in which they reside so you can easily browse to them. This was shown in Figure 9.30 earlier in this chapter.

  4. Next, follow steps 1 through 11 in the previous exercise, Exercise 9.06, to access the Add Data Recovery Agent Wizard. When prompted to select recovery agents (Exercise 9.06, step 11), browse to the location of the .CER file. By default, this file resides in the path in which it was created. If you look at Figure 9.30, you ll see it should be located in C:\Documents and Settings\Administrator . If another path was selected, the .CER file resides in that alternate path. As shown in Figure 9.34, when you locate the .CER file, click to select it, and then click Open .

    click to expand
    Figure 9.34: Importing Certificate for Recovery Agent

  5. If the certificate was created by EFS, you will receive a notice that Windows cannot determine if the certificate has been revoked. (Recall that we discussed that EFS does not maintain certificate revocation lists.) This warning is shown in Figure 9.35. Click Yes to accept or No to reject. Click Yes to display the final screen of the wizard, which shows the user and certificate you ve selected. Click Finish to close the Add Recovery Agent Wizard and return to the MMC.

    click to expand
    Figure 9.35: Windows Warning Regarding Certificate Status

end example
 

Adding recovery agents for the domain uses a similar process. Instead of selecting the Local Computer as the Group Policy Object (step 4 in the preceding exercise), you would select the GPO for which you want to establish the recovery agent (OU, domain, etc.). Figure 9.36 shows this node in the Default Domain Policy. Always back up recovery keys to floppy disk before making any changes. In a domain, the default recovery policy is implemented for the domain when the first controller is set up. The first domain administrator is issued a self-signed certificate used to designate the domain admin as the recovery agent. To change this default recovery policy for the domain, log on to the first DC as Administrator. If you want to add a recovery agent, you can use the steps outlined in the preceding exercise to Add Data Recovery Agents. However, the DC will contact a Windows Server 2003 CA to request a certificate. The certificate is based on the EFS Recovery Agent certificate template. If this template is not available or if you cannot obtain a certificate, you will receive an error and will be unable to add recovery agents.

click to expand
Figure 9.36: Default Domain Policy Encrypting File System Node

In addition to creating recovery agents, you can configure a GPO so that it does not require a recovery agent. You can configure this for any OUs, domains, or sites in the Active Directory forest to allow you to use EFS without a recovery agent. You will be unable to configure the GPO in this manner if you have an EFS policy defined. If so, you must delete the policy first. In the MMC with the Group Policy Object editor open, if you select Encrypting File System in the left pane, click Action on the menu, and select All Tasks , you ll have an additional option of Do Not Require Data Recover Agents . If this option is not available, you have not deleted the existing EFS policy.

Removing Recovery Agent Policy

It is possible that a company might implement a data recovery policy and later decide to remove or eliminate that policy. When a recovery policy is removed from a domain, it is no longer applied via group policy. In Windows 2000, once the group policy has been updated, no new files can be encrypted. In Windows XP and Windows Server 2003, computers will not be impacted. Encrypted files can still be opened, but they cannot be re-encrypted. Existing encrypted files remain encrypted until they are accessed or updated by a user who has a private key to decrypt those files.

Recovering Files

Files can be recovered in one of several ways. A file that has been saved via the Backup tool (or another backup utility) can be restored to the user s machine (or previous location), and the user s credentials can then decrypt the file. Files backed up using the Windows Backup tool will remain encrypted on the backup media and will remain encrypted when restored from the backups. If a user s certificate is lost or destroyed , the encrypted file can be sent to the designated recovery agent, and the recovery agent can decrypt the file and transfer it back to the desired location. Remember that the transmitted file will not be encrypted, so use a secure transfer method or deliver the file to the recovery agent on removable media. Conversely, you can import the recovery agent credentials to the location of the encrypted file for decryption and file recovery. Once the file is recovered, the recovery agent credentials should be removed from the computer for security. The file and the credentials must both be on the same computer to recover the file, regardless of whether this occurs on a designated secure workstation or on the user s computer.

Exam Warning  

You are practically guaranteed to encounter one or more questions that involve the use of certificates in one form or another. It s likely that if you see an EFS-related question on the exam it will involve the loss of private keys or certificates and the recovery of encrypted files. Make sure you re comfortable with the concepts of EFS and data recovery for the exam.

Backing Up Keys

Certificates can be backed up with or without private keys. This is accomplished via the Certificates snap-in in the MMC. It s suggested you back up certificates with private keys to a floppy disk or other secure removable media and store this media in a secure location. For stand-alone computers or for mobile computers such as laptops, you should remove the private keys from the system and store them in a secure location. In the following exercise, we ll step through backing up certificates with private keys and you ll see how to remove the private key during this process.

Exercise 9.08: Backing Up Certificates with Private Keys
start example

In this exercise, we ll use the Certificates snap-in in the MMC to export a certificate with private keys to a floppy disk. You ll also see how to remove private keys during the export process, if desired.

  1. Click Start Run , type mmc in the Open text box, and then click OK .

  2. In the MMC, click File Add/Remove Snap-in . Then, in the Add/Remove Snap-in dialog, click Add .

  3. In the Add Standalone Snap-in dialog, scroll down to locate Certificates . Select Certificates and then click Add .

  4. In the Certificates Snap-in dialog, select My User Account (selected by default) and then click Finish .

  5. Click Close to close the Add Standalone Snap-in dialog. Then, click OK to close the Add/Remove Snap-in dialog and return to the MMC.

  6. Click the + to the left of Certificates “ Current User to expand the node. Click the + to expand the Personal node beneath . Click Certificates to select this node.

  7. Click the certificate that displays the words File Recovery , as shown in Figure 9.37.

    click to expand
    Figure 9.37: Key Backup from Microsoft Management Console

  8. Right-click the certificate, select All Tasks , and then select Export . (Notice that you can also request and renew certificates here.)

  9. The Certificate Export Wizard is launched; click Next .

  10. In the Export Private Key dialog, you can export the certificate with or without the private key. The private key is password protected, so if you select this option, you ll be prompted for a password in a subsequent screen. Select whichever option you want to use (in this example, we ve selected Yes, export the private key ) and then click Next .

  11. The next screen Export File Format provides several options. If you selected No in the previous screen, this screen will enable the first set of options as shown in Figure 9.38. If you selected Yes in the previous screen, this screen will enable the second set of options, shown in Figure 9.39.

    click to expand
    Figure 9.38: Export File Format for Certificate Only (Excludes Private Key)

    click to expand
    Figure 9.39: Export File Format Including Private Key with Certificate

  12. If you have more than one certificate in the path and want to export all certificates, select the check box labeled Include all certificate in the certificate path if possible .

  13. The second check box in this section (shown in Figure 9.19), Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) , is selected by default. If you are using Windows NT 4.0 or earlier, you cannot use strong protection.

  14. The third check box, Delete the private key if the export is successful , can be selected if you want to delete the private key. The key will only be deleted if the export is successful. Alternately, you can delete the key manually after verifying the successful export. Click Next to proceed.

  15. The next screen requires a password if you chose to export the certificate with the private key. Enter your password twice and then click Next .

  16. The next screen, File to Export , asks you to specify the file name or to Browse to a location to which you want to export. Often, this location is a floppy disk or other removable media. Click Browse and locate the removable media to which you want to export the certificate. (For this exercise, we called the file backupdra and exported to the local drive.) Click Next to continue.

  17. The final screen in the wizard is the Completing the Certificate Export Wizard screen shown in Figure 9.40. This screen verifies the selections you ve made and gives you the opportunity to make modifications if any of the settings are not as you want. To make modifications, click Back . If all settings meet your requirements, click Finish .

    click to expand
    Figure 9.40: Certificate Export Wizard Successful Completion

  18. If the export is successful, you ll get a notification dialog, shown in Figure 9.41. This indicates the file was successfully exported to the location you specified with the settings you selected. If you selected the option to Delete the private key if the export is successful , your private key has also been deleted. The wizard will close and you ll return to the MMC.

    click to expand
    Figure 9.41: Export Successful Notice

end example
 

You can use the same steps to import a certificate. In the MMC Certificates snap-in, you would select Personal Certificates , right-click on Certificates (or select Certificates and then click Action on the menu), and select Import and follow the instructions in the Certificate Import Wizard .

start sidebar
Designing & Planning
Printing Encrypted Files

One of the places security can be weak is in the area of printing. When a file is encrypted with EFS, it is automatically and transparently decrypted and displayed on the user s monitor. That file can then be printed to a local or network printer. If the data is particularly sensitive, this can create a security hole. If your users will require the ability to print sensitive documents that are stored in an encrypted state, you should consider setting up a more secure printing environment.

When a user uses the Print function, the document is copied into a spool (.spl) file that resides on the local print provider (local computer or print server). By default, these spool files are stored in the following location:

  Systemroot  \System32\Spool\Printers 

By default (and by design), that folder is unencrypted. This makes sense because you don t necessarily need every single print spool file to be encrypted, just those for sensitive documents. If you were to encrypt this folder, the process of encrypting and decrypting spool files would slow the printing process significantly and unnecessarily.

Instead, create a separate printer to be used for encrypted files. This defined printer ideally should be a local printer that is not shared to avoid the all-too-common print and sprint problem where users print to a shared printer and sprint down the hall to grab the document before someone sees the sensitive information. The defined printer can use the same hardware (same actual printer) as the regular printer, but the definition of this secure printer will be slightly different.

Once you ve used the Add a Printer Wizard and added the appropriate printer and associated driver, right-click the printer and select Properties . You can click the Advanced tab and select the Print directly to the printer option button, as shown in Figure 9.42. You ll notice that most of the other options are disabled when you make this selection. By sending print jobs directly to the printer, a spool file is not created. This is one way you can improve security when printing EFS protected files. The downside to this method is that print jobs cannot be prioritized or scheduled.

click to expand
Figure 9.42: Create Secure Printer

Alternately, you can create an encrypted folder and direct the print spool function for that printer to this encrypted folder. The result will be that all files spooled from the designated secure printer will be encrypted until printed. By default, spooled files are deleted after the print job is complete, so the temporary file will be encrypted and then deleted for maximum security.

To change the location of the spool folder for a specific printer , you must use the Registry Editor. As you know, editing the Registry directly can cause serious and unexpected consequences that render your system unstable or unusable. Be sure to update your Automated System Recovery set prior to making changes to the Registry. Assuming you ve taken appropriate safeguards, you can change the location of the print spool folder for a specific printer by taking the following steps:

  1. Create a spool folder on the local computer.

  2. Launch the Registry Editor by clicking Start Run and then type regedt32 in the Open: text box. Click OK .

  3. Locate the following key:

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ 
Print\Printers\< printername >
  1. Locate the SpoolDirectory , which has a data type of REG_SZ. This is shown in Figure 9.43.

    click to expand
    Figure 9.43: SpoolDirectory in Registry

  2. Double-click SpoolDirectory or right-click and choose Modify .

  3. Change the Value: to the path to the new folder. For example, the path might be c:\windows\secureprintspool.

  4. Close the Registry Editor and reboot to make the change go into effect.

  5. The printer named in the Registry key should now send spool files to the desired folder.

  6. Locate the new spool folder and enable encryption on the folder by right-clicking the folder, clicking the Advanced button, and selecting Encrypt contents to secure data . Click OK to close the Advanced Attributes dialog, and click OK to close the print spool folder Properties dialog.

It s important to note that if you forget to create the new secure spool folder and you specify a path in the Registry SpoolDirectory entry for the specified printer, the files will spool to the default spool folder, which will not be encrypted and will not protect files during the print process. Also note that you can make changes to the location of the printer spool folder for all printers via the Server properties in Printers and Faxes Properties (on the Advanced tab of the Print Server Properties). This will affect all printers unless you have specifically created a new spool folder via the Registry, as we just did.

By specifying a separate print spool folder, encrypting it, and sending secure documents to the secure printer, you can ensure that sensitive files that are encrypted by EFS will be secured during the printing process. Of course, securing the paper copy of the document is another challenge that s outside the scope of this chapter and often outside the control of the IT department.

end sidebar
 

Disabling EFS

You can disable EFS for a computer or for the entire domain via the EFS policy just discussed. If you want to disable it for the local computer, verify that Local Computer is selected as the GPO (step 4s and 9 in the preceding exercise). If you want to disable it for the domain, select the domain as the GPO and clear the check box (again, steps 4 and 9).

You can also disable EFS via the Registry. As always, it is recommended that you always try to use the user interface to make changes to the system rather than accessing the Registry directly. Incorrectly editing the Registry, as you know, can make a system unusable. As a best practice, it s always wise to update your Automated System Recovery (ASR) floppy disk before modifying the Registry.

However, if you choose this method, you can use these steps to modify the Registry to disable EFS on the local computer.

  1. Click Start Run , type regedt32 , and then click OK .

  2. Locate the following Registry key by expanding the nodes in the left pane:

     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\EFS 
  3. With the EFS node selected, click Edit on the menu, select New , and then select DWORD Value .

  4. Type efsconfiguration in the Value name box and then press Enter .

  5. Double-click the EfsConfiguration Registry key you just created and type the number 1 in the Value Data box.

  6. Click OK to accept the change, and then close the Registry Editor by selecting File Close .

Third-Party Encryption Options

You can use a third-party data encryption program, and within Windows Server 2003, you can use third-party certificates with EFS. There are numerous third-party data encryption software programs on the market that can be used instead of EFS. There are pros and cons to implementing third-party software, which you ll need to evaluate for your organization. For example, EFS works fine in a native Windows environment, but if you have a network of mixed operating systems, you might run into interoperability issues. There are operating system-independent solutions available as well, and these might make sense if you are running a mixed network. However, many third-party options use password-based recovery systems, which can leave them vulnerable to attack. EFS uses cryptography instead of password-based access, making it far more secure. Many third-party options also require user intervention ”the user must take an action to cause a file to be encrypted or decrypted. This also creates a security hole when users don t want to take the time or don t understand exactly how to encrypt/decrypt files. If you choose to implement a third-party solution, you might use the option in Windows Server 2003 to disable EFS to avoid conflicts.

The benefits to using EFS in a Windows environment is that it is fully integrated into the operating system and can rely on the security structure already in place. It uses keys and certificates to keep data safe, which is a more secure solution that relying on passwords. It also is completely transparent to the user once an encrypted folder has been set up. The user simply opens, edits, and closes the file, and the encryption/decryption is handled automatically.

Although you can implement third-party solutions, make sure you ve thoroughly researched the cost, the impact on users, and the relative security of the solution and compared it to the features of EFS.

Third-Party Certificates

Once EFS chooses a certificate, it cannot be modified via the user interface but can be modified in the Registry. Moreover, EFS dos not automatically switch certificates if another one becomes available. Such would be the case when EFS uses a self-signed certificate and later is able to connect to a CA. If you want to use a third-party certificate, you can install it via the Certificates snap-in in the MMC. The specified certificate can be used for a user account, service account, or computer account. Once the account is specified in the Certificates snap-in, you can import a third-party certificate.




MCSE Designing Security for a Windows Server 2003 Network. Exam 70-298
MCSE Designing Security for a Windows Server 2003 Network: Exam 70-298
ISBN: 1932266550
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net