Cipher Command-Line Utility
The Cipher command-line utility, which Microsoft built into Windows 2000
(Win2K), displays or alters the encryption of directories and files on NTFS
partitions. The Cipher utility supports several commands. Type
cipher /?
to view the switches Table A summarizes.
Used without switches, the Cipher utility displays the encryption state of the
current directory and any files it contains. You can use multiple directory names
and wildcards. You must type spaces between multiple commands. For example,
to encrypt the sales information directory, type
cipher /e "sales information"
To decrypt the directory called "new projects", type
cipher /d new*
Windows NT users can set NTFS permissions to control who can access data.
However, file permissions don’t always ensure that data is protected, and some
users find that setting permissions is complicated. If people can gain physical
access to a machine, they can employ several methods to bypass even correctly
set NTFS permissions. They can boot from a diskette to DOS and then use a
utility such as NTFSDOS to access any file on the hard disk, including the
protected files. Alternatively, they can remove the hard disk from the system and
attach it to another system or employ one of several other methods to gain full
access to the data. In other words, the OS provides the protection, and if hackers
can find a way to bypass the OS, they can bypass the security as well. EFS
solves this problem by writing data to the hard disk using public key encryption.
The data is in an encrypted format on the hard disk, and it remains protected
even if someone uses another OS to boot the machine or moves the hard disk to
another machine.
How EFS Works
When you specify that you want to use EFS to encrypt a file or a folder, EFS
generates a file encryption key (FEK), which consists of a pseudo-random
number. The system uses this number and the Data Extended Standard X
(DESX) algorithm to create the encrypted file and write it to the hard disk. The
system then encrypts the FEK with your public key and stores it with the
encrypted file. When you access the encrypted file, the system uses your private
key to decrypt the FEK and then uses the FEK to decrypt the file. When you use
EFS for the first time, the system automatically generates a public/private key
pair if one doesn’t already exist. If you're logged on to a domain, the
public/private key pair resides on a domain controller (DC); otherwise, it resides
on the local machine.
Setting Up EFS
EFS is available only on Win2K machines that have NTFS formatted disks. To
configure a file or a folder to use NTFS, right-click the file or folder and chose the
Advanced button on the Properties dialog box that appears. Next, on the
Advanced Attributes dialog box, click the "Encrypt contents to secure data"
checkbox. As a result, the system rewrites the file or the contents of the folder to
the hard disk using encryption, thereby making the data inaccessible to anyone
without the proper credentials. Any new files you create in an encrypted folder
will automatically write to the hard disk with encryption. File decryption happens
automatically, without prompting, when you access a file—if you're the user that
set up the encryption. Not only is using EFS much easier than setting NTFS
permissions, it's also more secure.
EFS Recovery Agents
As a network administrator, you're probably thinking ahead to one danger that
EFS might introduce: If a user encrypts important company information and then
leaves the company, how do you gain access to the data? To provide for data
recovery, EFS generates two copies of the FEK and stores them with the file on
the local hard disk. The first copy is encrypted with the user's public key, and the
second is encrypted with the designated recovery agent’s public key. These
steps ensure that the recovery agent can access the FEK and decrypt the file if
necessary. By default, the domain administrator is the recovery agent for domain
computers, and the local administrator is the recovery agent for standalone
machines. You can use Group Policy to specify different or additional recovery
agents.
The weekly reports from the latest companies (including Microsoft) to fall victim
to intruders demonstrate that no one is immune. EFS doesn't offer a foolproof
guarantee that your data is safe, but this new encryption tool is much more
secure than any of its predecessors.
addition to using EFS from the explorer GUI, the CIPHER command is provided
to encrypt or display the encryption of folder and files on an NTFS partition.
Notes: If you encrypt a folder, all its' files and sub-folders are encrypted.
EFS does not work on on an object that has the System attribute.
EFS does not work on on a compressed object.
cipher can recognize files it has previously encrypted. The ciphertext of a file is
placed in a file of the same name with '".cip"' appended; the original file is not
deleted, since I'm not sure that all errors during operation are caught, and I don't
want people to accidentally erase important files.
There are two command-line options: -c and -k. Both of them require an
argument. -c ciphername uses the given encryption algorithm ciphername; for
example, -c des will use the DES algorithm. The name should be the same as an
available module name; thus it should be in lowercase letters. The default cipher
is IDEA.
-k key can be used to set the encryption key to be used. Note that on a multiuser
Unix system, the ps command can be used to view the arguments of commands
executed by other users, so this is insecure; if you're the only user (say, on your
home computer running Linux) you don't have to worry about this. If no key is set
on the command line, cipher will prompt the user to input a key on standard
input.
Encrypting Files and Folders
Win2K’s NTFS file and folder properties include encryption as an option. Users
can open, read, and save encrypted and nonencrypted files. Only the user who
encrypts the file or folder or a registered recovery agent can access an encrypted
NTFS file or folder.
Applying EFS is similar to applying NTFS’s compression attribute. When you
encrypt a folder, NTFS individually encrypts the files inside the folder and
automatically encrypts any files you add to the folder. If any subfolders exist, you
can also encrypt them. By default, NTFS encrypts any subfolders you create in
an encrypted folder.
EFS doesn’t support encryption and decryption of files and folders on a FAT
volume. In addition, users can’t share encrypted files. Three types of files exist
that you can’t encrypt: a system file, a compressed file, and a read-only file. You
can encrypt and decrypt folders (and files within a folder) from a command line
using Cipher. You can also use Windows Explorer to encrypt files or folders. You
can activate the encryption or compression attribute by clicking Advanced on a
file’s or folder’s Properties dialog box General tab. The compress and encrypt
attributes are mutually exclusive: When you select one attribute, the other
attribute automatically clears.
Make sure you don’t encrypt any files in the system folder. A user’s encryption
key isn’t available during the boot process, so if you encrypt system files (e.g.,
system DLLs, the Registry), you can’t boot into Win2K. Future versions of Win2K
will let you encrypt system files. If you attempt to encrypt a read-only file, you’ll
receive the message Error Applying Attributes.
To identify encrypted files in a folder without verifying individual file properties,
you can use Cipher without any switches to display the state of the files in a
folder. However, if you want to verify the state of files and folders at several
locations on different volumes, using Cipher can be tedious. Unfortunately, you
can’t easily accomplish this task in Win2K. To encourage users to encrypt folders
rather than files, Microsoft intentionally didn’t expose encryption or decryption on
individual files from Windows Explorer.
Decrypting Files and Folders
EFS provides transparent decryption of files and folders for typical reads and
writes. Users also can decrypt files or folders by right-clicking a file or folder in
Windows Explorer. To decrypt a file or folder, clear the Encrypt contents to
secure data check box in the Advanced Attributes dialog box, which Screen 2
shows. You access Advanced Attributes from the file’s or folder’s Properties
dialog box General tab.
Recovery Policies
When you install the first Win2K domain controller, Win2K automatically
implements a default recovery policy. Win2K issues the domain administrator a
self-signed certificate and designates a recovery agent. For standalone
machines, the system configures a default recovery policy locally. For machines
on the network, the system configures the recovery policy at the following three
levels: domain, organizational unit (OU), or computer. Administrators can define
three types of recovery policies: the recovery agent policy, which takes effect
when an administrator adds one or more recovery agents; the empty recovery
policy, which has no one designated as a recovery agent and in which EFS is
turned off; and no recovery policy, which means you have deleted the group
recovery policy so that the local machine administrators can control data
recovery by using default local policy. You add recovery agents through the
Group Policy console.
General Tips
Always encrypt folders rather than files. Encrypting folders will automatically
encrypt temporary files inside those folders. Similarly, encourage users to
encrypt the Temp folder on their workstations, and also to encrypt the My
Documents folder if they store data there. Because the data transferred over the
network isn’t encrypted, use a secure protocol such as SSL, IP Security (IPSec),
or PPTP. Be very careful whom you designate as a recovery agent. If your
company policy requires several recovery agents, periodically verify the
membership to ensure the list is current and accurate.
If you want to turn off EFS so that users can’t encrypt files, you can create an
empty policy with zero recovery certificates. Creating an empty policy is different
from having no policy. If you have no recovery policy, local machine
administrators can still define their own policies.
For security reasons, as a recovery agent you need to use the Export command
from the Certificates Microsoft Management Console (MMC) to back up a
recovery certificate. After you back up a certificate and the private keys to a
secure place, you need to delete the certificate from the console. You can use
the Import command to restore the recovery certificate and its associated private
keys. Don’t forget to delete the recovery certificate again in the Certificates
console.
Encryption Standards
EFS isn’t available in all OSs for two reasons. First, including EFS in an OS is
complex and requires that you integrate EFS with the OS. Second, national
regulations and restrictions on the export of encryption technology have made
integrating EFS more difficult for vendors. EFS encryption technology is based
on the DESX 128-bit encryption key. Current national policy doesn’t permit freely
exporting software with stronger than 56-bit encryption. EFS uses a DESX
encryption algorithm that is based on 128-bit encryption. Microsoft is working with
the US government for approval to export 128-bit DES. Win2K products in North
America will use this 128-bit DESX encryption. Because of export limitations,
international customers will be able to use 40-bit keys that are expanded to the
required 128-bits for DESX. According to Microsoft, you can restore files
encrypted with the international 40-bit version of EFS and use them with 128-bit
versions. However, you can’t use the 40-bit DESX to restore files encrypted with
128-bit DESX versions. This limitation ensures compliance with US export laws.
If and when the law allows exporting of stronger encryption, customers worldwide
will be able to migrate transparently to the stronger encryption algorithms. To
check the current status of US encryption export laws, go to
http://www.bxa.doc.gov/encryption.
Concerns and issues that are as yet unresolved
Before implementation of EFS, a number of issues have been raised regarding
EFS, and SLAC's Windows 2000 rollout.





Anti-Virus software scanning. In order to run virus scans on files using the
latest signature files, the anti-virus scanning software needs to have the
ability to access all data on all disks (and file servers). If EFS is enabled, that
means that the anti-virus software will need to be running with keys that allow
it to decrypt the data, which will need to be enterprise master keys.
Key management (and escrow) issues. For machines that are not part of the
SLAC domain, and for which SLAC has an interest in the data, key
management becomes a critical issue so that the data can be recovered.
Added layer of support burden without significant return on investment. NTFS
permissions prevent unauthorized file access to all files stored on the SLAC
file servers and all well maintained and managed workstations.
SLAC implementation phases. We may end up eliminating and recreating our
AD directory, which has the potential for making EFS files inaccessible due to
(re)creation of the EFS keys.
Reliability of EFS. It is new technology, and files encrypted using it may
become completely inaccessible. Those very files that people believe are



"private and important" may in fact become "extremely private and
inaccessible".
Performance issues. It appears that the file server does the encryption. For
an enterprise file server, this could be a big concern if a large number of
individuals decide to encrypt all their files.
Backup software support for EFS. NT Backup supports EFS, but Veritas
BackupExec is an unknown (and the current enterprise solution is
BackupExec).
Users with mandatory profiles cannot use EFS
Summary
The Encrypting File System (EFS) that is included with the Windows® 2000
operating system provides the core file encryption technology to store NTFS files
encrypted on disk. EFS particularly addresses security concerns raised by tools
available on other operating systems that allow users to physically access files
from an NTFS volume without an access check.
This document provides an executive summary and a technical overview of EFS
and looks at the issues of data access scenarios and the limitations of the
approaches that some products on the market have in trying to solve system, file,
and data security problems.
A standard safety measure on a personal computer system is to attempt to boot
from a floppy disk before trying to boot from the hard disk. This guards users
against hard drive failures and corrupted boot partitions. It also adds the
convenience of booting different operating systems. Unfortunately, this can mean
someone with physical access to a system can bypass the built-in security
features of the Windows® 2000 operating system file system access control by
using a tool to read Windows NTFS on-disk structures. Many hardware
configurations provide features like a boot password to restrict this kind of
access. Such features are not in widespread use, and in a typical environment,
where multiple users are sharing a workstation, they do not work very well. Even
if these features were universal, the protection provided by a password is not
very strong.
The root of these security concerns is sensitive information, which typically exists
as unprotected files on your hard drive. You can restrict access to sensitive
information that is stored on an NTFS partition if Windows 2000 is the only
operating system that can be run and, if the hard drive cannot be physically
removed. If someone really wants to get at the information, it is not difficult if they
can gain physical access to the computer or hard drive. Availability of tools that
allow access to NTFS files from MS-DOS® and UNIX operating systems makes
bypassing NTFS security even easier.
Data encryption is the only solution to this problem. With EFS, data in NTFS files
is encrypted on disk. The encryption technology used is public key-based and
runs as an integrated system service, making it easy to manage, difficult to
attack, and transparent to the user. If a user attempting to access an encrypted
NTFS file has the private key to that file, the user is able to open the file and work
with it transparently as a normal document. A user without the private key to the
file is denied access.
Using the Cipher.exe Tool
You can use the Cipher.exe tool to display or encrypt data at an MS-DOS
prompt. To encrypt a file using the Cipher.exe tool, type a command similar to
the following line at the MS-DOS prompt:
cipher [/E | /D] [/S:dir] [/I] [/F] [/Q] [dirname [...]]
The command line switches are defined in the following table. To view this
information at the MS-DOS prompt, type cipher /? at an MS-DOS prompt.
Switch
Description
/E
Encrypts the specified directories. Directories will be marked so
that files added afterward will be encrypted.
/D
Decrypts the specified directories. Directories will be marked so
that files added afterward will not be encrypted.
/S
Performs the specified operation on directories in the given
directory and all subdirectories.
/I
/F
/Q
Continues performing the specified operation even after errors
have occurred. By default, CIPHER stops when an error is
encountered.
Forces the encryption operation on all specified directories, even
those which are already encrypted. Already-encrypted directories
are skipped by default.
Reports only the most essential information.
dirname Specifies a pattern, or directory.
Used without parameters, CIPHER displays the encryption state of the current
directory and any files it contains. You may use multiple directory names and
wildcards. You must put spaces between multiple parameters.
NOTE : EFS does not work on file that use the System attribute. Your computer
could become unusable if you encrypt Windows system files. Also, note that EFS
cannot be used on compressed files or folders. There are additional switches
available with the command line utility Cipher.exe. To view them use the cipher
/? command