Once upon a time, encryption was something that was used only by government agencies, contractors working on top-secret military projects, and the most paranoid of private sector corporate entities. Times have changed. Today almost all businesses and many individuals have information stored in digital form that could cause embarrassment or even disaster if it fell into the wrong hands. We carry sensitive data around on portable computers, which are easily lost or stolen. We put confidential information on desktop machines that are located in physically vulnerable areas. We store critical trade secrets and personal client records on servers that are connected to the Internet and exposed to hackers. Today encryption is for everybody. It provides another layer of protection for information that must be kept private.

Luckily, encryption is getting easier and less expensive. Beginning with Windows 2000, Microsoft has built encryption capabilities into the operating system, and the encryption functionality has been improved in Windows XP. In this article, I will explore how Microsoft’s Encrypting File System (EFS) compares to third-party encryption methods. I’ll provide a brief overview of how EFS works “under the hood,” and I’ll explain how the version of EFS in Windows XP differs from that in Windows 2000. I will also discuss EFS vulnerabilities and list best practices for making EFS more secure.

Data encryption methods
There are several different methods for encrypting data. Different methods can be categorized by the state of the data when encrypted (stored on disk or in transit on the network), by the number of keys required (symmetric or asymmetric encryption), by the algorithms used (DES, IDEA, RSA, and so on), and in a number of other ways.

Note:

In this article, I am discussing only methods of encrypting stored data. There are other encryption mechanisms, such as IPSec, used to encrypt data in transit across the network.

Categorizing methods for encrypting stored data
You can categorize methods of encrypting data stored on disk based on the level at which the encryption occurs. For example:

  • Disk level encryption: Here the entire disk is encrypted, including operating system, swap files, and so on and a password, smart card, or other authentication mechanism is required in order to boot the computer.
  • Partition level encryption: A partition is created for encrypted data. Any data stored on that partition is automatically encrypted, with no action required on the part of the user.
  • Virtual drive encryption: Virtual drives (which are called containers, but are actually considered files) are created and encrypted with a key stored on the system or elsewhere (such as on a smart card or floppy). Separate secure containers can be created for different users or for devices such as Zip/Jaz drives.
  • File/folder level encryption: Data can be encrypted on a file-by-file or folder-by-folder basis.

Advantages of file/folder level encryption
Microsoft’s EFS gives you the ability to encrypt data at the file or folder level. Other encryption software, such as Kryptel, CipherWorks, SecretAgent, and many other third-party products also offer file level encryption. Some of these products use symmetric (secret key) encryption; they require that you set a password on each file you want to encrypt, and the same password must be entered to decrypt the file.

ScramDisk and DriveCrypt are third-party products that create virtual drives. An advantage is that they let you encrypt data on FAT-formatted partitions (EFS works only on NTFS partitions). Another product that uses virtual drives is SafeDisk. You access the containers using a password, and it can be used with Windows 9x operating systems. PGPdisk lets you set aside a location on disk that will be encrypted, which can be accessed using either a pass phrase or a PGP private key. EFS uses digital certificates and a combination of symmetric and asymmetric (public key) encryption, as I’ll discuss in the “under the hood” section later in this article.

The biggest advantage of file/folder level encryption is the flexibility it gives you to encrypt only those files you want to protect, without worrying about where the files are stored. With other methods, every file on a particular partition, virtual drive, or disk is encrypted. Encrypting certain files, such as operating system and application files, can cause problems in performance.

Although partition and virtual drive encryption provide convenience—all a user has to do is put the file on the partition or drive to encrypt it—the same effect can be achieved with EFS by creating encrypted folders. Then any file that you create in or move to that folder will automatically be encrypted.

A big advantage of EFS is its transparency to the user. Because it relies on certificates and keys that are assigned to the logged on user, there is no need for an authorized user to enter passwords or take other action to view and work with encrypted files. However, if an unauthorized user attempts to open the files, he/she will receive an “access denied” message.

How EFS works “under the hood”
EFS is integrated with the NTFS file system and, thus, only files/folders on NTFS-formatted partitions can be encrypted. If you move an encrypted file to a FAT partition or floppy, it will be decrypted. Microsoft has implemented encryption as a file attribute, so that encrypting a file or folder is as easy as accessing its properties sheet, clicking the Advanced button, and checking a check box, as shown in Figure A.

TIP

Encryption-related tasks can also be performed at the command line, using the cipher.exe tool.

Figure A
Encrypting files or folders with EFS is as easy as checking a check box.

This apparent simplicity is deceiving, however, as there’s a lot more going on with EFS “under the hood.” Here’s how it works, in a nutshell: When a user elects to encrypt a file, EFS generates a random number that becomes the file’s File Encryption Key (FEK). Then a variation of the DES symmetric encryption algorithm, called DESX, encrypts the file and stores it on disk. Symmetric encryption is used because it’s faster, and files to be encrypted can be large.

However, that’s not the end of the story. The FEK itself is also encrypted, using asymmetric encryption, with the public key assigned to that user. Asymmetric encryption is slower, but more secure, and since the FEK is small, performance isn’t an issue this time. Now when the user wants to decrypt the file, his/her private key is used to decrypt the FEK, which is then used to decrypt the actual file. Thus EFS combines the performance advantage of secret key encryption with the higher security level of public key encryption.

The key pair is tied to an EFS certificate. If this is the first time the user has encrypted a file, a certificate will be issued and a key pair will be generated for this purpose. If the user already has an EFS certificate, the associated key pair will be used. Users can also request an EFS certificate from a certification authority (CA). If there is no CA on the network, EFS generates self-signed certificates for users. When the user logs onto the computer, his or her certificates are associated with the user account and are automatically available when encryption or decryption needs to be performed.

New and improved EFS in Windows XP
One serious drawback of EFS in Windows 2000 is the inability to share EFS files with other users. Because of the way the FEK encryption process was designed, only the user who encrypted the file could decrypt it. There was no way for multiple users to share encrypted files.

Microsoft fixed this problem in Windows XP. Now the user who originally encrypts the file can select to share it with others. To do this, the user must select specific users who will be allowed access to the encrypted file. These users must have a valid local or Active Directory user account and an EFS certificate associated with that account. Then the additional users can decrypt the file with their own private keys.

Figure B shows the interface, accessed from the Details button on the Advanced Attributes properties sheet, which is used to share EFS files with other users. Only the user accounts that have EFS certificates will show up in the list of users with whom you can share the file. The accounts of users who have not ever encrypted a file (or requested an EFS certificate from a CA) will not appear on this list.

Figure B
Users who have EFS certificates can be given access to encrypted files.

Enterprise issues
EFS is designed so that it’s not necessary to have a CA on the network in order to use file encryption. If there’s no CA, the EFS component will issue a self-signed certificate to each user the first time the user requests to encrypt a file. There are, however, some advantages to using a CA to create EFS certificates, if you’re in a high-security or enterprise environment. This allows the network administrator to manage the certificates centrally, and using certificate services, you can revoke certificates and specify the length of time certificates are valid. It’s also possible to set up computers as dedicated recovery computers and issue specific recovery certificates to them, instead of issuing the recovery certificate to the domain controller.

In a domain environment, a recovery policy is normally defined at the domain controller, and, by default, the domain administrator is the designated recovery agent. A recovery agent is issued a special recovery agent certificate that allows for decrypting files that were encrypted by other users. There must be at least one recovery key configured on the system; otherwise, no one will be able to encrypt files. When you try, you will get an error message.

EFS vulnerabilities
Like any other security measure, EFS is not perfect. That’s why it should be part of a multilayered security plan. Most of EFS’s security vulnerabilities occur when it’s used on a standalone computer. The domain environment offers more protection. However, one of the most important uses of encryption is to protect data on standalone laptop/notebook systems, so it’s important to be aware of the ways that a determined intruder could circumvent EFS’s protections to gain access to your encrypted files.

One security disadvantage of file level encryption in comparison to disk level encryption is that the operating system files are not encrypted. This means that if someone steals your laptop, he may still be able to boot into the OS. There are a number of hacker tools available for cracking user account passwords, and he only needs the password of one user account to get into the system. The intruder will then be able to access any files that were encrypted by the user who holds that account.

What if he wants to access a particular encrypted file? Will he have to crack every user account and try each one in turn until he finds the user who encrypted the file? Unfortunately, this is not an issue for a savvy hacker because it’s likely he will be familiar with such tools as efsinfo.exe, which is part of the Windows 2000 resource kit. This tool can be used to determine the identity of the original user that encrypted the file.

If the intruder cracks the administrator account, though, he’ll be able to read everyone’s encrypted files unless you’ve changed the default by which the built-in administrator account is the EFS recovery agent, and even then, he can use efsinfo.exe again to find out which account has been designated as the recovery agent. So all the encrypted files will be wide open to him—unless you’ve taken steps to remove the recovery certificate from the machine.

Even in a domain environment, a hacker may be able to access cached logon credentials, capture logon information with a sniffer as it travels across the network, use replay methods to log on to the network with a valid account, or use brute force methods to guess passwords and gain access. These are not vulnerabilities of EFS itself, but because of EFS’s transparent nature, once logged on while impersonating a valid user, the hacker can access all of that user’s encrypted files.

EFS best practices
Following Microsoft’s recommended best practices for using EFS will enhance the security of your encrypted data. For example:

  • Have the recovery agent use the Export command from the Certificates MMC to back up the recovery certificate and the private key associated with it. Store this in a secure location, and delete the recovery certificate from the local machine. A hacker who cracks the recovery agent’s account won’t be able to use it to access everyone’s encrypted files.
  • Use Microsoft’s Syskey utility and either put the startup key on a floppy disk, which will require that the floppy be inserted in the drive in order to boot into the OS, or set a password that must be entered before the boot process can be completed. An advantage of this is that when Syskey is used, encrypted files become unavailable when it’s disabled, so even if the hacker disables it, he won’t have access to those files.
  • Assign recovery agent certificates to accounts that are created for that purpose. Remove the recovery agent certificate from the default admin account, and ensure that the recovery account(s) is not used for any other purpose. Set a very strong password on the recovery agent account(s).
  • In a domain environment, if you use roaming profiles, make sure that clients and the domain controller are configured to use IPSec so that hackers can’t capture users’ private keys, which are downloaded to them at logon as part of their profile. IPSec will encrypt this data as it travels across the network.
  • Be sure that encrypted files are not being saved in unencrypted form to temporary locations when you work with the files. Encrypt Temp directories and encrypt the folders in which your encrypted files are stored, rather than just encrypting the files themselves. Some applications save temporary files in the working directory.

Not the only security measure in town
Most importantly, don’t rely on EFS—or any other security measure—as your only means of protecting your data. Create a multilayered security plan in which you use EFS to act as a “vault” inside other front-line defense measures. Homeowners may put valuables into a safe inside the house, but that doesn’t mean they shouldn’t also put a fence around the property, lock the doors, and install an alarm system. Your data should be protected from intruders at the perimeter of the network (by a firewall), at the “front door” of the computer (by logon passwords), and once inside the OS (by access permissions), as well. If all these fail, EFS is your last line of defense that prevents intruders from reading the file once they get to it.