Actually, it's not at all like adding a recovery agent, nor is the
Administrator account on the machine automatically added as a data recovery
agent (DRA). I'll address your concerns as well as Milos' off-list request
for instructions in this reply since I think they're both addressed by the
same information.
First, let's look at what happens when a user encrypts a file. For purposes
of this discussion, I'm going to stick to a scenario where there is no PKI
in place.
*Note: important rules to remember- anything encrypted with a public key can
only be decrypted with the corresponding private key (and vice versa).
Anything encrypted with a symmetric (single) key is also decrypted with that
same key. Also, the workstation names are a bit odd here because I'm using
the names of a couple of the machines on my network as I've captured this
process in screenshots and I want people to be able to map the screenshots
to this explanation. :-)
Situation 1:
-Ripped2 is in a workgroup.
-UserBob logs on to Ripped2.
-UserBob creates a file called "Bobfile.txt", right-clicks the file and
selects "Properties", then clicks the Advanced button on the property sheet
for the file. UserBob selects the checkbox labeled "Encrypt contents to
secure data".
-Ripped2 checks UserBob's certificate store to determine whether or not
UserBob has an EFS certificate. Since this is the first time UserBob has
encrypted a file on this machine and since this machine has no PKI from
which to have obtained certificates, UserBob has no EFS certificate.
-Ripped2 generates a public-private key pair for UserBob, stores the private
key in UserBob's encrypted store (in his profile), then creates a
self-signed certificate into which UserBob's public key is embedded. This
certificate is stored in UserBob's Personal Certificates store.
-Ripped2 generates a symmetric file encryption key (FEK) for purposes of
encrypting Bobfile.txt. It is important to note that every single encrypted
file is encrypted with a unique symmetric FEK- the same FEK is never used
for another file.
-Ripped2 encrypts Bobfile.txt with the FEK generated for that file. The FEK
for Bobfile.txt is then stored in the header of the file in a field called
the Data Decryption Field (DDF). Symmetric keys are used for file encryption
because symmetric key encryption is much faster for bulk encryption (e.g.,
file encryption).
-Ripped2 then uses UserBob's public key, which is embedded in UserBob's EFS
certificate, to encrypt the FEK in the DDF.
-When UserBob opens Bobfile.txt, Ripped2 retrieves UserBob's private key and
uses his private key to decrypt the FEK that was encrypted with UserBob's
public key. The FEK in the file header, now decrypted, is used to decrypt
the file. This entire process is transparent to UserBob.
Now UserBob decides that he wants UserJoe to be able to access this
encrypted file. In order to do this, UserBob needs UserJoe's EFS certificate
and public key, so one of the following processes is undertaken:
Option 1- UserBob has UserJoe log on to Ripped2 and create a file, then
encrypt the file. When UserJoe encrypts a file on Ripped2, Ripped2 does the
same thing that it did when UserBob encrypted the file, but this time it
creates a key pair and certificate for UserJoe, storing the private key in
UserJoe's encrypted store and the certificate in UserJoe's Personal
Certificates store. Joe's certificate is also automatically added to
UserBob's "Trusted People" store at this time.
Option 2- UserJoe logs on to his own workstation, Jack, and encrypts a file
there, whereupon Jack creates the key pair and certificate on Jack. UserJoe
then uses the Certificates snap-in in an MMC to export his newly-created EFS
certificate. UserJoe is given the option to export his private key along
with his certificate. He does not have do so at this time, but he does
because he plans to decrypt files on another workstation.
UserJoe now takes that exported certificate to Ripped2 (say, on a
floppy, or via a drive mapping- it really doesn't matter how he gets it
there). UserJoe logs on and double-clicks the certificate, which brings up
the Certificate Import wizard. UserJoe follows the instructions and the
public-private key pair and certificate are now stored on Ripped2. UserJoe
logs off.
Option 3- UserJoe does the same things as in Option 2, but does not log on
to Ripped2 and import the certificate and key pair. In fact, UserJoe exports
only his certificate (without the private key) and gives his certificate to
UserBob. Remember, UserJoe's certificate contains UserJoe's public key.
UserBob logs on to Ripped2 and double-clicks the certificate that UserJoe
gave him, which imports it into UserBob's "Trusted People" store.
UserBob is now ready to make his encrypted file decryptable by UserJoe.
UserBob again right-clicks the file, brings up the properties and clicks the
advanced button. Whether UserJoe logged onto UserBob's workstation and
created a certificate by encrypting a file, or whether UserBob imported
UserJoe's certificate doesn't matter- either way, UserJoe is now available
as an additional data encryption agent for the file. UserBob again
right-clicks Bobfile.txt, brings up the properties, clicks the Advanced
button, and clicks the now-available Details button next to the "Encrypt
file contents..." checkbox. UserBob adds UserJoe as an additional data
encryption agent. As long as UserJoe has imported his private key onto
Ripped2, UserJoe can decrypt the contents of the file.
UserJoe is *not* a data recovery agent for Bobfile.txt- he is an additional
*encryption* agent. In fact, in this scenario, there is no data recovery
agent at all, because XP machines in a workgroup or in the absence of a
defined EFS policy, unlike Windows 2000 machines in a workgroup, do not
automatically use the local Administrator account as the default DRA;
instead, they encrypt the file without a DRA at all. This is why it is
advisable to have a PKI in place when users are encrypting files- by doing
so, you can use group policies to specify DRAs for your organization,
whether you do it at the OU level, or whether you use the same DRA
domain-wide.
Yesterday I spent a few minutes running through this scenario and capturing
screenshots of it as I mentioned above. I'm now putting it together into a
document that I'll send to the list.
Laura
> -----Original Message-----
> From: Sebastian "En3pY" Zdrojewski [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 04, 2006 3:38 AM
> To: [email protected]
> Subject: R: Questions regarding EFS
>
> AFAIK the process for adding more encryptors to the EFS
> process is more likely the process used to add a "Recovery
> Agent" for the user, so that if the user account got
> corrupted, or an administrator forces the user's password
> (both cases makes the encrypted files unrecoverable) the
> Recovery Agent can recover the information. If I remember
> well on XP the default user marked as Recovery Agent is the
> Administrator user account, while on Server platforms this
> function is not explicitly defined (that is: no recovery
> agent is defined for a user's encryption certificate).
>
> I may be wrong, but I am sure I have studied it this way.
>
> Sincerely
>
> En3pY
>
>
> --
>
> Sebastian `En3pY` Zdrojewski
>
> ##############################
> # URL: http://www.en3py.net/ #
> # E-Mail: [EMAIL PROTECTED] #
> ##############################
>
>
> -----Messaggio originale-----
> Da: Laura A. Robinson [mailto:[EMAIL PROTECTED]
> Inviato: sabato 4 marzo 2006 1.51
> A: 'Sebastian "En3pY" Zdrojewski'; [email protected]
> Oggetto: RE: Questions regarding EFS
>
> Actually, this is not the case. EFS sharing can be used in
> the absence of a PKI. The encryptor of the file only needs
> the certificate of the user they wish to add as an additional
> encryptor, and the process is quite simple. If specific
> instructions are needed, I can provide them, but the process
> is very straightforward and simple. Having said that, it is
> advisable to have a PKI in place when using EFS, but not
> because of the desire to add additional encryptors. This
> applies regardless of whether we're discussing a single
> machine or multiple machines.
>
> Laura
>
> > -----Original Message-----
> > From: Sebastian "En3pY" Zdrojewski [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 03, 2006 1:22 PM
> > To: [email protected]
> > Subject: R: Questions regarding EFS
> >
> > Actually you cannot use EFS to share information with other users
> > unless you have PKI services installed on your network.
> > Unless you decide to install PKI infrastructure on your
> network, the
> > encrypted files will be available only on local system.
> Copying files
> > and/or folders to targets outside the local system will
> cause loss of
> > encryption.
> >
> > Sincerely
> >
> > En3pY
> >
> >
> > Sebastian Konstanty Zdrojewski
> >
> > ________________________________
> >
> > URL: http://www.en3py.net/
> > E-Mail: [EMAIL PROTECTED]
> >
> > ________________________________
> >
> > Le informazioni contenute in questo messaggio sono riservate e
> > confidenziali. Il loro utilizzo è consentito esclusivamente al
> > destinatario del messaggio, per le finalità indicate nel messaggio
> > stesso. Qualora Lei non fosse la persona a cui il presente
> messaggio è
> > destinato, La invito ad eliminarlo dal Suo Sistema ed a
> distruggere le
> > varie copie o stampe, dandone gentilmente comunicazione.
> Ogni utilizzo
> > improprio è contrario ai principi del D.lgs 196/03 e alla
> legislazione
> > Europea (Direttiva 2002/58/CE).
> >
> > -----Messaggio originale-----
> > Da: Arley Barros Leal [mailto:[EMAIL PROTECTED]
> > Inviato: giovedì 2 marzo 2006 10.29
> > A: Dwight Jones; [email protected]
> > Oggetto: RE: Questions regarding EFS
> >
> > Hi Dwight,
> >
> > You may use the command "cipher" to script or command line
> efs enc/dec
> > operations. To be able to enc/dec files stored on remote
> servers (ie.
> > Trough
> > shares) you must trust the server for delegation and thus let the
> > server impersonate your credentials.
> >
> > I'm not sure if you can share encrypted files with other
> users beside
> > the legitimate certificate owner and the recovery agent
> user. Let me
> > know your findings..
> >
> > Cheers,
> > Arley Silveira.
> > Sénior Systems Engineer
> > Cisco VPN/Firewall Specialist, CCNA, MCSE Security MCSA,
> > MCP+I, Security+,
> > iNET+, OCP, CIWA
> >
> >
> >
> > -----Original Message-----
> > From: Dwight Jones [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 01, 2006 8:50 PM
> > To: [email protected]
> > Subject: Questions regarding EFS
> >
> > Ok, heres the situation. I already went thru the process
> of setting
> > up efs on a 2003 remote server and can access the files.
> What I want
> > to know is if it is possible to use the command line to
> encrypt, and
> > then give access to the shared file. I know you use cipher to
> > encrypt/decrypt, but is there a way to add an additional
> user to the
> > access list of the shared encrypted file.
> >
> >
> >
> >
> >
> >
> > This email and any files transmitted with it are solely
> intended for
> > the use of the
> > addressee(s) and may contain information that is confidential and
> > privileged. If you receive this email in error, please advise us by
> > return email immediately.
> > Please also disregard the contents of the email, delete it
> and destroy
> > any copies immediately.
> >
> >
> > --------------------------------------------------------------
> > -------------
> > --------------------------------------------------------------
> > -------------
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.375 / Virus Database: 268.1.1/273 - Release
> > Date: 02/03/2006
> >
> >
>
>
> --------------------------------------------------------------
> -------------
> --------------------------------------------------------------
> -------------
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 268.1.1/273 - Release
> Date: 02/03/2006
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 268.1.2/274 - Release
> Date: 03/03/2006
>
>
>
> --------------------------------------------------------------
> -------------
> --------------------------------------------------------------
> -------------
>
---------------------------------------------------------------------------
---------------------------------------------------------------------------
