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