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:en3py@itvc.net]
Sent: Saturday, March 04, 2006 3:38 AM
To: focus-ms@securityfocus.com
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: en3py@itvc.net #
##############################
-----Messaggio originale-----
Da: Laura A. Robinson [mailto:larobins@bellatlantic.net]
Inviato: sabato 4 marzo 2006 1.51
A: 'Sebastian "En3pY" Zdrojewski'; focus-ms@securityfocus.com
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:en3py@itvc.net]
Sent: Friday, March 03, 2006 1:22 PM
To: focus-ms@securityfocus.com
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: en3py@itvc.net
________________________________
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:arley.leal@sonae.com]
Inviato: giovedì 2 marzo 2006 10.29
A: Dwight Jones; focus-ms@securityfocus.com
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:djones@filink.com]
Sent: Wednesday, March 01, 2006 8:50 PM
To: focus-ms@securityfocus.com
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
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
