Keeping Files Confidential with EFS


Windows 2003 supports the Encrypting File System on NTFS volumes . EFS enables a user to encrypt a file such that only he can access it. When a user initially uses EFS to encrypt a file, the user is assigned a key pair (public key and private key). This is either generated by the certificate services or self-signed by EFS depending on whether there is a CA present. The public key is used for encryption and the private key is used for decryption.

When the user encrypts a file, a random number called the File Encryption Key (FEK) is assigned to the file. The DES or DESX algorithm is used to encrypt the file with the FEK as the secret key. The FEK is also encrypted with the public key using the RSA algorithm. In this way, a large file can be encrypted using relatively fast secret key cryptography while the FEK is encrypted with slower but more secure public key cryptography. This provides a high level of security with less impact on overall performance.

Leveraging Standalone EFS

Windows 2000, 2003, and XP all support EFS. They are capable of generating their own key pair for EFS if a domain level certificate is unavailable to them. EFS on a machine that does not belong to a domain has a number of differences than a machine that is a domain member. For example, Windows 2000 has a default setting that allows any local Administrator account to decrypt any user's encrypted files on that machine. This makes machines vulnerable to sector editor attacks as the local password store can be compromised. Windows XP and Windows Server 2003 do not have this behavior.

If a user encrypts a file and loses the certificate store of both the user and the local DRA, it will be impossible to decrypt the files. Similarly, due to the lack of a central key database for non-domain EFS users, a user could intentionally delete the DRA certificate and the certificate store and render the files unrecoverable.

When using EFS in a nonActive Directory environment, some key best practices should be followed to simplify management and improve local security:

  • Windows 2000 computers should have the default DRA private key removed stored separately from the system.

  • Use a SYSKEY mode with a boot floppy or master password that must be entered prior to system boot. The floppy or master password should be stored separately from the system. This helps protect the local account store from attack.

  • Build machines using sysprep and custom scripts to configure a central recovery agent. This can be achieved via a run-once Registry key that removes the existing local DRA and inserts a centralized DRA. This change must be performed after the sysprep mini-setup that generates the default DRA. The preferred practice is to use a Microsoft CA to issue a DRA certificate for the central recovery agent.

Existing Encrypted Files and Utilizing the Default Domain Recovery Agent

If a machine or user with standalone EFS is migrated to an Active Directory environment with an enterprise CA, clients will continue to use the self-signed certificates. They will not automatically enroll for a new certificate once they are joined. However, the default domain recovery agent will take effect for all new files. Existing encrypted files will utilize the default domain recovery agent once they are modified.


Common Pitfalls with Encrypted File System Implementations

One of the easiest traps to fall into with Encrypted File System (EFS) is to allow users to enable EFS on their own machine without access to a domain wide recovery agent. Clients will create their own key pair and administrators might not have the capability to recovery encrypted files if the user loses the local key pair. Active Directory allows you to prevent users from enabling EFS until such time that a proper CA has been put in place to enable managed EFS on the clients. The easiest way to do this is via GPMC:

  1. Open the Group Policy Management Console MMC snap-in.

  2. Navigate to the appropriate container where the GPO should be applied.

  3. Right-click on the GPO and select Edit as shown in Figure 1.6.

    Figure 1.6. Editing the GPO in Group Policy Management Console.

    graphics/01fig06.jpg

  4. Navigate to \Computer Configuration\Windows Settings\Security Settings\Public Key Policies.

  5. Right-click the folder named Encrypting File System.

  6. Click Properties.

  7. Uncheck the box marked Allow Users to Encrypt Files Use Encrypting File System

  8. Click OK.



Microsoft Windows Server 2003 Insider Solutions
Microsoft Windows Server 2003 Insider Solutions
ISBN: 0672326094
EAN: 2147483647
Year: 2003
Pages: 325

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