Best Practices for the Encrypting Files System

This is my attempt to get this stuff sticking in my head as I tend to forget things that I have no interest in. This is my attempt at summerising in my own words, though somtimes not. Information is taken from: “Best practices for the Encrypting File System” http://support.microsoft.com/kb/223316

http://technet.microsoft.com/en-us/library/bb457065.aspx

Some quick terminology:
Volume: A formated partition on a hard drive.
Recover Agent Certificates: [MUST FILL IN]
Recover Agents: [MUST FILL IN]
OU: Organization Unit, this is Activate Directory terminology.
escrow: a: deed, bond, money, or property held in trust by a 3rd party to be turned over to the grantee upon fulfillment of a condition.
MS Windows can directly encrypt data on volumes that use the NTFS file system so that no other user can use the data. To encrypt data you need to set an attribute in the object’s properties dialog box.

If a user can a decrypt a file and has write permissions then this user has the ability to remove other users from encrypted file.

Warning! There is no way to recover data if the certificate is corrupt or missing.
Here are some best practices.

• Instruct users to export their certificates and private keys to removable media and store media securely when not in use.
• For greatest possible security the private key should be taken off the computer when the computer is not in use! This will protect the encrypted data from attackers that physically get their hands on that computer, no private key no data(I believe).
• When accessing the encrypted files the private key can be imported from the removable media.
• Never encrypt files only folders everything placed into an encrypted folder is itself encrypted.

Private keys associated with recovery certificates are sensitive! These types of keys:

1. must be generated by machines that are physically secured, or their certificates must be exported to a .pbx file.
2. protected with a strong password
3. saved on a medium physically secured

• Recovery agent certificates must be assigned to special recovery agent accounts that are not used for any other purposes.
• Do not destroy recovery certificates or private keys when recovery agents are changed, and apparently they are changed periodically, untill all files that have been encrypted with them are updated.
• When dealing with OU:
  1. Designate 2 or more recovery agents
  2. Designate two or more computers for recovery
  3. Grant appropiate permissions to administrator in order for them to use the recovery agents.
  4. Have 2 recovery agents per computer for redundancy.

• Create a recovery agent archive program to make sure that obsolete keys can recover encrypted files.
• Recovery & Private Keys must be exported and held in a secure manner.
• Archives must also be stored in a secure manner and 2 must be created: backup and master. The master should be kept on site and the backup offsite.
• According to this document it says to avoid using print spool file in the print server architecture, but I am not sure why? ( I should write the author of this document and ask him about this). It goes on to say that if you have to use print spool files make sure they are generated in an encrypted folder.
• Encrypting files does have CPU overhead, the article says to load balance servers when there are many clients using the Encrypting File System.

How to enable Encrypting File System file sharing
EFS:

• Supports file sharing of encrypted file to multiple users but not to groups.
• Only gives individual user permissions to access encrypted files.
• Cannot support multiple users access on a folder.
• Cannot support the use of groups on files.

• After a file has been encrypted then file sharing can be enabled thru the user interface, a button.
• A file must be encrypted first and then saved before users can be added.
• Add users thru the local computer or Active Directory if the user has a valid certificate for EFS.

Data Recovery on EFS Overview

• Data recovery does not mean that the private key has been reocoverd, key recovery is 1 way to achieve data recovery.

To recreate a self signed certificate in Windows XP Pro, in a command line type:
cipher /k

also be aware of the following key as it store the thumbprint of the key currently being used:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys

Random Notes:

from: http://archives.neohapsis.com/archives/sf/ms/2002-q3/0441.html
user: bkml@att.net, Bruce K. Marshall

• FEK:
  • Is better known as the File Encryption Key
  • Is not the current user’s public key
  • Is a randomly generated key
  • Unique for every encrypted file
  • Is encrypted using the user’s EFS public key then stored along with encrypted data in the data decryption field or DDF
  • Can be retrieved using their EFS private key

kiko: First off holy crap this EFS stuff is alot trickier than it seems to be.
kiko2: But Frank why?
kiko: O my little spoiled rotten apples the problem I am trying to solve is a simple one.

1. I encrypt a folder and store some files in it
2. I then proceed to export the certificate with the private key and select the delete key on successfull export.
3. Then I restart the computer so that the private key gets “uncached”

And it is at step 2 when the kamod overflows!! Why b/ even after the certificate with the private key is imported, none of the files previously encrypted can be decrypted!!! Haaaaa I am going to loose it with crap that is not documented detailed enough. There should be a law against half-ass documentation, if you are convicted you should have to repay long hours of users trying to figure out your truly ignoramous docs.

So I have broken down and called microsoft for help this is my info:
Case ID: 1041036163

Something I have found:

Circumventing or cracking EFS is monumentally difficult because each file is encrypted with its own key, which is in turn encrypted with the owner’s EFS key, which is in turn protected by that user’s master key, which is in turn protected by the system startup key. Installing a parallel copy of Windows or any other operating system and cracking the Security Accounts Manager (SAM) database won’t get you the keys you need to decrypt files because the keys aren’t stored in the SAM.

http://www.microsoft.com/technet/community/columns/secmgmt/sm0205.mspx

Ok I am going to stop here because for about a week and a half I battled with EFS and exporting keys. After looking at newsgroups & tutorials( yes from every so called EFS expert) that led no where I stumbled upon a Microsoft news group microsoft.public.security.crypto and subscribed to it. After going thru it completely not finding my answer I posted to it and I am going to paste everything below here is the url for the original post, short ending is when exporting do not enable strong protection:

http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.security.crypto&mid=8c5bdf6f-e511-4c1f-87da-35f947d4243e

Overview:

I am trying to do a simple EFS test in windows xp pro sp2.  I start
off with a clean certificate store for the personal folder.  The
following are my steps in order:

1.  I create a folder on my desktop

2.  Set the attributes to "Encrypt contents..."

3.  I create a plain text document in notepad outside the encrypted
folder and add a couple of words and save.

4.  I drag the text document into the encrypted folder; the filename
turns green, and the atrributes show up as 'AE', I also check its
attributes and sure enough it is encrypted.

5.   I then check my certificate store under the personal folder and
behold there is a certificate with an associated private key.  I know
this because when I double click it says so.  The thumbprint in the
text file and folder also match perfectly to the certificate with the
private key.

6.  Now I want to export the certificate and private key with it,
still in the certifiacte manager I right click my only certifiacte and
select export.

7.  All of the following are check off: "Yes, export the private key",
format used .PFX, "include all certifiactes in the certification path
if possible", "Enable strong protection", "Delete the private key if
export is successfull", I set my password it is only 6 charactes
long( I am just doing a test ), and finally set my file name.  No
problems were encountered after the export of the certificate with the
private key.

8.  I then go to test what I have done so far by logging out and
loging in, why? b/ the private key remains cached, and try to access
the encrypted file, I get an "Access Denied" message.  This is perfect
exactly what I expected.

9.  Now I import the certificate with the private key.  I   right
click in blank space in my personal folder of the certifacate manager,
slect "import", find my file, type my password, check off the
following: "Enable strong key protection..." and "Mark this key as
exportable...", then I place this certificate in the "Personal"
folder.

10.  Then I try to access the file and still recieve the access
denied.  I try logging out and logging back in and the same, I reboot
the machine and still the same.

Things to note:
-In different variations of this simple test I have deleted my
certificate from my certificate store under the personal folder after
a successfull export with the private key attached, but alas still
recieve the same error after importing the certificate containing the
private key.

Machine & Environment Information:
1. windows xp pro sp2
2. logged on as an administrator, I have tried this as different
account with adminstrative access and still have the "access denied"
problems when performing the same test.
3. machine is not part of any Active Domain
4. no recovery agent policy in place (this is fine as I just want to
do a simple test)

My brief of my understanding of EFS:
Upon first use of EFS a certificate and private key is created.  A
public key encryptes the "File Encryption Key" which in turn encrypts
the file(data) itself.  To decrypt the file(data) a private key must
Decrypt the "File Encryption Key" which in turn decrypts the
file( data ) iteself.  I know the "File Encryption Key" is a "symetric
key" and the public & private key pair are "assymetric" keys.

Questions:
1. If my "personal" certifiacte store has multiple certificates with
associated private keys which is tried first are any looked at in the
store or is only the current user's private key tried?  I know when
the current user is logged on with and EFS having allready been used
once he/she has an associated private and public key.  I assume in the
decryption process the current private key for the current user is
tried first but are the others, in the certificate, even looked at?
2. Any ideas on why the same user who encrypted the file cannot
decrypt it even after the importation of the certificate with the
private key?( the simple test )

Other info:
I don't care about "Recoverty Agents" at this moment.
Here is my result trying to use the cipher command to decrypt:
-------------------------------------------------------------------------------------------------
C:Documents and SettingsAdministratorDesktop>cipher /d /a enc
test.txt

 Decrypting files in C:Documents and SettingsAdministratorDesktop
enc

test.txt [ERR]
test.txt: Access is denied.

0 file(s) [or directorie(s)] within 1 directorie(s) were decrypted.

C:Documents and SettingsAdministratorDesktop>
-------------------------------------------------------------------------------------------------
- I have called microsoft( "India" ) and they have no clue about EFS
well at least I find myself explaining all the basic concepts to them
for more than 2hrs. 

Brian Komar responds:

This is your mistake. You cannot enable strong private key protection. EFS does not present the interface to type in the password protecting the certificate’s private key. You encounter a “silent failure”. Delete the certificate from the store again, re-import but do *not* enable strong private key encryption.

He goes on after I ask him how he figured this out.

This is going to sound bad, but “I wrote the book” www.microsoft.com/MSPress/books/6745.aspx Truthfully, I found this out during research during a consulting engagement about a year before I completed the PKI book. There are other applications that have the same issue – 802.1x wireless authentication for Windows XP is another great example Brian

Other 2 guys in the same thread talking about the same subject:

I wish. No, unfortunately EFS still has the same limitation on Windows Vista and 2008, since it inherits the same basic key- management architecture used in XP, 2003 and 2000. Now, remember that the private key is only accessible once the user has logged in. That said, it’s freely available to access (and potentially export, if export hasn’t been disabled when the keypair was generated/imported) throughout that logon session, so it’s good practice to encourage users to lock their screen, and to enforce the requirement to re-enter the password when resuming from standby/ hibernate. If given these considerations, you still find it unacceptable to use EFS keys that aren’t further protected, then your best (and only) option is to use EFS with smartcards in Vista. [I'm not saying that it's easy to make this transition - it's definitely a long-term investment - but there really are no other ways to protect that private key from someone - who's found the system logged in and unattended - who wants to access the encrypted data.] Cheers, Mike

On Aug 8, 2:49 am, Robert Kochem <rob…@mailueberfall.de> wrote: > Do you know if the “strong key protection” has to disabled under Vista, > too? I have read that the EFS system now resides on a much “higher level” > which allows to use EFS with certificates on a smartcard, therefore I could > imagine that the “strong key protection” should not be a problem under > Vista anymore. Am I right? > > Robert