Recover encrypted data from your systems
In "Securing Win2K with Certificate Services," September 2001, InstantDoc ID 22113, I described how Microsoft's public key infrastructure (PKI) product, Certificate Services, worked and showed you how you can improve your network's security by leveraging the service as an Enterprise Certification Authority (CA). Now, I show you how to leverage the features that Encrypting File System (EFS) offers by tying it into your PKI.
The Security of EFS
EFS, which Microsoft introduced in Windows 2000, is a surprisingly powerful and robust technology that lets users protect their sensitive data from unauthorized eyes by encrypting it. Although EFS doesn't replace the safety you get through physical security and file and folder permissions, it does offer an additional safeguard in the event that an intruder defeats these mechanisms. For example, I use EFS to protect sensitive documents on my laptop when I travel on business. If someone steals my laptop and uses a tool such as Winternals Software's NTFSDOS Professional or a disk-sector editor to analyze the hard disk, the data in my files is encrypted and therefore unusable to the thief. You can also use EFS in your office network to further protect sensitive documents from prying eyes.
How EFS Works
Before I show you how to improve on the default EFS configuration, you need to understand how EFS works. (For EFS resources, see the Web-exclusive box "For More Information," which you can access at http://www.secadministrator.com, InstantDoc ID 23946.) When a user requests that a file be encrypted, EFS generates a symmetric key, called a file encryption key (FEK), which it uses to perform that encryption. To protect the FEK, EFS encrypts it with the public key from a certificate that supports EFS issued to the user. EFS stores the encrypted FEK and identifying information about the user with the now-encrypted file. When the user opens the encrypted file, EFS uses the private key associated with the user's certificate to decrypt the encrypted FEK. EFS then uses the decrypted FEK to decrypt the file. EFS performs data encryption and decryption on a user's behalf whenever he or she opens or saves a file.
To encrypt a file or folder, right-click the file or folder in Windows Explorer, select Properties, then click Advanced on the General tab. In the Advanced Attributes dialog box, which Figure 1 shows, select the Encrypt contents to secure data check box, then click OK. After you've marked a folder for encryption, EFS will encrypt any file written to that folder.
Like most CryptoAPI-generated certificates and keys, EFS certificates and their associated private keys are stored securely in your user profile, which has some important implications. For example, users with mandatory profiles can't take advantage of EFS because they can't save changes—including EFS certificates issued to them—to their profile. If you use Win2K in a workgroup environment or use local system accounts to log on, your profile is local to each system, and you'll have an EFS certificate on each machine. Thus, if you back up an encrypted file on one system and restore it to another, you won't be able to open the file because the EFS certificates are different.
You face a similar problem when you use domain accounts in Win2K domain environments without using roaming profiles. Each time you encrypt a file on a system for the first time, an EFS certificate with a public key and associated private key is issued to you. If you don't have a PKI in place, EFS issues a self-signed certificate (i.e., a certificate that has context only on the system that issued it). If you back up encrypted files on one system and restore them to another system, you won't be able to open the files. Similarly, if you've backed up encrypted files to a file server that subsequently fails, you won't be able to open the files restored to that server because your EFS certificates will have been lost (unless you backed up and restored your user profiles, too).
If you use roaming profiles, only one EFS certificate is issued to you, and each system trusted for Kerberos delegation can impersonate you and open your roaming profile to obtain both the EFS certificate required to encrypt an FEK and the private key required to decrypt it. (For the security implications of maintaining a copy of a user's certificate and private key on a central file server, see the Web-exclusive sidebar "What's the Downside to EFS?" which you can access at http://www.secadministrator.com, InstantDoc ID 23927.)
EFS encrypts files on the file system only. Also, EFS works only with NTFS 5.0 (NTFS5), so if you've upgraded your systems from Windows NT 4.0 or use a file system other than NTFS (e.g., FAT, FAT32), you can't take advantage of EFS. Data from encrypted files held in memory that applications have allocated isn't encrypted. Furthermore, if you access an encrypted file over a network, the encryption and decryption processes take place on the file server and all data is sent across the network in plaintext. If you need to secure the network to protect data in transit, consider using IP Security (IPSec) instead of EFS.
Using EFS with a PKI
Many organizations can realize significant benefits by using roaming user profiles and a PKI. For example, if you delete a roaming user profile or it becomes corrupt, you can recover that profile, complete with EFS certificate and associated private key, from another system that the user has logged on to either locally or over the network.
If you use a PKI that integrates with EFS, EFS automatically obtains certificates from the PKI instead of issuing self-signed certificates. Certificate Services has three types of certificate templates that support EFS: Basic EFS, User, and Administrator. However, EFS requests only a Basic EFS certificate for users. The advantages of using a PKI to issue EFS certificates include the ability to control the validity period of the issued certificates and the ability to revoke certificates if they become lost or compromised.
The default lifespan for a self-signed EFS certificate is 100 years from the date you installed the OS. Given the growth trend in computing power, in just a few years, intruders will likely be able to crack the keys used to protect encrypting keys. (Although you can't control the lifespan of an EFS certificate that a PKI issues directly, a CA can't issue a certificate with an expiration date after its own. Also, you can use other, non-Microsoft PKIs, such as Baltimore Technologies' Baltimore UniCERT, that can integrate with the EFS and let you set the expiration date.) When a certificate expires, you can still decrypt a file. However, when you save that decrypted file, EFS will automatically request a new EFS certificate and private key. You can delete expired EFS certificates and private keys, but you should first archive those certificates and keys in case you need to decrypt an old file secured with an expired EFS certificate. Also, you should consider exporting valid certificates in case the corresponding user profiles become corrupt.
Prev. page
[1]
2
next page 
