Re: EFS and DRA. Admin unable to decrypt

From: drunkardswalk@earthlink.net
Date: 02/19/03 

From: drunkardswalk@earthlink.net
Date: Wed, 19 Feb 2003 14:53:47 -0700

I'm guessing this is directed at me, so I'll reply.

On Sun, 16 Feb 2003 18:15:38 -0800, "yoggie" <yoggie@hotmail.com>
wrote:

>Dude ,
>
>I fully agree with all you've said except for this part
>
>"the certificate alone can't do anything except encrypt or
>verify. It can't decrypt on its own" ---
>
>Considering that XP/2000 use the Symmetric Encryption
>Method were the same key pair is used for
>encryting/decyrpting data >
>
>So the certificate is used to identify the user & the
>credentials of the key but the certificate itself cannot
>decrypt/encrypt its the private KEY which does it all, u
>will notice if u export the key & keep the certificate
>then another new key will be generated next time another
>file is encrypted
>
>Yoggie.

I think we're talking at cross-purposes here. Time for definition of
terms. The first time a user tries to encrypt a file, if he has no
EFS encryption key, the system will generate one for him. Actually,
it generates a public key/private key pair.

Now, for each file the user encrypts, the system generates a random
file-encryption key (FEK in MS parlance), which it uses a in a
symmetric encryption algorithm (DESX by default, I think, 3DES if
you've set the system to use FIPS 160 in your security policies) to
encrypt the file. Then it uses the user's *public* key (and any RA's
public key) to encrypt the FEK using a non-symmetric, public-key
encryption algorithm (not sure which, since my Platform SDK is
scrubbed right now, but I'd guess RSA 4). The encrypted FEK is stored
with the encrypted file. This is the part I was referring to in my
earlier post.

Then, when the user wants access to the encrypted file, the system
uses his *private* key to decrypt the file's FEK, then uses the
decrypted FEK to decrypt the file itself. The RA can also decrypt the
file using *his* private key, because his public key was incorporated
into the public-key encryption of the FEK.

Every user has a public key/private key pair. A user certificate
*isn't* either of these, although it can (but doesn't have to) contain
the user's public key. (Apparently, though, MS *does* use a
certificate in the store as the means of containing the public key;
I'll want to have another look at the Platform SDK before proclaiming
that as Imperial Ukase.) The purpose of the certificate is to
associate (via digital signing) a user's public key with his identity.
In other words, it proves to the system that the public key is, in
fact, the one owned by the user, and which that user's private key
goes with.

So it's the user's private key, not the certificate, that's used in
the non-symmetric algorithm to encrypt a file's file encryption key.
And each encrypted file has a unique FEK generated at the time of
encryption.

Now, when you create an RA, you *must* export and delete his *private*
key. Else, you may as well not have used EFS, because a halfway
intelligent hacker who gains physical access to your system can almost
trivially crack your encrypted files if that key is on the system,
particularly if SYSKEY is running in mode 1 (the default). If you
want the details of the hack, again, the book to get is "Hacking
Windows 2000 Exposed," 3rd ed. Obviously, to use the RA to recover
files, you'll have to temporarily re-import his private key, since
it's the private key that's used for decryption in the non-symmetric
algorithm. So long as his public key was on the system while users
were encrypting files, it will have been incorporated into the
encryption hashes for all the FEKs, and so, his private key will
decrypt them.

One last bit of problematic nomenclature regards the file extensions
.CER and .PFX. These aren't, as some texts might lead you to think,
the public and private keys, respectively (or both keys, perhaps, in
the case of .PFX files). These are merely standard file formats for
certificates. The .CER files are in X.509 format, while the .PFX are
in Personal Information Exchange PKCS #12 format. Which you use (or
one of several others, as well) is up to you when you export. The
most common way you'll likely choose to export, given how the
Certificates.msc plug-in works, is with the certificate (and public
key) in a .CER file, and both the public and private keys in a .PFX
file. That's so common a way to go that that's why so many texts and
forum posts get confused on the topic.

So, with that major chunk of exposition behind me (and I apologize in
advance for any faux pas, since I'm totally wasted and pulling this
stuff off the top of my head <g>), I think you'll agree we're really
in agreement. Agreed? Yeah? Hmmn? In agreement?

Lord God, I think I'm channelling Daffy Duck. Gad.

Reid

Relevant Pages

  • Re: DRA is Decrypting Files when it shouldnt be!!!
    ... > EFS is allowing the RA to decrypt 200 files that were encrypted BEFORE an RA ... > encryption to get the RA to decrypt encrypted files. ... the default RA certificate was used. ... certificate and private key only when needed). ...
    (microsoft.public.windowsxp.security_admin)
  • Key Recovery and Decryption
    ... I had the encryption key backed up on ... and designating a Data Recovery Agent. ... to install the Administrator's Data Recovery Certificate ... corresponding private key but if I try to export this ...
    (microsoft.public.windowsxp.security_admin)
  • Re: securing folder on external disk(s)
    ... > where the encryption comes in I think). ... > If, as you advices, I'd use the EFS. ... The key is a self-signed certificate that is generated the first time ... them _as long as the private key is unknown_. ...
    (microsoft.public.security)
  • Re: EFS...can it be given to a group or folder ..win2003
    ... If you export a certificate from the Certificates mmc snapin and have the ... private key present, you can export with private key - that will generate a ... This posting is provided "AS IS" with no warranties, and confers no rights. ... >>> encryption, ...
    (microsoft.public.windows.file_system)
  • Re: question about gpg
    ... finding the private key. ... If that were true, public-key cryptography would be weak, ... because the encryption key is, after all, public. ... then I can figure out the plaintext by ...
    (comp.os.linux.security)