Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Basic Operations

Nothing has to be done to implement EFS. It's already available to any user who can select a check box. Unless EFS is disabled or a policy is implemented that denies the user this right, the user determines which of his files will be encrypted. Most users will be oblivious to the impact of doing so, other than it appears as if others cannot view their files. While users only see the result (their files appear to be impenetrable to others), IT needs to provide a structure that will ensure that files are private when they need to be and can be recovered if the user is unable to do so. The first step in developing sound administrative practices and polices for EFS is to understand EFS basic operations.

While there are no operating system restrictions on encryption of application or data files, system files cannot be encrypted. The reason is that the file system must be available before files can be decrypted, and some files are needed to boot the OS that therefore would be encrypted and unavailable.

Encrypting and Decrypting

Individual files can be encrypted one by one, or a folder can be marked for encryption, in which case every file placed in the folder is encrypted. Users may decrypt an encrypted file by modifying the file's encryption property using Windows Explorer, by using the cipher command, or by opening the file in the application used to create it. When the file's encryption property is used, users must re-encrypt the file. However, when an application is used to decrypt the file, the file is re-encrypted when the file is saved.

If a folder is marked for encryption, often called encrypting the folder, files placed or saved in the folder will be encrypted. When the user who encrypted it accesses the file, it is automatically decrypted. For example, if the user saves a Word document in the encrypted folder, the document is encrypted. When the user opens the document, it is automatically decrypted. To the user, it appears as if nothing has happened; encryption and decryption are transparent to the user.

Encryption transparency has several advantages. First, the user is not required to understand how to encrypt or decrypt files and doesn't have to do anything to accomplish it. Instead, she just does her work. Second, when a file is first saved in plain text and then later encrypted, a temporary file is made. Since the plaintext copy of the file is marked for deletion, it might be possible for someone to forensically examine the drive and recover the data. However, when a file is first stored in an encrypted folder, no plaintext copy of the file is stored.

WARNING: Deleted Plaintext Copy May Still Be Present

When ordinary files are deleted, they are not really removed from the drive. Instead, they are simply "marked for deletion" and gradually overwritten as new data is added to the drive. Forensic applications and techniques exist that can gather these "remnants," or "data shreds." To prevent data remanence (the existence of leftover shreds) from exposing sensitive data, organizations often use special utilities to overwrite data multiple times, use magnets to degauss drives before they are reused, and destroy drives rather than resell them or give them away.

To prevent encrypted file data remanence from becoming a problem, always encrypt folders, not files. However, if plaintext shreds of sensitive data may exist on a drive, or you want to be sure that there aren't any, the cipher.exe tool can be used to overwrite data marked for deletion.

Using File and Folder Properties to Encrypt and Decrypt Files

When the folder property is set to encrypt files, files are automatically encrypted when placed in the folder. However, individual files can be encrypted or decrypted by using the Advanced file properties page of the file. To encrypt a file, follow these steps:

In Windows Explorer, right-click the file and select Properties.

Click the Advanced button on the General page.

Select Encrypt contents to secure data and click OK twice.

In the Encryption Warning dialog box, as shown in Figure 6-1, do one of the following:

Figure 6-1. The warning box informs users that they can encrypt all files.

To just encrypt the file, select Encrypt the file only,

To encrypt the folder and all files in it, select Encrypt the file and the parent folder.

If you select Always encrypt only the file, the warning will not appear the next time you encrypt the file.

Click OK.

To decrypt a file:

In Windows Explorer, right-click the file and select Properties.

Click the Advanced button on the General page.

Select Encrypt contents to secure data to remove the check mark.

Click OK twice.

To encrypt a folder (to create a folder that will automatically encrypt files placed in it):

In Windows Explorer, right-click the folder and select Properties.

Click the Advanced button on the General page.

Select Encrypt to secure contents and click OK twice.

If subfolders are present, configure whether subfolders should be changed. In the Confirm Attribute Changes popup, as shown in Figure 6-2, do one of the following:

Figure 6-2. Encrypt all files in this folder and all files in all subfolders of this folder.

Select Apply changes to this folder only to only encrypt files in this folder,

Select Apply changes to this folder, subfolders and files to encrypt the files in the folder and its subfolders and files.

Click OK.

To decrypt a folder, follow these steps:

Right-click on the folder in Windows Explorer and select Properties.

Click the Advanced button.

Select the Select to encrypt to secure contents box to remove the check mark.

Click OK twice.

In the Confirm Attribute Changes popup, as shown in Figure 6-3, do one of the following:

Figure 6-3. Decrypt all the files in the folder and subfolders.

Select Apply changes to this folder only to remove the encryption property but not decrypt the files,

Select Apply changes to this folder, subfolders and files to decrypt all the files.

Click OK.

Using the Cipher Command to Encrypt and Decrypt Files

Cipher.exe is a utility that can be used at the command line to manipulate EFS encrypted files. It is particularly useful if you have large numbers of files to encrypt or decrypt, as in recovery operations. The syntax for cipher is provided in the "Tools" section later in this chapter.

To encrypt the reports folder and all subfolders, enter the following command:


cipher /e /s:reports

To encrypt a single filein this case the JanuarySales.doc in the Midwest\Sales folderenter the following:


cipher/e /a C:\Midwest\Sales\JanuarySales.doc

To decrypt the JanuarySales.doc file, enter this:


cipher /d /a C:\Midwest\Sales\JanuarySales.doc

Archive/Backup of Certificates and Keys

An understanding of EFS architecture and how it works is not necessary to perform backup of its keys. Users should be trained, however, to back up both an EFS certificate and its associated private key. If this backup or archival of certificate and private key is not done, users will eventually lose critical or sensitive data. It's just a matter of time.EFS Architecture" and "Avoiding Data LossPlanning for Recovery," later in this chapter.

Meanwhile, if EFS is not disabled, certificates and keys must be backed up, and the backup must be secured. Backup should be periodically repeated to ensure that a good copy is available in case it is needed to recover encrypted files.

Users and IT pros should be aware that the archived certificate and private key can be imported into the certificate store of any user, not just the original user. This is a good thing because the original user account may also have been deleted or destroyed in whatever circumstances damaged or destroyed their keys. However, it can mean that if the archived certificate and key become available to an unauthorized individual, that person might be able to use the keys to decrypt files to which he or she should not have access. To prevent this from happening, a complex password should be used to protect the file, and the media should be stored in a safe place. The password will be needed to use the backup. Because this password may be infrequently used, it may also need to be stored in a safe location, separate from the media. Storing the password on the hard drive or in documents kept with the computer or with the media is not acceptable.

During the archival process, the private key must be selected for backup. Instruct users to do so because the certificate alone will not be sufficient to recover encrypted files. When prompted, users should not remove the private key from the computer. Removing the private key will make it impossible for existing encrypted files to be decrypted.

Getting users to follow this procedure may be difficult, and some explanation of how EFS keys can be damaged or destroyed may help encourage the practice. Any operation that can damage data can damage keys. Keys are part of the user's profile. Keys might be accidentally deleted, for example, if an administrator deletes the user's profile. (Profile deletion is a common practice when profile problems occur. Because a new profile is created when the user logs on, the new profile may solve the problem. Unfortunately, it may also create a new oneloss of access to encrypted files.) Another way keys are destroyed is when a drive crashes or when the operating system is reinstalled. In some cases the keys remain, but since they are not associated with any current user, they cannot be used to decrypt the files.

To archive certificate and private keys, you can use the Certificates snap-in, the file system Backup Keys button, or the cipher command.

Use the Certificates Snap-In to Archive Keys

Add the Certificates snap-in to an MMC console.

Expand the Certificates container and select the Certificates, Personal, Certificates folder, as shown in Figure 6-4.

Figure 6-4. Be sure to verify that the certificate you are archiving is current.

[View full size image]

Right-click the EFS certificate in the details pane and click All tasks, Export.

Click Next at the wizard Welcome screen.

To archive the private key to ensure later recovery, select Yes, export the private key and click Next. (The default, as shown in Figure 6-5, is not to export the key. The certificate, without the key, is worthless for recovery.)

Figure 6-5. Always remember to add the private key to the export when backing up keys for archival purposes.

Note, as shown in Figure 6-6, that strong protection is selected. This will ensure that access to the private key is protected by a password. Click Next.

Figure 6-6. Do not delete the private keywithout it, you cannot decrypt files.

Enter a complex password and confirm it, as shown in Figure 6-7. Then click Next.

Figure 6-7. The password will be required to import the key. Do not forget it!

Browse to or enter a location to store the file. Add a filename and then click Next.

Review the settings, and then click Finish. You should see a popup telling you the export was successful.

When the private key is exported, the .PFX file format is used. This format is based on the PKCS#12 standard, a standard for storing or transporting private keys, certificates, and other miscellaneous secrets.

Use the Cipher Command to Archive Keys

Enter the following cipher command to back up the EFS keys to the EFS folder on the A:\ drive and save them in the RBkeys file.


Cipher /x:A:\efs\RBkeys

Use the Backup Keys Button

Right-click on a file that has been encrypted and select Properties.

Click the Advanced button.

Click the Details button.

Select the username in the Users who can transparently access this file box.

On the Advanced page, click the Backup Keys button, as shown in Figure 6-8.

Figure 6-8. The certificate owner's name must be selected before you can back up their keys.

This starts the Export wizard. Follow the procedure as described in the previous instructions for using the Certificates console, starting with step 4.

Import Certificate and Keys

If keys are archived, they can be used if the originals are destroyed or if it is necessary to decrypt files encrypted by someone who has left the company. To do so, import the keys into the profile of an account. This account does not have to be the one that originally was used to create the keys.

Create or open a Certificates console for the logged on user.

Right-click the Certificates - Current User, Personal, Certificate container and select All tasks, Import. Then click Next.

Browse to the certificate file and select it or enter the path and filename of the certificate file. Then click Next. If the Browse button is used, change the File Type box to all files to see the certificate file.

Enter the password for this certificate file.

Select Mark this key as exportable, as shown in Figure 6-9, and then click Next. This will allow backup of the key at a later time. If this selection is not made, the newly imported keys cannot be archived.

Figure 6-9. Don't forget to prepare for future key backups.

Check that the keys will be stored in the Personal store, as shown in Figure 6-10, and click Next.

Figure 6-10. Keys should be stored in the Personal store.

Review the settings and click Finish. Click OK in the popup indicating successful import.

Remove the Private Key

When traveling with encrypted data on a Windows XP or Windows Server 2003 laptop, a sound practice is to remove the private key and carry it separately from the laptop or data storage device. If the laptop is lost or stolen, even if the password for the account used to encrypt the data is known, the encrypted data cannot be decrypted without the private key. The laptop owner can decrypt files by importing the private key. A Windows 2000 laptop computer that is a domain member also can have this protection if a domain account was used to encrypt the files. When local user accounts are used to encrypt data on a Windows 2000 computer, a recovery agent may also be able to decrypt data. (Windows XP and Windows Server 2003 standalone computers do not automatically create a recovery agent.) If recovery agent credentials can be compromised, an attacker might use them to decrypt encrypted files. The recovery agent private key should also be removed to mitigate the impact of such an attack. To delete the private keys for each account that may have keys stored on the computer, export the keys, including the private key, but select the choice Delete the private key if the export is successful during step 6 in the earlier "Archive/Backup of Certificates and Keys" section of this chapter (refer to Figure 6-6).

Recover Files

Windows XP and Windows Server 2003 computers do not automatically create a recovery agent for EFS files. However, Windows 2000 computers do. In a Windows Server 2003 domain, the first domain administrator to log on after dcpromo will become the recovery agent. Windows XP and Windows Server 2003 computers joined in either a Windows Server 2003 or Windows 2000 domain will use the recovery agent keys to make their own protected copy of the file encryption key. This means that the recovery agent can recover the encrypted filesin fact, the recovery agent can transparently view any encrypted files that use the recovery agent's certificate to protect a copy of the file encryption key. It also means that anyone who can log on using the recovery agent account can read the encrypted files. The recovery agent account should be protected with a strong password and should not be used for day-to-day activities. While the files can be recovered (decrypted) by opening them, proper procedures dictate that they should be recovered by using the cipher command. This way, the recovery agent recovering the files will not see the data during the recovery process. It also means that many files can be decrypted at the same time. To recover encrypted files using the recovery agent, follow these steps:

If necessary, back up the encrypted files and move the backup to an isolated location. (Backed up encrypted files remain encrypted.)

If necessary, restore the files from backup to an NTFS partition on a computer dedicated to file recovery. (Restored encrypted files remain encrypted.)

Use the recovery agent account to log on from the console of the computer where the files have been placed.

Enter the cipher command, as shown here. The encryptedfileslocation is the folder where the encrypted files are located.


cipher /d /s:encryptedfileslocation

Return files in a secure fashion to the authorized user who should immediately encrypt them.

Obtaining Encryption Keys

If EFS has not been disabled, a user will obtain his EFS keys when he first encrypts a file. If the computer is joined in an Active Directory domain, the operating system will first look for the existence of a Certification Authority (CA) by searching the Active Directory. (If the Active Directory cannot be located, the request will fail.) If a CA is present, the operating system will request a certificate from the CA. If no CA is present, a self-signed certificate will be created for the user. A self-signed certificate is one that has not been issued by a CA. On Windows XP Professional, Windows 2000, and Windows Server 2003, the operating system automatically creates these certificates. This operation is transparent to the user.

However, the user can request a new certificate either using the Certificates snap-in or the cipher command. Before a new certificate is requested, the old certificate should be archived. Until an encrypted file is decrypted and then encrypted again, the new certificate will not be used, so its associated private key cannot be used to decrypt the file. To use the Certificates snap-in, do the following:

Open the Certificates snap-in for the current user.

Right-click on the Certificates, Current User, Personal container and select All tasks. Then select Request new certificate.

If the Active Directory cannot be located, the request will fail.

If the Active Directory is located and a CA is not present, the request will fail, as shown in Figure 6-11.

Figure 6-11. In a domain, a new EFS certificate can only be obtained if none is present, or if a CA is present to issue the new certificate.

If a CA is present, a list of available certificate types will be presented, as shown in Figure 6-12. Select the EFS Certificate and click OK.

Figure 6-12. Available certificate types for the logged on user will be displayed in the Certificate Request Wizard.

The cipher command cipher /k can also be used.

Old EFS keys should be archived, including the private key, but not destroyed. All files encrypted using the old keys need to be decrypted using the old key and then encrypted using the new one. The best way to do so is to use cipher /u.

Adding a Recovery Agent

The default recovery agent in the domain is the first administrator account to log on to the domain after the domain is created. Nothing specific has to be done for this to occur. If this certificate and key are archived, the certificate and key can be added back to the recovery policy if this is ever necessary. Additional recovery agents for the domain can be created if a CA is available. A CA is necessary to create the new recovery agent certificate.

On a Windows Server 2003 standalone system, no recovery agent is created. By default, there is no recovery policy for the standalone system. This is a rather large difference between Windows 2000 and Windows Server 2003. Windows XP also operates like Server 2003; there is no default recovery agent for a standalone computer. When the computer is joined to the domain, it will obtain and use the domain recovery policy and recovery agent if EFS has not been disabled.