Frequently Asked Questions: New Security Tool for EFS

  • Article
 

Q. What is the cipher.exe tool?

A. Cipher.exe is a command-line tool that's provided as part of Windows 2000, and which enables the user to manage encrypted data using the Encrypting File System. We've delivered an improved version of cipher.exe that provides an additional function designed to help customers secure their data.

Q. t's the Encrypting File System?

A.

The Encrypting File System (EFS) is a feature introduced in Windows 2000 that provides automatic encryption and decryption of data on NTFS disk drives. The important characteristics of EFS are:

  • It's transparent to applications. Encryption and decryption occurs automatically as part of normal file write and read operations, respectively.
  • It applies to folders as well as files. If the "encrypt" attribute is selected for a folder, all files within it, and all files subsequently added to it, are encrypted.
  • It's easy to use. Users can select files or folders to be encrypted via a checkbox on the Properties page of the item.

The Microsoft web site contains a number of references on EFS, but some of the best are:

Q. What's the new function the improved tool provides?

A. The new tool introduces a "Wipe" function that overwrites all of the deallocated data on an NTFS drive.

Q. What do you mean by "deallocated" data?

A. To answer this question, we first need to discuss how NTFS manages disk space. We should note before proceeding that the description that follows focuses on the mainstream case, in order to illustrate the general problem. MSDN provides a detailed technical treatment of NTFS for readers who would like additional information.

Whenever a new data file is created on an NTFS drive, the file system allocates data to it in chunks called clusters. If the file outgrows the clusters it's been allocated, NTFS allocates additional clusters. If the file later shrinks or is deleted, NTFS deallocates the unneeded clusters from the file, and marks them as being available for allocation to a different file if needed.

Q. So, when I delete an NTFS file, the data in the file isn't really erased?

A. That's correct. It's still on the drive, and will be overwritten by new data as soon as the clusters the data resides on are allocated to new files. In the meantime, though, it could be possible for an attacker to find these clusters and read the data. This isn't unique to NTFS—virtually all modern file systems work this way.

Q. Does this mean that a Windows 2000 user could read previously deleted data?

A. No. The NTFS security architecture prevents anyone from accessing the data in deallocated clusters. Even when the clusters have been allocated to a new file, NTFS will limit access to the data in the clusters, and only allow data that belongs to the new file to be read.

However, this wouldn't make it impossible to read the data. If an attacker were able to gain physical control of a Windows 2000 machine, he could boot the machine using a different operating system—one that didn't respect the NTFS security information. Through this method, he could potentially read the deleted data using a low-level disk editor or other tool.

Q. Is this a security vulnerability in Windows 2000?

A. No. In the scenario at issue here, Windows 2000 isn't even in use. Instead, this scenario is a good illustration of the Third Immutable Law of Security ("If a bad guy has unrestricted physical access to your computer, it's not your computer anymore").

Q. Does this mean the attacker could read every file I'd ever deleted?

A. No. Remember that deallocated clusters are reused at some point and allocated to new data files. When this happens, the data they contain would be overwritten. As a result, the attacker could only recover deleted data from clusters that had not yet been reallocated.

Q. How does the tool protect me against this scenario?

A. The tool gives you a way to overwrite all of the deallocated data on an NTFS drive. If you've done this, an attacker would be unable to read the data, even using a low-level disk editor.

Q. I heard that there are ways to perform forensic analysis and "un-overwrite" data. Is this true?

A. A number of claims have been advanced over the years regarding forensic techniques that potentially could be developed to recover overwritten data. The theoretical bases for these techniques range from checking for physical evidence to using magnetic remanence signatures to remove "layers" of data. We aren't experts on such techniques, and can't comment on the scientific validity of the claims.

However, can say this: there are no commercial products today that would enable an attacker to recover data that has been overwritten using a tool like the new cipher.exe. While it may be possible to build specialized equipment to recover overwritten data, the engineering would be esoteric and the costs would almost certainly be higher than the value of any data that it might recover.

Q. None of this seems to have anything to do with the Encrypting File System. Why is the new function provided as part of cipher.exe?

A.

We could have created a stand-alone tool to overwrite the deallocated data, but we concluded that it made more sense to include the feature as part of cipher.exe for two reasons:

  • Overwriting deallocated data only makes sense if you're also using EFS
  • An error that's commonly made when using EFS can be easily addressed using the new function.

Q. Why does it only make sense to overwrite deallocated data if I'm using EFS?

A. In the previous discussion, we discussed a scenario in which an attacker could recover data from files that had been deallocated but not yet reallocated. However, in such a scenario, the attacker wouldn't be limited to only reading data from deallocated clusters. If the operating system in use on the machine didn't respect the NTFS security information, the attacker could read data from any cluster on the drive, including ones that are currently allocated to files.

We can protect data in deallocated clusters by overwriting the data, but protecting the data in files requires a different approach. Overwriting the data would be counterproductive, and it isn't technically feasible to prevent an attacker with complete control over the machine from reading the data on the drive. But it is possible to prevent the data from being comprehensible to the attacker. That's where EFS comes in.

EFS enables you to protect the data in files by transparently encrypting it. An attacker who gained access to an EFS-encrypted file would be able to read the encrypted data, but would be unable to make any sense out of it unless he possessed the key. By using EFS to protect the data in sensitive files, and using cipher.exe to overwrite data in deallocated clusters, you can keep all of the data on the disk secure.

Q. What's the common usage error you mentioned, and how does the new tool address it?

A.

As part of the process of encrypting a pre-existing file, EFS always creates a backup copy of the file it's encrypting. The best explanation of the rationale behind creating it was provided in a Microsoft White Paper on EFS:

  • EFS also incorporates a crash recovery scheme whereby no data is lost in the event of a fatal error such as system crash, disk full, or hardware failure. This is accomplished by creating a plaintext backup of the original file being encrypted or decrypted. Once the original is successfully encrypted or decrypted, the backup is deleted... Creating a plaintext copy has the side-effect that the plaintext version of the file may exist on the disk, until those disk blocks are used by NTFS for some other file. ("Encrypting File System for Windows 2000", page 22).

The recommended way to use EFS is to encrypt folders, and then create sensitive files within them. This ensures that the data in the files is never recorded on the drive as plaintext. If EFS isn't used in the recommended way, and a file is created in plaintext first, and then subsequently encrypted, the encryption process would cause an additional copy of the plaintext to be created on the drive. The new cipher.exe tool can be used to ensure that the deleted backup copy couldn't be recovered.

Q. Is this a security flaw in EFS?

A. No. Remember that in order for the backup copy of the plaintext file to be made, the original version of the file also had to be in plaintext. That is, while the backup copy may be an additional source of plaintext, it will never be the only source of plaintext. In fact, under these conditions, it's likely that in addition to the two copies of the file we've already discussed, the disk would literally be littered with plaintext "shreds".

Q. What are plaintext shreds?

A. By plaintext shreds, we mean fragments of files that are created as part of normal file handling. Modern file systems like NTFS typically seek to optimize the usage of disk storage according to many criteria, such as how efficiently space on the drive is used, the access time required to read or write data, etc. To do this, they use a variety of data structures, and dynamically change between them in response to changes in the data.

For instance, under NTFS, small files are stored using one type of data structure; when they grow beyond a certain size, they're dynamically converted to a different data structure. Likewise, normal housekeeping operations like compressing and decompressing a file or defragmenting a hard drive can cause data to be re-situated on the drive. Each time this happens, the old copies of the plaintext are deallocated—but, like other deallocated data, it could potentially be recovered.

Q. What's the right way to use EFS?

A. The recommended way to encrypt sensitive data using EFS is to create a folder, set the Encrypt attribute on it, and then create files within it. If this is done, the files will be encrypted from the start. EFS will never create a backup file containing plaintext, and there will never be plaintext shreds on the drive.

Q. I've been creating files in plaintext and then encrypting them later. What should I do?

A. To address the plaintext that may already be on the drive, use the new cipher.exe tool and overwrite the deallocated data. To avoid the problem in the future, make sure you're creating sensitive files within encrypted folders.

Q. How do I install the tool?

A. To install the tool, just download the installer package and double-click on it. This will replace the version of cipher.exe that's already on the machine with the new version.

Please note that it's extremely important that you use the installer package to install the tool. Do not simply copy the new version of cipher.exe to your machine. New functionality has been added to NTFS to support the tool, and this is installed on the system as part of the tool installation process. If you simply copy the tool and then run it, it is possible to cause data on your system to be lost.

Q. Once I've installed the new tool, how do I use the new feature?

A.

To overwrite the deallocated data, do the following:

  1. Close all applications
  2. Open a command prompt by selecting Start, then Run, and entering CMD as the command
  3. Type "Cipher /W:<'directory'>" (without the quotes), where <'directory'> is any directory on the drive you want to clean. For instance, "Cipher /W:c:\test" will cause the deallocated space on the C: drive to be overwritten.
  4. The tool will begin running, and will display a message when it's completed.

Q. Why do I have to include a directory? Why not specify the drive?

A. NTFS drives can be mounted as directories. For instance, a drive could be mounted as C:\folder1\D_drive. This usage enables drives of this type to be cleaned.

Q. Should I run the tool on a regular basis as a preventive measure?

A.

You can run the tool as often as you need to. However, if you find that you need to run it periodically, it's probably a sign that you're not following recommended practices. That is, if you're following practices that potentially could expose data, it's good to use the tool—but it's better to follow practices that don't expose data in the first place. Specifically, we recommend that you:

  • Use EFS to protect any sensitive data on the machine
  • Always encrypt data files by creating them within EFS-encrypted folders, rather than creating them as plaintext and encrypting them later.

If you've followed these steps, it's not necessary to run the tool periodically, as there won't be any sensitive plaintext to overwrite.

Top of page Top of page