Taking Recovery Precautions

Previous page
Table of content
Next page

Encrypting a file always includes a risk that it cannot be read again. The owner of the private key, without which a file cannot be decrypted, might leave the organization without decrypting all of his or her files. Worse yet, he or she might intentionally or accidentally encrypt critical shared files so that no one else can use them. A user s profile might be damaged or deleted, meaning that the user no longer has the private key needed to decrypt the file s FEK. Because losing data is often disastrous, there are four methods of recovering when encrypted files cannot be decrypted. You can use data recovery agents, export and import of EFS recovery keys, and Backup for file backup and restoration.

Data Recovery and Data Recovery Agents

You can use Local Policy on stand-alone computers to designate one or more users, typically Administrator accounts, as data recovery agents. These DRAs are issued recovery certificates with public and private keys that are used for EFS data recovery operations.

The default design for the EFS recovery policy is different in Windows XP Professional than it was in Windows 2000 Professional. Stand-alone computers do not have a default DRA, but Microsoft strongly recommends that all environments have at least one designated DRA.

In a Windows 2000 environment, if an administrator attempts to configure an EFS recovery policy with no recovery agent certificates, EFS is automatically disabled. In a WindowsXP Professional environment, the same action enables users to encrypt files without a DRA. In a mixed environment an empty EFS recovery policy turns off EFS on Windows 2000 computers, but only eliminates the requirement for a DRA on WindowsXP Professional computers.

When a domain user logs on at a domain computer that is within the scope of the EFS recovery policy, all DRA certificates are cached in the computer s certificate store. This means that EFS on every domain computer can easily access and use the DRA s public key (or multiple public keys if multiple DRAs are designated). On computers where an EFS recovery policy is in effect, every encrypted file contains at least one data recovery field, in which the file s FEK is encrypted by using the DRA s public key and stored. By using the associated private key, any designated DRA can decrypt any encrypted file within the scope of the EFS recovery policy.

Warning 

The private key for a DRA must be located on the computer where recovery operations are to be conducted.

Because each DRA has a distinct private key that can decrypt a file s FEK, data recovery discloses only the encrypted data, not the private keys of any user other than the DRA. A private key for recovery cannot decrypt the DDF. If there are multiple recovery agent accounts, each private key for recovery decrypts only its own DRF and no other. Thus, there is no danger that an unauthorized recovery agent account can access information from the file that enables access to other files.

Note 

It is best not to encrypt files when you are logged on with a DRA account. The effectiveness of EFS recovery is compromised if a file s creator is both the user and the recovery agent.

For more information about encrypted file recovery, see WindowsXP Professional Help and Support Center.

For more information about how to change EFS recovery policy for the local computer, see WindowsXP Professional Help and Support Center and Configuring Data Recovery Policy in a Stand-Alone Environment later in this chapter.

Data Recovery Implementation Considerations

When designating DRAs for your files, it is important to keep the following considerations in mind:

  1. Files are more secure, but less recoverable, if only one person can decrypt them. If you choose not to designate any DRAs, be sure that user profiles are backed up regularly. The user s private key, without which the file cannot be decrypted, is stored in the user profile. Additionally, because users can have multiple profiles on multiple computers or might have a roaming profile, be sure that all profiles are being backed up. This is especially true for notebook computers. If the user logs on with a local account and encrypts a file, the private key for that transaction is contained in the user profile for the local account, not the user s domain account profile.

    The most effective way for users to ensure access to encrypted files is to export their EFS certificates and private keys. For more information about exporting EFS certificates and keys, see Exporting and Importing EFS and DRA Certificates and Private Keys later in this chapter.

  2. Files are less secure, but more recoverable, if more than one person can decrypt them. If you want the ability to recover encrypted files, designate one or more DRAs by using the EFS recovery policy.

  3. For more flexible EFS recovery management, consider issuing EFS recovery certificates to designated recovery agent accounts, in addition to the default Administrator account. Also, legal or corporate policy might require that the recovery agent account be different from the domain Administrator account. You can also configure EFS recovery policy for portable computers to use the same recovery agent certificates, whether the computers are connected to domains or are operated as stand-alone computers.

  4. EFS is normally used to encrypt user data files. Application files (for example, .exe, .dll, .ini files) are rarely encrypted. If computers are configured to use System Restore as part of recovery policy, application files are saved at restore points. These files can then be restored to return the system to a previous state. If application files that System Restore is monitoring are encrypted, it is important to note the following expected results of restoration:

    • If you decrypt a previously encrypted monitored file or folder, and then restore to a point before the file or folder was decrypted, the restored file or folder remains decrypted. If you undo the restore, the file or folder remains decrypted.

    • If you encrypt a monitored file, and then restore to a point before the monitored file was encrypted, the restored file is unencrypted. If you undo the restore, the file remains unencrypted.

    • If you modify a monitored file that is encrypted for multiple users, and then restore to a point before the modification occurred, the file will be accessible only to the first user who modified the file after the restore point was created. If you undo the restore, only the user who ran the restore will be able to access the file. The filter will back up the file during restore in the context of the user who is running the restore operation.

    • If you delete a monitored encrypted file and then restore to a point before the deletion, the deleted file is restored with its encryption attributes intact. If you undo the restore, the file is again deleted.

    • If you encrypt a directory and then restore to a point before it was encrypted, the directory remains encrypted. Monitored files created in this directory after the restore point are encrypted, but they will be deleted by a restore. Monitored files moved into this directory retain the encryption status from the directory in which they were created. After the restore, monitored files will be moved back to their original directory and retain the encryption status from that directory. If you undo the restore, the directory remains encrypted, and files are returned.

    • If you modify an encrypted directory (for example, change its name) and then restore to a point before the modification, the modification is lost, but the directory remains encrypted. If you undo the restore, the modification returns and the directory remains encrypted.

    • If you delete a directory that is encrypted and then restore to a point before it was deleted, the directory retains its encryption status. If you undo the restore, the directory is again deleted.

If you encrypt application files, consider these recommendations:

  • The best practice is to place these files in a partition/drive that is excluded from System Restore protection. This reduces the risk of restoring files to a pre-encrypted state.

  • If you choose to encrypt application files and use System Restore on the partition/drive storing the files, turn off System Restore (losing all previous restore points), complete the encryption settings, and then turn System Restore back on. This ensures that the files cannot be reverted to a pre-encrypted state.

To configure System Restore

  1. On the System Tools menu, click System Restore.

  2. Select System Restore Settings, and configure the options as appropriate for your environment.

    Note 

    You must be an administrator to configure System Restore.

Data Recovery Agent Decryption Process

The process for decrypting a file for a DRA is identical to that described earlier for a user except that the copy of the FEK encrypted by using the DRA s public key is taken from the file s DRF, decrypted, and used to decrypt the file.

Figure 17-8 illustrates the process of obtaining the DRA s private key from his or her user profile, using it to decrypt the FEK, and using the FEK to decrypt the data.

click to expand
Figure 17-8: Decrypting a file for a data recovery agent

Configuring Data Recovery Policy in a Stand-Alone Environment

In a stand-alone environment, an administrator for the computer needs to generate a recovery agent certificate and designate a DRA.

Designating a Data Recovery Agent in a Stand-Alone Environment

For stand-alone computers, Windows XP Professional does not create a default recovery agent. A DRA can be added by using Group Policy on the local computer, but the intended DRA must first have a recovery certificate. Because the computer is stand-alone, EFS creates a self-signed certificate for the DRA. This requires the cipher.exe command-line utility.

To generate a recovery agent certificate

  1. Log on as an administrator.

  2. At a command prompt, type:

    cipher /r:filename

    This generates importable .pfx and .cer files with the file names you specify.

To designate a DRA

  1. Log on as the intended DRA.

  2. Open the Certificates snap-in, and import the .cer file containing the recovery agent certificate.

    or

    Import the .pfx file containing the recovery key.

    Note 

    For more information about importing certificates, see Exporting and Importing EFS and DRA Certificates and Private Keys later in this chapter.

The local administrator can now open the Group Policy MMC snap-in and add the DRA.

To remove a DRA

  1. In Local Computer node of Group Policy, expand Computer Configuration.

  2. Expand Windows Settings, Security Settings, Public Key Policies, and Encrypting File System.

  3. Select the DRA to remove and delete the certificate.

Exporting and Importing EFS and DRA Certificates and Private Keys

As added protection in the event that a user s certificate or private key is damaged or lost, certificates and private keys can be exported. The certificate is stored in a file with a .cer extension, and the certificate and private key are stored in a password-protected file with a .pfx extension. These archive files can be stored on a floppy disk or other medium, and can be imported easily from these files.

Exporting these keys does not automatically remove them from the system; however, it is possible to remove the private key after it has been exported. Public keys are always available. They do not need to be removed. Circumstances might warrant removal of the private key, however.

If an EFS user wants to safeguard against loss of a private key through, for example, a damaged or deleted user profile, it can be exported and protected it with a strong password. Keys can be exported to a floppy disk, and the disk can be stored off-site or locked in a vault, depending on the level of security needed.

If one or more DRAs have been designated by Group Policy, it is important that those keys be exported. In addition, it is recommended that you:

In a domain environment, when DRAs are designated by Group Policy, any DRA can recover (decrypt) any domain user s encrypted files. Each encrypted file can have one or more data recovery fields, in which a copy of the file s FEK is encrypted by using a DRA s public key and stored. The DRA s private key, however, is not needed unless an EFS user is unable to decrypt a file. If a file needs to be recovered, a DRA can either import his or her private key on the computer where the encrypted file is stored, or the user can use the Backup utility included with WindowsXP Professional to back up the encrypted file and make it available for the DRA to restore on a computer used for data recovery.

Caution 

Every DRA has a personal EFS certificate and private key. Normally, when the DRA recovers a file, the DRA s personal private key is used. However, recovery certificates and keys are not bound to a specific user. Anyone who has access to a DRA s private key can import that key and use it to decrypt any files for which the DRA is a recovery agent. Therefore, it is extremely important to protect exported private keys by using strong passwords and physically secure storage.

Exporting Certificates and Keys

You can use the Certificate Export wizard to export a certificate and private key to a removable medium. The same process is used to export any certificate.

To export a certificate

  1. Open the Certificates snap-in, and then expand the Personal folder.

  2. Double-click Certificates, and then right-click the certificate you want to export.

  3. Select All Tasks, and then select Export.

  4. Select Yes, export the private key.

    The export format is PCKS #12. You have the option of deleting the private key or leaving it on the computer. If you are backing up an EFS certificate and keys, you might want to leave the private key on the computer so that you can decrypt your files without importing the private key. If you are backing up a file recovery certificate and keys, it is best if you delete the private key after the export. The private key is only needed for disaster recovery, and files are more secure if the private key is removed.

  5. Select an option, and then click Next.

  6. Enter a password to protect your exported private key. It is best if you use a strong password.

  7. Click Next.

  8. Enter a file name for the exported certificate and private key.

  9. Click Next, review the final information, and then click Finish.

    The export file has a .pfx extension.

Importing Certificates

The same process is used to import either an EFS certificate or a File Recovery certificate.

To import a certificate

  1. Open the Certificates snap-in, and then expand the Personal folder.

  2. Right-click the Certificates folder, click All Tasks and click Import.

    This starts the Certificate Import Wizard. You can also start this wizard by double-clicking a certificate file.

  3. In the dialog box, enter the name of your certificate file.

  4. Enter the password that protects the private key. This password was created during export. You have the option of protecting the imported private key by using the same password. If you enable this option, you will be prompted to enter this password when you attempt to open an encrypted file.

    Note 

    Enabling the option to protect the imported private key adds another layer of protection. However, if the password needed to open the file is forgotten, you will not be able to open the files. A designated data recovery agent would have to import the file recovery private key and open the file.

    You also have the option of marking the key as exportable. If you are importing from a backup copy of your keys and plan to keep the backup copy, it is best not to select this option. This prevents an attacker from exporting your EFS private key.

  5. Designate a location for the certificate. The default location is the personal certificate store.

Backing Up and Restoring Encrypted Files or Folders

In WindowsXP Professional, encrypted files and folders remain encrypted if you back them up by using Backup in Administrative Tools. You can also use the ntbackup command, the backup APIs, or other backup products designed for use with WindowsXP Professional. Backup files remain encrypted when transferred across the network or when copied or moved onto any storage medium, including non-NTFS volumes. If backup files are restored to volumes formatted by using the version of NTFS used in Windows 2000 or later, they remain encrypted. Along with providing excellent disaster recovery, backups can also be used to securely move files between computers, sites, and so on.

Opening restored, encrypted files is no different from decrypting and opening any encrypted files. However, if files are restored from backup onto a new computer, in a new forest, or at any location at which the user s profile (and thus the private key needed to decrypt the files) is not available, the user can import an EFS certificate and private key. After importing the certificate and private key, the user can decrypt the files.

Recovering Encrypted Files

Any data recovery agent can recover an encrypted file when a user s private key fails to decrypt the file.

To recover an encrypted file

  1. Log on to a computer that has access to the user s profile; for example, a computer that has a designated recovery console or a recovery key on removable media such as a floppy disk. You might log on at the user s computer or the user might have a roaming profile.

  2. Locate the encrypted file. For example, the user might have made a backup of the file by using Backup or sent the file to a WebDAV Web folder.

  3. Decrypt the file by using either the cipher command or My Computer. This will make the file available to the user.

    For more information about decrypting files, see Working with Encryption and Decryption earlier in this chapter.



Previous page
Table of content
Next page
Microsoft Windows XP Professional Resource Kit 2003
Microsoft Windows XP Professional Resource Kit 2003
ISBN: N/A
EAN: N/A
Year: 2005
Pages: 338
BUY ON AMAZON
SQL Tips & Techniques (Miscellaneous)
SQL Hacks
The Complete Cisco VPN Configuration Guide
Service-Oriented Architecture (SOA): Concepts, Technology, and Design
Information Dashboard Design: The Effective Visual Communication of Data
Persuasive Technology: Using Computers to Change What We Think and Do (Interactive Technologies)
flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net
Privacy policy