EFS Private Keys

[Robert]

I understand that in W2K the FEK is protected by the user's private key.
All well and good, but where is the private key stored, and how is *it*
protected??? I assume it is stored on disk or in the registry someplace.
Is there some super-secret OS key that is used to protect all private keys?

Can anyone explain it in such a way that you don't have to be a MCSE to
understand it?

Thanks for any clarity.

Bob

 

[Zardox]

-----Original Message-----
I understand that in W2K the FEK is protected by the user's private key.
All well and good, but where is the private key stored, and how is *it*
protected??? I assume it is stored on disk or in the registry someplace.
Is there some super-secret OS key that is used to protect all private keys?

Can anyone explain it in such a way that you don't have to be a MCSE to
understand it?

Thanks for any clarity.

Bob

Hi,

this informations are from :
http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/prodtechnol/windows2000serv/reskit/distsys/par
t2/dsgch15.asp


Where Private key reside:
Private keys for the Microsoft RSA-based CSPs, including
the Base CSP and the Enhanced CSP, reside in the user
profile under RootDirectory\Documents and
Settings\<username>\Application Data\Microsoft\Crypto\RSA.
In the case of a roaming user profile, the private key
resides in the RSA folder on the domain controller and is
downloaded to the user's computer until the user logs off
or the computer is restarted.

How is it protected:
Unlike their corresponding public keys, private keys must
be protected. Therefore, all files in the RSA folder are
automatically encrypted with a random, symmetric key
called the user's master key. The user's master key is
generated by the RC4 algorithm in the Base or Enhanced
CSP. RC4 generates a 128-bit key for computers with the
Enhanced CSP (subject to cryptography export restrictions)
and a 56-bit key for computers with only the Base CSP
(available for all Windows 2000 computers). The master key
is generated automatically and is renewed periodically. It
encrypts each file in the RSA folder automatically as the
file is created.

bye,
Zardox.

 

[David Cross [MS]]

private keys are protected by DPAPI:
http://msdn.microsoft.com/library/d...-us/dnsecure/html/windataprotection-dpapi.asp

 

[Steven L Umbach]

The user and recovery agent private EFS keys are stored in the associated user
profile and available through the mmc certificate snapin. As other posts described
the private keys are protected however the key to the private key is the user's
password, so ultimately the private key is only as secure as the user's password as
long as it is still on the computer. Worse yet, in W2K a users password can be reset
by someone gaining administrator access or if the administrator's password could be
reset , and assuming it is the recovery agent on a non domain machine, then access
could be gained to the user/recovery agent account and hence access to the EFS
encrypted files. It is a very trivial process to reset the administrator's password
on a W2K machine with free software from the internet.

XP Pro, improved security by not requiring or creating a recovery agent by default
and also by not allowing access to a user's EFS private key if the password was
"reset" as can be done in Computer Management/local users and groups by accessing a
user account and resetting it where the current password does not need to be known to
an administrator. That may not stop someone with physical access from cracking a
user's password with a program such as LC 4 http://www.atstake.com/products/lc/ and
then gaining access to encrypted EFS files.

To protect your EFS files when physical security can not be assured, a user needs to
export and delete their private EFS key and that of any recovery agent on the local
computer and secure them away from the computer. When that is done the EFS files are
secure for most intents and purposes by today's standards and XP pro even has much
stronger encryption available for EFS. However, it is possible that there may be
hidden clear text copies or fragments of EFS files - particularly if a program uses a
temporary folder such as Office in which case you want to also encrypt the uses temp
folder. MS also recommends that the cipher /w command be used to remove clear text
copies of encrypted files. It is always important to have backups of your EFS private
keys, as it is fairly easy to lose access to your files permanently if you don't. See
the links below for more info. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;223316
http://is-it-true.org/nt/nt2000/atips/atips24.shtml
http://support.microsoft.com/default.aspx?scid=kb;en-us;315672

 

[Robert]

Thanks. Very helpful site. I was wondering if you could clarify something
for me. In the article it says:

"... the logical step is for DPAPI to use a user's logon password, which it
does, in a way. DPAPI actually uses the user's logon credential."

What API(s) do I use to gain access to the user's logon credential? (Let's
say I want to use the credential directly to provide some additional
security services to an application.)

Thanks again.

Bob

------------------------------------------

private keys are protected by DPAPI:
http://msdn.microsoft.com/library/d...-us/dnsecure/html/windataprotection-dpapi.asp

--


David B. Cross [MS]

--
This posting is provided "AS IS" with no warranties, and confers no rights.

http://support.microsoft.com

I understand that in W2K the FEK is protected by the user's private key.
All well and good, but where is the private key stored, and how is *it*
protected??? I assume it is stored on disk or in the registry someplace.
Is there some super-secret OS key that is used to protect all private keys?

Can anyone explain it in such a way that you don't have to be a MCSE to
understand it?

Thanks for any clarity.

Bob

 

[Robert]

Thanks... just goes to show you, security truly is relative. The best you
can do is strive to make the difficulty of getting to the data more costly
than the value of the data itself.

----------------------------------

The user and recovery agent private EFS keys are stored in the associated user
profile and available through the mmc certificate snapin. As other posts described
the private keys are protected however the key to the private key is the user's
password, so ultimately the private key is only as secure as the user's password as
long as it is still on the computer. Worse yet, in W2K a users password can be reset
by someone gaining administrator access or if the administrator's password could be
reset , and assuming it is the recovery agent on a non domain machine, then access
could be gained to the user/recovery agent account and hence access to the EFS
encrypted files. It is a very trivial process to reset the administrator's password
on a W2K machine with free software from the internet.

XP Pro, improved security by not requiring or creating a recovery agent by default
and also by not allowing access to a user's EFS private key if the password was
"reset" as can be done in Computer Management/local users and groups by accessing a
user account and resetting it where the current password does not need to be known to
an administrator. That may not stop someone with physical access from cracking a
user's password with a program such as LC 4

http://www.atstake.com/products/lc/ and

 

[David Cross [MS]]

Depends what you want to do... you could example call CryptProtectData if
you want to encrypt other data using the user's credential... but you cannot
access the credential directly in clear form.

--


David B. Cross [MS]

--
This posting is provided "AS IS" with no warranties, and confers no rights.

http://support.microsoft.com

Thanks. Very helpful site. I was wondering if you could clarify something
for me. In the article it says:

"... the logical step is for DPAPI to use a user's logon password, which it
does, in a way. DPAPI actually uses the user's logon credential."

What API(s) do I use to gain access to the user's logon credential? (Let's
say I want to use the credential directly to provide some additional
security services to an application.)

Thanks again.

Bob

------------------------------------------

private keys are protected by DPAPI:

http://msdn.microsoft.com/library/d...-us/dnsecure/html/windataprotection-dpapi.asp

--


David B. Cross [MS]

--
This posting is provided "AS IS" with no warranties, and confers no rights.

http://support.microsoft.com

I understand that in W2K the FEK is protected by the user's private key.
All well and good, but where is the private key stored, and how is *it*
protected??? I assume it is stored on disk or in the registry someplace.
Is there some super-secret OS key that is used to protect all private keys?

Can anyone explain it in such a way that you don't have to be a MCSE to
understand it?

Thanks for any clarity.

Bob

 

[Drew Cooper [MSFT]]

Steven - you pretty much covered everything, but I wanted to add a few
comments:

Resetting the password doesn't work if offline syskey is used. I believe we
fixed that in Win2k SP1. (Yeah - hardly anyone uses syskey in password or
floppy mode, but there is still a means of mitigation.) The one hole that
remained was anything encrypted in machine context. It's trivial to "become
the machine" with physical access, so anything encrypted in machine context
is for all practical purposes still plaintext. This same exploit exists on
XP and Windows 2003.

Plaintext detritus can exist on the hard drive for files that were
originally plaintext then converted to encrypted files. "cipher /w" does a
good job of cleaning up the old plaintext, but be warned that it is only a
"best effort" as is any other disk-scrubbing tool that runs from within the
OS. Any clusters that are in use can't be scrubbed. Those clusters may
contain some of the plaintext.

Ultimately the encrypted files are as secure as a user's password. A strong
password (or using a smartcard for logon) is important to ensure that EFS
isn't easily cracked.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

The user and recovery agent private EFS keys are stored in the associated user
profile and available through the mmc certificate snapin. As other posts described
the private keys are protected however the key to the private key is the user's
password, so ultimately the private key is only as secure as the user's password as
long as it is still on the computer. Worse yet, in W2K a users password can be reset
by someone gaining administrator access or if the administrator's password could be
reset , and assuming it is the recovery agent on a non domain machine, then access
could be gained to the user/recovery agent account and hence access to the EFS
encrypted files. It is a very trivial process to reset the administrator's password
on a W2K machine with free software from the internet.

XP Pro, improved security by not requiring or creating a recovery agent by default
and also by not allowing access to a user's EFS private key if the password was
"reset" as can be done in Computer Management/local users and groups by accessing a
user account and resetting it where the current password does not need to be known to
an administrator. That may not stop someone with physical access from cracking a
user's password with a program such as LC 4

http://www.atstake.com/products/lc/ and

 

[Steven Umbach]

Hi Drew.

Thanks a bunch for the information. I was not sure about the impact of using
syskey was to EFS in W2K, that is good to know. Is there much of a risk in
plaintext copies of files that are created and then directly saved into an
encrypted folder [as per best practices] such as from Excel or Word assuming the
users temporary folder is also encrypted? Thanks -- Steve

Steven - you pretty much covered everything, but I wanted to add a few
comments:

Resetting the password doesn't work if offline syskey is used. I believe we
fixed that in Win2k SP1. (Yeah - hardly anyone uses syskey in password or
floppy mode, but there is still a means of mitigation.) The one hole that
remained was anything encrypted in machine context. It's trivial to "become
the machine" with physical access, so anything encrypted in machine context
is for all practical purposes still plaintext. This same exploit exists on
XP and Windows 2003.

Plaintext detritus can exist on the hard drive for files that were
originally plaintext then converted to encrypted files. "cipher /w" does a
good job of cleaning up the old plaintext, but be warned that it is only a
"best effort" as is any other disk-scrubbing tool that runs from within the
OS. Any clusters that are in use can't be scrubbed. Those clusters may
contain some of the plaintext.

Ultimately the encrypted files are as secure as a user's password. A strong
password (or using a smartcard for logon) is important to ensure that EFS
isn't easily cracked.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

The user and recovery agent private EFS keys are stored in the associated user
profile and available through the mmc certificate snapin. As other posts described
the private keys are protected however the key to the private key is the user's
password, so ultimately the private key is only as secure as the user's password as
long as it is still on the computer. Worse yet, in W2K a users password can be reset
by someone gaining administrator access or if the administrator's password could be
reset , and assuming it is the recovery agent on a non domain machine, then access
could be gained to the user/recovery agent account and hence access to the EFS
encrypted files. It is a very trivial process to reset the administrator's password
on a W2K machine with free software from the internet.

XP Pro, improved security by not requiring or creating a recovery agent by default
and also by not allowing access to a user's EFS private key if the password was
"reset" as can be done in Computer Management/local users and groups by accessing a
user account and resetting it where the current password does not need to be known to
an administrator. That may not stop someone with physical access from cracking a
user's password with a program such as LC 4

http://www.atstake.com/products/lc/ and

then gaining access to encrypted EFS files.

To protect your EFS files when physical security can not be assured, a user needs to
export and delete their private EFS key and that of any recovery agent on the local
computer and secure them away from the computer. When that is done the EFS files are
secure for most intents and purposes by today's standards and XP pro even has much
stronger encryption available for EFSfiles permanently if you don't. See
the links below for more info. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;223316
http://is-it-true.org/nt/nt2000/atips/atips24.shtml
http://support.microsoft.com/default.aspx?scid=kb;en-us;315672

 

[Drew Cooper [MSFT]]

Not to dodge the question, but I'm not sure how to measure the level of
risk.

Of course "cipher /w" should be used. Until a cluster is reused, that data
is on the disk. Anyone who can read the volume directly (admins or anyone
with physical access) can see the data otherwise.

Why "cipher /w" is a "best effort":
It's possible to have a cluster that was in use that couldn't be wiped.
There are two ways I can think of to hit this problem:
1. Something is holding a handle open to a "deleted" file that's not really
deleted yet. DeleteFile() returns success when it has successfully *marked*
a file for deletion. When the last handle is dropped the file will finally
be deleted. A common culprit here is antiviral software that examines all
of your disk activity.
2. Small files can live in the MFT and that cluster could be in use because
of another MFT entry's activity. The default size of an MFT entry is 1 KB.
I don't remember the last time I saw an Excel or Word file that was that
small. I just created a new (empty) .doc. It was bigger than 10 KB. I'm
pretty sure that the max size of an MFT entry is 4 KB.


Regarding encrypted temp dir . . .
- We used to recommend that as a best practice but don't now. Too many
nasty side-effects. One of them is that lots of apps install by extracting
files into the temp dir, then plopping their files into place. If the any
piece of the app needs to run in a user context other than the user who
installed it, it fails - doesn't have the key pair to open the file.
- I don't remember what the Excel guys do, but I know that Word creates temp
files in the current directory now. As long as you do your work in an
encrypted dir, all versions of the docs are encrypted.


Enough of my overexplanations for now. If you need more detail, please let
me know.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Drew.

Thanks a bunch for the information. I was not sure about the impact of using
syskey was to EFS in W2K, that is good to know. Is there much of a risk in
plaintext copies of files that are created and then directly saved into an
encrypted folder [as per best practices] such as from Excel or Word assuming the
users temporary folder is also encrypted? Thanks -- Steve

Steven - you pretty much covered everything, but I wanted to add a few
comments:

Resetting the password doesn't work if offline syskey is used. I believe we
fixed that in Win2k SP1. (Yeah - hardly anyone uses syskey in password or
floppy mode, but there is still a means of mitigation.) The one hole that
remained was anything encrypted in machine context. It's trivial to "become
the machine" with physical access, so anything encrypted in machine context
is for all practical purposes still plaintext. This same exploit exists on
XP and Windows 2003.

Plaintext detritus can exist on the hard drive for files that were
originally plaintext then converted to encrypted files. "cipher /w" does a
good job of cleaning up the old plaintext, but be warned that it is only a
"best effort" as is any other disk-scrubbing tool that runs from within the
OS. Any clusters that are in use can't be scrubbed. Those clusters may
contain some of the plaintext.

Ultimately the encrypted files are as secure as a user's password. A strong
password (or using a smartcard for logon) is important to ensure that EFS
isn't easily cracked.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

The user and recovery agent private EFS keys are stored in the

associated
user

profile and available through the mmc certificate snapin. As other

posts
described

the private keys are protected however the key to the private key is

the
user's

password, so ultimately the private key is only as secure as the

user's
password as

long as it is still on the computer. Worse yet, in W2K a users

password
can be reset

by someone gaining administrator access or if the administrator's

password
could be

reset , and assuming it is the recovery agent on a non domain machine, then access
could be gained to the user/recovery agent account and hence access to

the
EFS

encrypted files. It is a very trivial process to reset the

administrator's
password

on a W2K machine with free software from the internet.

XP Pro, improved security by not requiring or creating a recovery

agent by
default

and also by not allowing access to a user's EFS private key if the password was
"reset" as can be done in Computer Management/local users and groups

by
accessing a

user account and resetting it where the current password does not need

to
be known to

an administrator. That may not stop someone with physical access from cracking a
user's password with a program such as LC 4

http://www.atstake.com/products/lc/ and

then gaining access to encrypted EFS files.

To protect your EFS files when physical security can not be assured, a user needs to
export and delete their private EFS key and that of any recovery agent

on
the local

computer and secure them away from the computer. When that is done the

EFS
files are

secure for most intents and purposes by today's standards and XP pro

even
has much

stronger encryption available for EFSfiles permanently if you don't. See
the links below for more info. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;223316
http://is-it-true.org/nt/nt2000/atips/atips24.shtml
http://support.microsoft.com/default.aspx?scid=kb;en-us;315672


I understand that in W2K the FEK is protected by the user's private key.
All well and good, but where is the private key stored, and how is *it*
protected??? I assume it is stored on disk or in the registry someplace.
Is there some super-secret OS key that is used to protect all

private
keys?

Can anyone explain it in such a way that you don't have to be a MCSE to
understand it?

Thanks for any clarity.

Bob

 

[Steven L Umbach]

Thanks again Drew. That information was very helpful. The risk seems very small, but
it is good to know. I know a lot of users underestimate the amount of information
that can be extracted from a storage device, particularly if no effort is made to use
a utility to periodically "scrub" the disk and scramble old filenames if they have
what they consider is sensitive information. --- Steve

Not to dodge the question, but I'm not sure how to measure the level of
risk.

Of course "cipher /w" should be used. Until a cluster is reused, that data
is on the disk. Anyone who can read the volume directly (admins or anyone
with physical access) can see the data otherwise.

Why "cipher /w" is a "best effort":
It's possible to have a cluster that was in use that couldn't be wiped.
There are two ways I can think of to hit this problem:
1. Something is holding a handle open to a "deleted" file that's not really
deleted yet. DeleteFile() returns success when it has successfully *marked*
a file for deletion. When the last handle is dropped the file will finally
be deleted. A common culprit here is antiviral software that examines all
of your disk activity.
2. Small files can live in the MFT and that cluster could be in use because
of another MFT entry's activity. The default size of an MFT entry is 1 KB.
I don't remember the last time I saw an Excel or Word file that was that
small. I just created a new (empty) .doc. It was bigger than 10 KB. I'm
pretty sure that the max size of an MFT entry is 4 KB.


Regarding encrypted temp dir . . .
- We used to recommend that as a best practice but don't now. Too many
nasty side-effects. One of them is that lots of apps install by extracting
files into the temp dir, then plopping their files into place. If the any
piece of the app needs to run in a user context other than the user who
installed it, it fails - doesn't have the key pair to open the file.
- I don't remember what the Excel guys do, but I know that Word creates temp
files in the current directory now. As long as you do your work in an
encrypted dir, all versions of the docs are encrypted.


Enough of my overexplanations for now. If you need more detail, please let
me know.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Drew.

Thanks a bunch for the information. I was not sure about the impact of using
syskey was to EFS in W2K, that is good to know. Is there much of a risk in
plaintext copies of files that are created and then directly saved into an
encrypted folder [as per best practices] such as from Excel or Word assuming the
users temporary folder is also encrypted? Thanks -- Steve

Steven - you pretty much covered everything, but I wanted to add a few
comments:

Resetting the password doesn't work if offline syskey is used. I believe we
fixed that in Win2k SP1. (Yeah - hardly anyone uses syskey in password or
floppy mode, but there is still a means of mitigation.) The one hole that
remained was anything encrypted in machine context. It's trivial to "become
the machine" with physical access, so anything encrypted in machine context
is for all practical purposes still plaintext. This same exploit exists on
XP and Windows 2003.

Plaintext detritus can exist on the hard drive for files that were
originally plaintext then converted to encrypted files. "cipher /w" does a
good job of cleaning up the old plaintext, but be warned that it is only a
"best effort" as is any other disk-scrubbing tool that runs from within the
OS. Any clusters that are in use can't be scrubbed. Those clusters may
contain some of the plaintext.

Ultimately the encrypted files are as secure as a user's password. A strong
password (or using a smartcard for logon) is important to ensure that EFS
isn't easily cracked.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


The user and recovery agent private EFS keys are stored in the associated
user
profile and available through the mmc certificate snapin. As other posts
described
the private keys are protected however the key to the private key is the
user's
password, so ultimately the private key is only as secure as the user's
password as
long as it is still on the computer. Worse yet, in W2K a users password
can be reset
by someone gaining administrator access or if the administrator's password
could be
reset , and assuming it is the recovery agent on a non domain machine,
then access
could be gained to the user/recovery agent account and hence access to the
EFS
encrypted files. It is a very trivial process to reset the administrator's
password
on a W2K machine with free software from the internet.

XP Pro, improved security by not requiring or creating a recovery agent by
default
and also by not allowing access to a user's EFS private key if the
password was
"reset" as can be done in Computer Management/local users and groups by
accessing a
user account and resetting it where the current password does not need to
be known to
an administrator. That may not stop someone with physical access from
cracking a
user's password with a program such as LC 4
http://www.atstake.com/products/lc/ and
then gaining access to encrypted EFS files.

To protect your EFS files when physical security can not be assured, a
user needs to
export and delete their private EFS key and that of any recovery agent on
the local
computer and secure them away from the computer. When that is done the EFS
files are
secure for most intents and purposes by today's standards and XP pro even
has much
stronger encryption available for EFSfiles permanently if you don't. See
the links below for more info. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;EN-US;223316
http://is-it-true.org/nt/nt2000/atips/atips24.shtml
http://support.microsoft.com/default.aspx?scid=kb;en-us;315672


I understand that in W2K the FEK is protected by the user's private key.
All well and good, but where is the private key stored, and how is *it*
protected??? I assume it is stored on disk or in the registry
someplace.
Is there some super-secret OS key that is used to protect all private
keys?

Can anyone explain it in such a way that you don't have to be a MCSE to
understand it?

Thanks for any clarity.

Bob