Re: EFS and Biometrics? Other options?

From: Laura A. Robinson (larobins@bellatlantic.net)
Date: 08/21/01 

Message-ID: <032201c12a5c$dea15f40$0b00010a@lauradominion.com>
From: "Laura A. Robinson" <larobins@bellatlantic.net>
To: "Russell Aspinwall" <russell.aspinwall@flomerics.co.uk>, <info@cascadeone.com>
Subject: Re: EFS and Biometrics?  Other options?
Date: Tue, 21 Aug 2001 12:18:08 -0400

No. There is no password involved in EFS. Encryption/decryption is
transparent and is based on the user's keys, which are kept in a protected
store in the user profile by default, but can also be stored on smart cards,
floppies, etc. Additionally, no file can be encrypted unless there is a
specified recovery agent and available keys.

In a nutshell, encryption works like this:

When a user encrypts a file, a randomly generated file encryption key (FEK)
is generated, which is different for each file. The user's public key is
used to encrypt the FEK, and the user's private key is used to decrypt the
FEK. The encrypted FEK is stored in the data decryption field (DDF) for the
file. Another copy of the FEK is encrypted with the public key of the
designated recovery agent and stored in the data recovery field (DRF) for
the file.

If the logged on user does not have a public/private key pair, one is
generated on the fly and stored in the user's profile on the hard drive. If
the user's machine is not a member of a domain, the local administrator
account is the designated recovery agent for all files encrypted on that
machine (this account's key pair is also automatically generated). In a
domain environment, the default recovery agent is the domain's administrator
account. (This can, and typically should, be customized via group policy)

To decrypt the file, the machine must be able to access either the user's
private key or the recovery agent's private key. If the user's private key
is stored on a smart card or a floppy, for example, no files can be
decrypted by the user without the presence of the storage medium containing
the private key that corresponds to the public key that was used to encrypt
the FEK. As long as the user's keys *are* available, decryption is a
completely transparent process to the user. The appropriate private key is
automatically retrieved and used to decrypt the FEK, the FEK is then used to
decrypt the file, and the user works as normal.

I could go into a big spiel about design and implementation considerations
for EFS, but basically, it boils down to this:

 Since no file can be encrypted without at least two designated entities who
can decrypt the file, no, it is not possible for a virus to render an
encrypted file irretrievable in a properly implemented EFS infrastructure.
In order to render the file irretrievable, the virus would not only have to
destroy the user's private key, but the recovery agent's private key, as
well. This in itself would be *extremely* difficult, and in a domain
environment, the virus would have to destroy keys stored in the domain as
well as on the user's machine/smart card/floppy/whatever. Even *if* a virus
were to somehow destroy the keys for both the user and the recovery agent on
a user's hard drive on a machine that is not a member of a domain (which
would, in this case, be the local administrator account), the keys could be
retrieved from backup.

In a properly implemented environment, you would already have generated
public/private key pairs for your users in the domain, as well as those for
recovery agents that you designate, and you would have backups of both. You
would also store the user's keys on some other media than their hard drive,
because if the keys are stored on the hard drive of the machine, then all
that would be required to decrypt the files would be a successful logon as
the user in whose profile the keys are stored (or a logon as the local
administrator if the machine is not a domain member).

Hope this helps,

Laura A. Robinson
Technical Instructor/Consultant
MCT, MCSE, CLI, PCLP
IntelliMark Pennsylvania Division
http://www.intellimark-it.com
lrobinson@intellimark-it.com

----- Original Message -----
From: "Russell Aspinwall" <russell.aspinwall@flomerics.co.uk>
To: <info@cascadeone.com>
Cc: <focus-ms@securityfocus.com>
Sent: Tuesday, August 21, 2001 4:04 AM
Subject: Re: EFS and Biometrics? Other options?

> Hi,
>
> Could EFS be used by a virus to encypt the hdd with a password unknown
> to the user so rendering the machine usable by the user?
>
>
>
> info@cascadeone.com wrote:
>
> > I am attempting to secure confidential information on remote machines
(laptops). I know there are many ways to encrypt the entire HDD...
> >
> > EFS is offered by Microsoft, and of course comes default with the 2K
install. Does EFS have any support for biometrics?
> >
> > What I am really looking for is a solution that will:
> > 1. logon via a biometric device
> > 2. automatic transparent encrypt/decrypt entire HDD
> > 3. no challenge (password, biometric) for encryption/decryption
> >
> > Has anyone done this type of thing with EFS, using Biometric logon? Has
anyone done this with another product (or combination of products)?
> >
> > TIA,
> > 5of3
> >
> > info@cascadeone.com
> >
> >
> >
>

Relevant Pages

  • Re: Event ID 6032
    ... see who is the recovery agent by opening the properties of an encrypted file ... decrypt the files by reversing the process in which you encrypted them. ... to encrypt, you should just be able to un-click the box to decrypt. ... and import the recovery agent certificate from the server. ...
    (microsoft.public.windows.server.sbs)
  • Re: Info regd Hard Disk Encryption required.
    ... Another similar solution is to run a virtual machine and encrypt its entire ... EFS can handle that. ... > An alternative to EFS is the older PGP Disc. ... >> decrypt it while the system is booting. ...
    (microsoft.public.win2000.security)
  • Re: efs and "encryption" overall... help?
    ... To be absolutely sure that an attacker can not access EFS encrypted files ... stronger encryption to encrypt EFS files, not that it would be easy to crack ... Pro that more then one user may be able to decrypt the file if the original ... > first encryption a certificate is created that is used to decrypt those ...
    (microsoft.public.windows.server.networking)
  • Re: recovery agent keys/certs
    ... To decrypt a file two things are needed a) read permissions ... Create the recovery agent before users encrypt files so that you ... Backing up EFS certificates will allow for later ...
    (microsoft.public.windowsxp.security_admin)
  • RE: Laptop Security - Microsoft EFS
    ... When you use EFS, ... who can also decrypt the respective persons info. ... If the private key for the recovery agent sits on the very computer you are ... trying to protect, then you may as well not encrypt anything, because it's ...
    (Security-Basics)