Windows 2000 EFS (Encrypting
File System)
Windows
2000 provides for the ability to encrypt files and folders on disk in a
fashion, which is transparent to the application. EFS is implemented using a public key infrastructure, and uses AD
if a certificate authority has not been assigned as the certificate manager.
A
file encrypted using EFS can be accessed only by a person who has the private
key (generally the file owner), or a "recovery agent", which defaults
to being the (domain) Administrator account.
Normal NTFS permissions also apply (of course). Additional recovery agents can be
created. Files are encrypted in such a
way that all recovery agents that exist at the time the file was created can
decrypt the files. Recovery agents created
after the file was created can not decrypt the files. If all recovery keys are lost or destroyed, the files are
inaccessible ("breaking" the encryption is computationally
difficult).
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.
Conclusions of the Windows
2000 working group
The
plan is to disable EFS on a global policy basis at initial SLAC-wide AD domain
rollout. If and when the issues and
concerns are better understood, EFS may be enabled for use, with appropriate
key escrow management, for specific cases(*). Normal NTFS permissions will continue
to be used to limit access to files/folders to people who are authorized to
access the data.
All
machines that access SLAC resources will need to join the SLAC AD, at which
point SLAC wide global policies will apply, and EFS will be disabled.
(*)
The specific cases that have been conjectured have been laptops or systems that
have a high likelihood of being lost or stolen and which normally contain
information of an extremely private nature (medical information for example).
Gary
Buhrmaster, 2/12/00