Use EFS to Encrypt Shared Data

People who use laptops often carry around several gigabytes of information—some trivial and some confidential. Most users depend on their username and password combination to restrict access to this information, but administrators know that this protection is only minimal.

The obvious solution to protect data is to encrypt it. Companies such as Sunbelt Software and PC Guardian offer specialized encryption tools, and Windows 2000's Encrypting File System (EFS) offers built-in encryption. But a problem with EFS—compared with other encryption solutions—is that because EFS uses unique private keys, people who share a laptop or workspace can't share the encrypted data. When just one person uses a laptop, this restriction isn't a problem. But I recently worked with a company that needed to protect corporate data on laptops that rotated on a regular basis. The laptops had several data directories that contained confidential customer data. When an employee—let's say Bob—had to do field work, he updated the data and took the laptop with him. If the company used EFS as Microsoft intended, the next employee to use the laptop—Mary, for example—would need to wipe all the data from the disk, then recopy all the data to the laptop to ensure that the network files were encrypted with her key. The company didn't want this hassle. In addition, when a laptop with only one designated user changed ownership, the company didn't want to have to decrypt, then later reencrypt, data on the laptop with the new user's key to ensure that the user could access the information.

To meet the company's needs, I had to bend the EFS rules a bit. EFS uses an X.509 certificate to encrypt data. This certificate resides in a user's personal certificate store. When the user has no suitable key, EFS will try to request the key from an enterprise Certificate Authority (CA). If no enterprise CA exists, the workstation will create a self-signed certificate.

To share encrypted data, users must have the same key. But the problem is that certificates created in this manner are unique for each user.

Simply sharing a key isn't difficult. You can use any key pair for which you've marked the private key exportable—including the self-signed certificates EFS can create. However, I wanted to use certificates that a company CA had issued so that the certificates would conform to the company's certificate policy. The company had a standalone root CA in place. (You can also use an enterprise root CA. With an enterprise root CA, you don't need to manually request a certificate, then have an administrator issue the certificate.) For information about installing a standalone root CA, see the Windows Help files.

To use a standalone root CA to create an EFS certificate, log on as Administrator and go to the Certificate Services Web site (http://servername/certsrv, where servername is the name of the server on which you installed your CA). This Web site installs automatically when you install Certificate Services. Select Request a certificate. Because the certificate enrollment form doesn't have a default option to request an EFS encryption key, you need to use the advanced request form.

In the advanced request form, enter all the requested information. In the name field, enter a name that will help you easily identify the certificate later. Be sure to correctly enter the Object Identifier (OID)—in this case, 1.3.6.1.4.1.311.10.3.4—and select the option to mark the key as exportable. For a list of OIDs, see the Microsoft article "Object IDs Associated with Microsoft Cryptography" (http://support.microsoft.com/?kbid=287547). Finally, select a key size that matches the encryption strength you want.

Next, you must use the Microsoft Management Console (MMC) Certification Authority snap-in to approve the key request. In the snap-in tree, expand your standalone CA's folder, then open the Pending Requests folder. This folder contains all the certificates that have been requested through the Certificate Services Web site but aren't yet approved. On a standalone root CA, each requested certificate must be approved before it's issued. Right-click the certificate you requested, and select All tasks, Issue. Next, go to the Certificate Services Web site and select Check on a pending Certificate. Select your certificate. On the next screen, click Install this certificate. You can now use the key to encrypt files.

To make the key available to other users, load the MMC Certificates snap-in and select the option for the snap-in to manage My user Account. Expand the Certificates Current User folder and select the Personal folder. The Personal folder is the user's personal certificate store. Right-click the appropriate encryption key (which you can identify by the name you entered on the request form) and export the key as a .pfx file (thus including the private key). Multiple users (e.g., Bob and Mary) can now double-click the .pfx file in Windows Explorer to import the file and therefore create encrypted files and access each other's encrypted files.

When a user imports the .pfx file into his personal certificate store, the user needs to mark the file as nonexportable, which is the default. Only use this certificate on domain accounts. A thief could easily circumvent your local user account security: If he or she obtained your machine, he or she could use the private key in your personal store to decrypt your data. Make sure you store the .pfx file in a secure place.

By default, the EFS recovery agent role goes to the local administrator. However, you need to assign this role to a domain user (whom I'll call EFSrecoveryUser). Otherwise, a thief could log on as the local administrator to decrypt your data.

To create an EFS recovery agent, log on as EFSrecoveryUser and go to the Certificate Services Web site. Follow the same procedure as for the EFS certificate request, except you need to use OID 1.3.6.1.4.1.311.10.3.4.1 to enroll an EFS recovery certificate. Again, enter a name that will help you easily identify the EFS recovery certificate.

To assign the EFS recovery agent to all the machines by using Active Directory (AD), you must export the EFS Recovery public key from EFSrecoveryUser's personal certificate store as a Distinguished Encoding Rules (DER) Encoded Binary X.509 file or a Base64 Encoded X.509 (.cer) file, then use a policy to publish the file. Log on as EFSrecoveryUser and open the Certificates snap-in. Open the Personal folder and right-click the appropriate key (which you can identify by the name you entered on the certificate request form) in the Details pane. Select All Tasks, Export, and select the export format and filename. To publish the public key, open the MMC Active Directory Users and Computers snap-in. Right-click the container where you store your computer accounts. This container is usually the Computers container directly under the root level—but since you can't assign policies to this container, you need to create an alternative container for computer accounts and move the accounts there. Select Properties and click the Group Policy tab. Click New and name your new policy EFS Recovery public key distribution. Then, click Edit. In the new Group Policy window that opens, expand the Machine Configuration, Windows Settings, Security Settings, and Public Key Policies folders. Right-click the Encrypted Data Recovery Agents folder and select Add. In the Add Recovery Agent wizard, click Next. Click Browse Folders and select the .cer file you exported. Click Next, Finish. You're now ready to share encrypted files and recover them if necessary.

You might notice that the imported certificate contains a warning that the certificate is from a nontrusted CA. You can use Group Policy to publish your CA as a trusted root CA. Go to the Certificate Services Web site and select Retrieve the CA certificate or certificate revocation list. Select your standalone root CA from the list, select DER encoded format, and click the Download CA certificate link. Save the file to disk. Next, use AD to publish the file. Open the Active Directory Users and Computers snap-in, and right-click the container you added earlier (i.e., where you added the EFS Recovery public key distribution Group Policy). Select Properties and click the Group Policy tab. Select the EFS Recovery public key distribution Group Policy, and click Edit. In the Group Policy window that opens, expand the Machine Configuration, Windows Settings, Security Settings, and Public Key Policies folders. Right-click the Trusted Root Certification Authorities folder and select All Tasks, Import. In the Certificate Import wizard, click Next. Enter the name of the file you downloaded from the Certificate Services Web site and click Next. Click Browse if possible; select the Trusted Root Certification Authorities certificate store and click Next. If Browse is shaded, click Next immediately. Click Finish.

I admit that my encryption solution exploits the public key infrastructure (PKI) because private keys aren't intended for multiuser use. However, my solution will meet most companies' requirements.

—Remco de Groot
[email protected]