Exporting Certificates, Encrypted File System Recovery - Win2k/XP

A certificate is only one part of the security! The user or computer (depending on the type of certificate issued) keeps a private key that corresponds to the certificate. The private key is never transmitted over the network and the server does NOT have a copy of the private key unless private key archival is configured.

http://technet2.microsoft.com/WindowsServer/en/Library/7641eea2-16e8-49b0-8387-e8c67da40ef71033.mspx

The private key is stored in the user profile by default, but it can be put on a smartcard. If the private key is lost then potentially the data encrypted with that key becomes *permanently inaccessible* unless you configure the EFS recovery agent or private key archival. The certificate on the server side is only used to verify the private key and whether the key has been issued by a trusted Certification Authority. Basically a certificate is an RSA public key signed by the private key of a CA.

If you don't get all this, then you should read up on encryption technologies (especially RSA), the role of a CA in a certificate chain, EFS recovery agents, etc. etc. before relying heavily on EFS for data security. Know how to and practice recovering encrypted data, or it will bite you.

A PKI requires proper planning, a backup and recovery strategy, some amount of user training, physical security and good network security/encryption to be of any use. Yes, all of those. Don't poke around a CA in a production environment. Please.

Here's some good articles:

Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure
http://technet2.microsoft.com/WindowsServer/en/Library/091cda67-79ec-481d-8a96-03e0be7374ed1033.mspx

Public Key Infrastructure for Windows Server 2003
http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx

Thx Rant- I have a very basic understanding of efs and pki technologies.  I was trying to determine the Windows implementation of the process of how the private key was derived in the process of encrypting a file and the best way to back it up accordingly.

It seems like the private is created by the local workstation or in the user profile in the process of requesting a certificate from a CA, even in the case when the user is encrypting data on a server share? (as is the case in my setup) Windows documentation of the process seems to indicate that the network traffic is not encrypted (w/o IPSEC).  So if the data is stored on the an encrypted server share I am guessing when the user opens up a file on an encrypted share it is decrypted on the server and then sent over the network unencrypted for use on the workstation and then only re-encrypted back on the server after the file is closed?  

In this setup I was trying to understand why the private key is held in the user profile on the workstation as it seemed to me like all the encryption would all be done on the server? I was trying to understand why the private key would be in the user profile, it seems like it is not used in the actual encryption algorithm itself but rather in part of the process to verify the owner of the certificate.

I have been looking through the recommend recovery strategies, and MS seems to indicate that these can be assigned at the OU level.  I was trying to learn how this would affect the contents of the OU?  Would the Agent on the OU have the private keys for everything in that OU and where would these then be stored?  Also, based on the rudimentary tests I have done, it seems like only the Recovery agents are the only ones able to open file encrypted by someone else and ACL rights do not allow an indvidiaul to open a file?

Sorry if this is a bit scattered, but the technology is very new to me so I am just trying to get a grasp on it.  Any answers to these questions would be much appreciated.

cheers

<< It seems like the private is created by the local workstation or in the user profile in the process of requesting a certificate from a CA, even in the case when the user is encrypting data on a server share? >>

Yes, correct. The local Crypto-service Provider (CSP) generates a private/public key pair, and the public key is sent to the CA for digital signing. That signed public key (the certificate) is stored in the CA and is also returned to the client. The simplified version is that the encryption is performed using the public key of the client and can only be decrypted by the client holding the correct private key. The encryption is not directly performed with RSA because it's far too slow, but the DESX encryption keys are exchanged with RSA.

<< So if the data is stored on the an encrypted server share I am guessing when the user opens up a file on an encrypted share it is decrypted on the server and then sent over the network unencrypted for use on the workstation >>

Also correct. If you want to be completely secure, network traffic must be encrypted.

As far as I know, the recovery agent doesn't get a copy of all private keys, but the recovery agent's account has its own private key which is added to the possible list of users who can decrypt the data. This is unrelated to the access control list on NTFS objects.

It's been a while for me since I looked at it and I'm doing all this off the top of my head (as usual, bad habit). If you want to I'd like to play around on a test lab, but after the Easter holidays. Can't think straight right now ;-)

Thanks for answering my questions, I will be testing this out a bit this week so if you have any time on your own to look at it again that would be great!  Just a few followup questions to your response.

-You said I was right to assume that data would be decrypted on the server first.   How would this be possible without the private key from the workstation?  You had said a DESX algorithm is used but I am not sure if you were also saying that the same key pair as the one in the certificate are being used.

-Secondly, how would ipsec be implemented in this equation?  I haven't seen any documentation on it.  Is it just a matter of enabling ssl on the certificate website in IIS?

-If the recovery agent has its own private keys which can be used to recover data.  Where are these keys stored?  I see there is an RSA folder on workstastion for the certificate holder;  But wouldn't the recovery agent keys be somewhere on the CA or in Active Directory?  If this is the case, wouldn't it be enough to just back up the recovery agent keys off the server instead of having to backup each workstation key?  As a follow up to this question, I have seen Microsoft says it is a good poliocy to back up all the keys off the workstation and once that is done, to remove the keys entirely from the workstation afterwards.   My question is, if the private key is removed from the workstation, as Microsoft suggests, how the would the end user get their data without re importing the key?

Thanks again!

Ok I figured out the answer to some of these, but still a few questions remain.  

You have to request a recovery agent cert to be able to add the agent in the GPO Computer settings part of the policy.  
It looks like IPSEC will require a configuration change on the nic cards on the workstations in addtion to gpo policy changes.

It also looks like all EFS 'security is based at the file level, so to grant access to an additional user to an encrypted file; you have to make them a recovery agent on the file itself.
 
I am having difficulty adjusting the scope of the recovery agents beyond individual files.  I would like to assign larger amounts of users as recovery agents to a specific sets of files.  I have assigned recovery agents at the Default Domain Policy level and they will show up by default on all files and I am able to decrypt them.  However when I have assigned  recovery agent rights at the OU level they are not able to decrypt files.  

I have looked at the User Enterprise Trust user setting for that to tie the agent into the user it the specific OU but the wizard looks for an .stl file or self signed certificate which I have not been able to generate.  

Rant, if that is the case with IPSec, then what would the necessary config entail just gpo settings?  I have worked with IPSec primarly in regards to websites/ie and not with files over an internal network.

I think you are misunderstanding the scope of what I am trying to do slightly.  I am not trying to encrypt individual user files or profile information.  I am trying to encrypt files shared by many users on an encrypted file share with subdirectories for different ou's/security groups.  So I want many users >15 to have access to a single encrypted file.

no doable, according to MS