Section 3.8. Using the Encrypting File System


3.8. Using the Encrypting File System

Windows 2000 introduced the Encrypting File System (EFS), a way to scramble the contents of documents, other files, and even programs so that they become unreadable by anyone other than the person who encrypted them. Although EFS has merits in environments consisting of corporate desktop computers, the real boon is for laptops: because theft of laptops has been on the rise for almost a decade, there is a real risk in storing sensitive information on these mobile system. If a laptop from a research and development representative were to fall into a competitor's hands, the cost of that loss would far exceed the retail price of a new laptop; indeed, the damage would be almost immeasurable. So, EFS is definitely an asset.

How does EFS appear to the end user? It's nearly transparent in operation, though not as much in presentation. When you encrypt a document, Windows doesn't attempt to hide the document's presence on the disk. In fact, encrypted documents are outlined in blue with a normal default folder view. The real transparency comes when you open the document. The process goes as follows: from each individual file on a server's disk, Windows calculates a unique file encryption key. When a user selects to encrypt a file, the file encryption key is encrypted too, using the public key stored on the user's EFS certificate. (This public key is generated the first time a request to encrypt an object is submitted.) To decrypt a file, the file encryption key must first be decrypted, which happens when a specific user has a private key that corresponds with the public key. These private keys are not stored in the SAM; rather, they are held in a protected key store. Note that other users can be authorized to decrypt the file encryption key by using their own private key. If the keys match up correctlythat is, if the expected result is obtained from the mathematical processesthe filesystem object is decrypted transparently. If there is an error, and unexpected results are returned, the user is denied access and the object remains encrypted. The object is encrypted again when the user closes it.

There are some limitations to note when using automatic encryption in the filesystem. For one, you can encrypt files and folders only on disks formatted with NTFS. Two, compressed files and folders cannot be encrypted; they will be uncompressed before the procedure. Three, you cannot encrypt files marked with the System attribute or files in the system root folder.

If you encrypt the parent folder when encrypting a single file or a single folder, all future additions to that folder will be encrypted automatically. But if you encrypt the folder only, objects in the folder at that point are not encrypted, though any future additions will be encrypted automatically. Additionally, when decrypting, if you select to decrypt a single file within an encrypted folder, future additions to that folder will not be encrypted.

There are performance implications when using EFS. Because of the nature of encryption and decryption, opening files that are subjected to those processes takes longer.


3.8.1. Encrypting Files and Folders

To encrypt a file or folder using the GUI, follow these steps:

  1. Right-click the file or folder to encrypt, and then select Properties.

  2. Navigate to the General tab, and then click the Advanced button.

  3. Check the Encrypt contents to secure data checkbox, and then click OK.

  4. In the Properties dialog box, click OK. You'll be prompted if the file or folder you want to encrypt is contained within another folder that is not encrypted. Select one of the following options:

    Encrypt the file and the parent folder.
    Encrypt the file only.

  5. Next, the Confirm Attribute Changes dialog box appears. To encrypt a folder only, select Apply Changes to This Folder Only. To encrypt a folder and all its contents, select Apply Changes to This Folder, Subfolders, and Files.

To decrypt a file or folder, follow these steps:

  1. Right-click the file or folder to encrypt, and then select Properties.

  2. Navigate to the General tab, and then click the Advanced button.

  3. Uncheck the Encrypt contents to secure data checkbox, and then click OK.

You also can control encryption from the command-line using the CIPHER utility, located in %SystemRoot%\System32:

  • To encrypt a folder using the command-line, run cipher /e foldername.

  • To decrypt a folder using the command-line, run cipher /d foldername.

  • To encrypt a folder and all its subdirectories recursively, run cipher /e /s:foldername.

  • To encrypt a single file within a directory, run cipher /e /a filename.

  • To decrypt a single file within a directory, run cipher /d /a filename.

  • To create a user's file encryption key before the first encryption request is submitted, run cipher /k.

  • To generate an EFS recovery agent certificate (more on this shortly), allowing a user other than the one who encrypted a file or folder to decrypt it in emergency situations, run cipher /r:filename.

  • filename represents the name of a file without its extension because the command will generate both a .PFX file containing the certificate and private key and a .CER file containing only the certificate.

Table 3-4 lists other command-line arguments for the CIPHER utility.

Table 3-4. Miscellaneous command-line CIPHER switches

Argument

Function

/F

Forces an encryption function to encrypt all files, regardless of whether they are encrypted already.

/H

Displays hidden and system files, which are left out by default, in the listing of files that are affected by an action.

/I

Ignores errors that normally stop an encryption function.

/N

Prevents keys from being updated. Used mainly to locate all encrypted files on a specified volume.

Works only with /U.

/Q

Displays only essential information when an action is completed.

/U

Hits all encrypted files on a volume and updates the user's encryption key if it has changed.

Works only with /N.

/W

Removes any data from available, noncommitted portions of a volume.

This is an exclusive option. No other switches are acknowledged when /W is used.


3.8.2. Recovering Encrypted Objects

It can be somewhat disconcerting that, in emergency or recovery situations, encrypted files can be decrypted by a user other than the user who encrypted the file originally. This is actually a feature, and it really is quite secure. Designated user accounts, called recovery agent accounts, are issued recovery agent certificates with public keys and private keys upon their creation that are used for EFS data recovery operations. The Windows user accounts that function as recovery agent accounts are designated by a GPO or a local security policy object, depending on the machine's participation in a domain. By default, they are the highest-level administrator account available. Depending on the network environment of a particular machine, this is either the local administrator or the domain administrator for the first domain controller installed in the domain. The private key from the appropriate agent certificate must be located on the computer where recovery operations are to be conducted.

When a recovery agent certificate is issued, the certificate and private key are installed in the user profile for the user account that requested the certificate. An EFS file can contain more than one recovery agent account, and each EFS file can have a different private key. However, data recovery discloses only the encrypted data, not the user's private key or any other private keys for recovery. This ensures that no other private information is revealed to the recovery agent administrator unintentionally.

Windows Server 2003 no longer requires a file recovery agent (FRA). Anyone can begin playing around with this feature in a test lab, for example, and because there is no default FRA on the network, that user's files will never be able to be accessed by anyone other than him. Ack!


To view the recovery agents for an object, log in as the owner of the encrypted object. Then, right-click the object and select Properties. Click the Advanced button, which opens the Advanced Attributes dialog box. Click the Details button to bring up the Encryption Details box. The recovery agents for the specified object are listed in the bottom box. Figure 3-14 shows this.

Figure 3-14. An object's recovery agents


But what is in the top box of the Encryption Details dialog? This is a new feature of Windows Server 2003 which makes it quite a bit easier to enable other users to decrypt a file without them being recovery agents. By designating their user accounts in the top list, the users can access and use the file transparently. Simply click Add and select the users from the local computer or from a domain that should be able to access the file transparently.

You also can decrypt files and folders quickly from the command-line if you are the recovery agent for those folders or the user who originally encrypted the objects. Use the cipher command with the /u and /a switches. For example, to decrypt a file called man_ch3r3.doc, issue the following command:

cipher /u /a man_ch3r3.doc

3.8.3. Protecting User Certificate Integrity

Microsoft recommends that, to protect a user's certificate from thievery, users should export their personal certificate, save it to some sort of removable media, and then remove it entirely from the local computer. This is because although the encryption/decryption methods EFS uses are quite secure, if someone happens to make off with a machine and is able to log on with administrator credentials, he could modify the certificate configuration to allow himself the ability to decrypt any files. Obviously, this is a problem. To follow the recommended procedure, take these steps:

  1. Open the Certificates snap-in to the MMC.

  2. Navigate through the Personal folder to Certificates.

  3. In the righthand section of the console, right-click the certificate to export, and select Export from the All Tasks menu.

  4. The Certificate Export Wizard begins. Select to export the private key along with the certificate and click Next.

  5. On the Export Options screen, select what file type the exported certificate should take, the level of encryption that should be used, and the action you want to be performed with the local key once the export is complete. Click Next once you've selected appropriate options.

  6. By exporting the private key, you need to encrypt it with a password of your choosing. Select the password carefully, as the certificate and private key will be irretrievable if you forget it.

  7. Select a path and filename for the key and certificate combination.

  8. On the final step in the wizard, double-check your selections carefully, and then click Finish. The wizard will trundle and notify you if the operation was successful.

The certificate will no longer reside on the computer from which you removed it. To re-import it to the same or a different computer, right-click inside the Certificates folder again, choose Import from the All Tasks menu, browse for your exported certificate file from the preceding list of steps, enter any necessary passwords protecting that certificate, choose a location for the key (usually the Personal folder is sufficient), and then click Finish. The key now resides on that computer.



    Learning Windows Server 2003
    Learning Windows Server 2003
    ISBN: 0596101236
    EAN: 2147483647
    Year: 2003
    Pages: 149

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