In many businesses, users share desktop computers. Some users travel with portable computers that they use outside the physical protection of the business, in customer facilities, airports, hotels, and at home. This means that valuable data is often beyond the control of the business. An unauthorized user might try to read data stored on a desktop computer. A portable computer can be stolen. In all of these scenarios, malevolent parties can gain access to sensitive company data.
One solution to help reduce the potential for stolen data is to encrypt sensitive files by using Encrypting File System (EFS) to increase the security of your data. Encryption is the application of a mathematical algorithm to make data unreadable except to those users who have the required key. EFS is a Microsoft technology that lets you encrypt data on your computer, and control who can decrypt, or recover, the data. When files are encrypted, user data cannot be read even if an attacker has physical access to the computer's data storage. To use EFS, all users must have Encrypting File System certificates-digital documents that allow their holders to encrypt and decrypt data using EFS. EFS users must also have NTFS permission to modify the files.
Two types of certificates play a role in EFS:
| • | Encrypting File System certificates. This type of certificate allows the holder to use EFS to encrypt and decrypt data, and is often called simply an EFS certificate. Ordinary EFS users get this type of certificate. The Enhanced Key Usage field for this type of certificate (visible in the Certificates Microsoft Management Console snap-in) has the value Encrypting File System (1.3.6.1.4.1.311.10.3.4). |
| • | File Recovery certificates. This type of certificate allows the holder to recover encrypted files and folders throughout a domain or other scope, no matter who encrypted them. Only domain admins or very trusted designated persons called data recovery agents should get this. The Enhanced Key Usage field for this type of certificate (visible in the Certificates Microsoft Management Console snap-in) has the value File Recovery (1.3.6.1.4.1.311.10.3.4.1). These are often called EFS DRA certificates. |
To enable another authorized person to read your encrypted data, you can give them your private key, or you can make them a data recovery agent. A data recovery agent can decrypt all EFS-encrypted files in the domain or organizational unit in his or her scope. This document provides step-by-step instructions for the main EFS-related tasks in a small-to-medium business, and also lists several important best practices for using EFS.
The procedures in this document guide you through the following tasks:
| • | Create and safeguard a recovery key to ensure that encrypted data can be safely recovered when the original user cannot do so. |
| • | Create recovery agents who can recover encrypted files when the original user cannot do so. |
| • | Set up EFS in your business. |
| • | Configure Windows Explorer to conveniently use EFS. |
| • | Configure file sharing to work with EFS. |
| • | Export and import data recovery keys to enable the safe recovery of encrypted files and folders. |
| • | Recover data when the original user cannot do so. |
By following the procedures in this document, you will make the following system-wide changes:
| • | Create a backup data recovery key. |
| • | Create a recovery agent. |
| • | Enable EFS for encrypting data on a computer hard drive. |
| • | Configure Windows Explorer to include EFS options. |
These procedures also enable you to implement the following changes or precautions:
| • | Provide shared access to selected encrypted data. |
| • | Manage data recovery keys for use in recovering encrypted data. |
| • | Recover encrypted data when necessary. |
The procedures in this document help you configure your computers to use EFS and illustrate how to use EFS to protect data on the computer hard drives in your business. Before you begin to carry out these procedures, you should work with your legal counsel to ensure that your planned encryption policies and procedures adhere to relevant legal laws and regulations. In particular, if your organization has offices outside the United States, you need to be familiar with export control laws related to encryption software. You should also be familiar with some basic requirements and conditions for using EFS:
| • | You can encrypt files and folders only on NTFS file system volumes. Consequently, you cannot use EFS to protect data on hard drives that use the FAT or FAT32 file system. Unless you have a specific reason to continue using the FAT file system, it is recommended that you convert these volumes to use NTFS. The Windows 95, Windows 98, and Windows Millennium Edition operating systems do not support NTFS or EFS. Windows XP Home Edition supports NTFS, but not EFS. | ||||||
| • | Files or folders that are compressed cannot also be encrypted. If you encrypt a compressed file or folder, that file or folder will be uncompressed. | ||||||
| • | Files marked with the System attribute cannot be encrypted, nor can you encrypt files in the systemroot folder. | ||||||
| • | Options that you select from a pop-up dialog box when you first encrypt files or folders determine how encryption operates in the future:
|
Unless otherwise specified, in the procedures described in this document, server computers are running the Windows Server 2003 operating system, and client computers are running Windows XP Professional.
In an Active Directory environment, users are assumed to have roaming user profiles. Please note that screenshots in this document reflect a test environment and the information might differ from the information displayed on your computer.
All of the step-by-step instructions in this document were developed using the Start menu that appears by default when you install your operating system. If you have modified your Start menu, the steps might differ slightly.
Not having a backed-up recovery key can result in irrevocable loss of encrypted data. Backing up a recovery key helps ensure that encrypted data can be recovered in the event that the user holding the EFS encryption certificate is not able to decrypt the data.
| • | Credentials: This operation must be performed using the recovery agent account that has the file recovery certificate and private key in its private store. The domain administrator is the default recovery agent; in a home or non-domain environment, there is no default recovery agent, but you can create a local recovery agent for all accounts on the computer. It is more common in a home setting for each EFS certificate holder to back up their own private keys. |
| • | Tools: Certificates snap-in to the Microsoft Management Console (MMC). |
CAUTION: Before making any changes to the default recovery policy, be sure to back up the default recovery keys. The default recovery keys in a domain are stored on the first domain controller for the domain.
| • | To back up default recovery keys to a floppy disk
|
To allow an account to read or recover data encrypted by using EFS, you must make the account a recovery agent. In a domain environment, it is advisable to use domain accounts for that purpose. You can create a recovery agent for any site, domain, or organizational unit in an Active Directory directory service forest. By default, the built-in Administrator account for a domain is a recovery agent; in that case you do not need to create a recovery agent.
| • | Credentials: Administrator of the domain. |
| • | Tools: the Active Directory Users and Computers snap-in to MMC. |
| • | To create a domain-based recovery agent
|
In a non-domain environment, such as on a standalone computer or in a workgroup, you can create a local recovery agent. Creating a local recovery agent might be helpful if the computer is shared by multiple users. On a single-user computer, it is easier for the user to simply back up the recovery key to a removable media.
| • | Credentials: Administrator of the local computer. |
| • | Tools: Group Policy Object Editor. |
| • | To create a local recovery agent
|
Once you have finished creating a recovery agent and have generated and backed up a recovery key, you are ready to begin using EFS to help protect files and folders from unauthorized access. This section provides instructions on enabling EFS.
| • | Credentials: You must be a user with an EFS certificate and NTFS permission to modify the file or folder. |
| • | Tools: Windows Explorer. |
| • | To encrypt a file or folder by using EFS
|
Some businesses might find it easier to implement EFS by configuring Windows Explorer to display "Encrypt" and "Decrypt" on the shortcut menu when a user right-clicks a file. To enable this, you need to edit the Windows registry to create a new registry value which does not exist by default.
CAUTION: Incorrectly editing the registry might severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
| • | Credentials: An administrator with experience editing the registry and an understanding of the dangers of editing the registry. |
| • | Tools: the Registry Editor. |
| • | To enable Encrypt/Decrypt options on the Windows Explorer menu
|
Note: In Windows Server 2003, you can also add the Encryption Details button to the Explorer menu by creating a registry batch file (*.reg) with the following information and running the registry batch file for each user:
[HKEY_CLASSES_ROOT\*\Shell\Encrypt To User...\Command]
@="rundll32 efsadu.dll,AddUserToObject %1"
Businesses commonly want to use encryption to help safeguard sensitive data, but also need to allow multiple users access to that data. With EFS, one user can encrypt a file, and then give additional users the ability to access the encrypted data. To allow several users to access an encrypted file, the user who encrypts the file designates the file as shared, and then enables shared access by adding the EFS encryption certificates of each additional user to the encrypted file. In this way, businesses can help improve security without impairing the availability of data.
You should be aware of certain requirements and limitations related to sharing encrypted data:
| • | You cannot add groups of users to encrypted files, nor can you add users to encrypted folders. |
| • | All users that are added to an encrypted file must have an EFS encryption certificate on the computer where the file is located. Typically, a certification authority such as Verisign issues certificates. Also, if a user has logged on to the computer and encrypted any file, that user will have an EFS encryption certificate on the computer. To import certificates, see To import a certificate on the Microsoft TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=22846. |
| • | All users that can decrypt the file must also have access to read the file. NTFS permissions must be set properly to allow this access. If a user is denied access because of insufficient NTFS permissions, the user cannot read the encrypted file and cannot decrypt the data. To set permissions on files, see To set, view, change, or remove permissions on files and folders on the Microsoft TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=22847. |
| • | Credentials: An EFS certificate, and ownership of the file, are required. |
| • | Tools: Windows Explorer. |
All users that are added to the file must have a certificate located on the computer.
| • | To allow a user to encrypt or decrypt a file
|
Note: When a user is added to a file and the user's EFS encryption certificate is imported, the certificate is validated to a trusted root certification authority (CA). The certificate is then stored in the Other People certificate store for that user.
Data recovery keys (DRA keys) must be available to the Data Recovery Agent to enable the Agent to recover encrypted data when normal recovery is not possible. Therefore, it is important to safeguard recovery keys. A good way to guard against loss of recovery keys is to export the Data Recovery certificates and private keys of Data Recovery Agents to securable removable media in .pfx format files. You can then recover lost data by importing them.
The following procedures outline the process for exporting and importing DRA keys.
| • | Credentials: You must be logged on with the administrator account on the first domain controller in the domain. |
| • | Tools: Certificates MMC snap-in. |
| • | To export the certificate and private key of the default domain Data Recovery Agent
|
In the event that you need to recover encrypted data by using an exported data recovery key, you will first need to import the key. Importing keys is simpler than exporting them. To import a key stored as a PKCS #12 formatted file (.pfx file), just double-click the file to open the Certificate Import Wizard, or you can start the wizard and import the key by completing the following steps:
| • | Credentials: Domain Admin account on the computer. |
| • | Tools: The Certificates MMC snap-in. |
| • | To import a data recovery key
|
IMPORTANT: A domain-based account should always be used in association with a Data Recovery Agent, because local accounts might be susceptible to physical offline attacks.
In the event that encrypted data cannot be recovered by the original user, for example, because the user has left the company, you need a way to recover the data and make it accessible to the company. This section tells how to recover an encrypted file or folder. To do so, you will use Backup or another backup tool to restore the user's encrypted file or folder to the computer where the file recovery certificate and recovery key of the Data Recovery Agent are located.
You must be a designated recovery agent to carry out this procedure. In other words, you must hold the private key and certificate for a DRA identified on the file or folder to be recovered.
| • | Credentials: Data recovery agent. |
| • | Tools: Windows Explorer. |
| • | To restore an encrypted file or folder
|
The following best practices can help a company effectively use and manage encrypted files and folders.
| • | Recovery agents should back up their file recovery certificates to a secure location. |
| • | Use the Default Domain Configuration. |
| • | Update lost or expired DRA private keys promptly. <![CDATA[ Cipher.exe /U C:\Temp\test.txt: Encryption updated. C:\My Documents\wordpad.doc: Encryption updated. ]]> Note: When using the default self-signed certificate in a domain without a certification authority, the lifetime of the certificate is 99 years. |
The following best practices can help a company protect the data of mobile users in case of theft or loss:
| • | Physical protection of the computer is paramount. There is no technological substitute for taking every precaution to ensure the computer is not stolen or physically compromised. |
| • | Always use the mobile computer as part of an Active Directory domain. |
| • | Store the private keys for users separately from the mobile computer and import them when needed. |
| • | For common storage folders such as "My Documents" and temporary folders, encrypt the folder so that all new and temporary files will be encrypted when created. |
| • | Always create new files, or copy existing plaintext files, into an encrypted folder when the data is extremely sensitive. This will ensure that all files have never existed in plaintext form on the computer, and that temporary data files cannot be recovered by using sophisticated disk analysis attacks. |
| • | Encrypted folders can be enforced in a domain by using a combination of Group Policy, logon scripts and security templates to ensure that standard folders such as "My Documents" are configured as encrypted folders. |
| • | The Windows XP operating system supports the encryption of data in offline files. Offline files and folders that are cached locally should be encrypted when using client-side caching policies. |
| • | Use the system key utility SYSKEY in mode 2 or mode 3 (boot floppy or boot password) on the mobile computer to prevent the system from being booted by malicious users. The system key utility and its options are documented in online help for your version of Windows. |
| • | Enable Server Message Block (SMB) signing in Group Policy for servers that are trusted for delegation and used for storing encrypted files. This setting is found in Group Policy at this location: GPO-name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft Network Server: Always digitally sign communications. |
| • | Ensure unencrypted data is removed from the hard drive after encryption of files and periodically thereafter. |
For more information about EFS, see the following:
| • | "Encrypting File System" on the Microsoft TechNet Web site at http://go.microsoft.com/fwlink/?LinkID=22412 |
| • | "Encrypting File System in Windows XP and Windows Server 2003" on the Microsoft TechNet Web site at http://go.microsoft.com/fwlink/?LinkID=22413 |