Rolig nu
her er løsningen:
Med venlig hilsen, Lars
www.complex-data.dk www.pc-doktoren.dk
Tlf: 48188551 Fax: 48188551 Hotline:40188551 alle dage 7oo-22oo
kompetence koster penge - inkompetence koster MANGE penge.
5-Minute Security Advisor - Recovering Encrypted Data Using EFS
So your users have discovered the wonders of the Encrypting File
System (EFS) and have decided to remove all but the most innocuous
documents from the public's eye. One of your users—let's call him
Bob-- is having a hard time decrypting his draft of the important
corporate memo that he needs to send out in an hour. Minutes later,
you receive a call from the CFO, who just received a new laptop and
can no longer decrypt her financial reports. You take an additional
two aspirin, but they are not helping.
To understand what causes these stumbling blocks—and how to fix
them--let's take a look at EFS and how it encrypts and decrypts files.
How EFS recovery works
EFS uses both public key ( asymmetric) encryption and symmetric
encryption. Asymmetric encryption is an encryption scheme that uses
two different keys, one to encrypt the data and the other to decrypt
it. Likewise, in symmetric encryption you can use the same key to both
encrypt and decrypt the data. Symmetric encryption is more difficult
to manage securely than public-key encryption because no aspect of the
encryption scheme (especially the key!) can be made public. However,
symmetric encryption is much easier on the processor, because it
occurs at roughly 100 to 1,000 times faster than asymmetric
encryption. EFS combines both methods to give good performance and
strong security at the same time.
When a new file is encrypted, the EFS service places an exclusive lock
on the file and generates a File Encryption Key (FEK). The FEK is a
symmetric key and, as such, it can be used to both encrypt and decrypt
the file. The FEK is used for only that file. Once the FEK is
generated, the file is encrypted. Then EFS locates the user's public
key, which it uses to encrypt the FEK, and stores the encrypted FEK in
a Data Decryption Field (DDF) in the header of the encrypted file.
When a user wants to decrypt the file, EFS retrieves the user's
private key. It then uses the private key to decrypt the FEK, located
in the DDF of the file header, and finally decrypts the file with the
FEK.
Note that the File Encryption Key is not directly tied to the user. In
fact, EFS can store multiple DDFs in a file's header, which will allow
multiple users to decrypt the file. Each DDF contains the same key
encrypted with a different user's public key.
Action Some sensitive data may still be exposed via the system's page
file. This is easy to fix, though: on laptops, turn off hibernation,
and make sure that Windows wipes the pagefile when the machine is shut
down.
Data Recovery Agents
In addition to storing DDFs, EFS also stores a Data Recovery Field
(DRF) for each user account that is designated as a Data Recovery
Agent (DRA). For our purposes, a DDF and a DRF behave identically,
except that the DDF is determined at the level of the file but all
files on the local computer or domain have the same DRFs. This
behavior allows a trusted administrator to decrypt files even if users
lose their primary key. In Windows XP, DRAs are no longer required for
EFS. The FEK resides only in the DDF and DRF fields of the file's
header. If the file has only one DDF field and no DRF fields, only the
user can decrypt the file. Although this arrangement is extremely
secure, it is dangerous. If users lose their private key, the file is
lost.
To adequately protect your data, you should be using at least one DRA.
This is automatic with Windows 2000 domain computers; if you're not
using a Windows domain, you can still designate DRAs for EFS files by
following these instructions.
Backing up encrypted data
Backing up the encrypted files is as easy as backing up any other
file. Because the FEK is stored with the file, you don't need to take
any special precautions when you back up the file. However, you won't
be able to decrypt the file if you don't restore it to a domain or
local computer where authorized users can access their private keys.
It is also important to back up public/private key pairs and the
public key certificate. The public key and public key certificate are
stored in \username\Application Data\
Microsoft\SystemCertificates\My\Certificates folder of the user
profile. The private key is stored in the \Documents and
Settings\username\Application Data\Microsoft\Crypto\RSA folder. Like
all data stored in the RSA folder, the private key is encrypted with
the user's master key. Because the key pair and certificate are stored
within the user profile, they are backed up when the profile is backed
up.
Additionally, key pairs and certificates—including any DRA keys—can be
exported to removable media and stored in a secure location. Note that
anyone who has a DRA's keys can decrypt anything that the DRA can
decrypt. Thus, it is imperative that these keys, and their backup
media, be kept in a safe place.
Restoring user access to data
Recovery access is controlled by the recovery policy in effect on the
computer where the data being recovered is stored. For standalone
computers that aren't part of a domain, you set the policy on the
local computer. If your computer is in a domain, you can set the
domain EFS recovery policy via the Group Policy mechanism; this
controls who has permission to act as a recovery agent for computers
throughout the domain. In any case, when a user cannot decrypt a file,
it's because they don't have access to their private key. The best
resolution to this problem is to reunite users with their keys
whenever possible. You do this by either restoring their user profile
or by importing their keys and certificate. Once the users can access
their keys, they will be able to retrieve the FEK by decrypting their
DDF within the file. If there is no valid backup of the user's key,
then a data recovery agent can either import the key to the user's
computer or restore the encrypted file to a computer where the DRA key
pair is stored to decrypt the file for the user. In order for this to
work, you may need to use the efsinfo utility to figure out who the
designated DRAs for the file are.
If you cannot restore the user's keys, and you have access to the DRA
keys, the actual process of recovery is very straightforward: move the
file to a machine that has the DRA's private key, find the file in
Explorer, right-click it to open its Properties dialog, switch to the
General tab, click the Advanced button, and clear the "Encrypt
contents to secure data" checkbox. That's all you have to do!
Armed with this new information, you can stroll down the hall to the
CFO's office, where you discover that she is logging on to her local
workstation without a domain account. Realizing that her key was
stored in her old local profile, you call IT to see if her old laptop
is still available. Unfortunately, it has already been wiped out.
Because the CFO is impatient and doesn't want to wait for you to
restore her backed up laptop to get recover her profile, you load your
DRA keys on her laptop and decrypt the files for her. While you're at
it, you ensure that she will be logging on to the domain from now on.
You then saunter down to the memo writer's cube and find out that his
profile has been corrupted. Another call to IT gets his profile
restored, which allows him to send his memo out almost on time! You
return to your desk and promptly submit your request for a raise.
If you want more information on how EFS recovery works, and the best
way to design an EFS recovery strategy that meets your needs, Check
out the Data Protection and Recovery Whitepaper at
http://www.microsoft.com and Chapter 17 of the Windows XP Resource
Kit.
On Sat, 26 Jul 2003 13:12:41 +0200, "TJE" <TJE@tje.com> wrote:
>Hejsa!
>
>Før jeg hopper skrigende ud af vinduet, så ville jeg lige se om der var
>nogen hér der kunne hjælpe mig med et rigtigt møg-problem, jeg har givet
>totalt op på...
>
>Ok, før jeg tog på ferie tænkte jeg at jeg vile være smart og kryptere nogle
>private data med EFS, i tilfælde af indbrud e.lign. Så kommer jeg hjem, og
>alt virker fint indtil jeg installerer Virtual Machine, hvorefter jeg ikke
>kan åbne de filer jeg krypterede. (Min idiot bank insisterede på at jeg
>skulle indstallere VM!)
>
>Det hele gik lidt hurtigt, og ja, jeg har hul i hovedet, så jeg fik aldrig
>gemt en kopi af nøglen, men følgende er stadig gældende:
>
>- samme computer
>- samme bruger
>- samme password (i.e. kender det password nøglen er lavet med)
>
>Jeg har forsøgt alt muligt - slette certificates, lave nye, læst 'alt' om
>EFS, med andre ord, prøvet stort set alt... Da det er første gang jeg roder
>med EFS, så kan jeg roligt sige at jeg er HELT NY i den sammenhæng, og er
>generelt ikke den store haj til ting og sager der har med kryptering at
>gøre!
>
>System: XP sp1...
>
>Jeg håber seriøst at der er nogen der gider/kan hjælpe, så jeg kan fortsætte
>mit liv, omend med røde kinder! ;-P
>
>/TJE
>