Re: EFS Private Keys
From: Drew Cooper [MSFT] (dcoop_at_online.microsoft.com)
Date: 12/31/03
- Next message: Drew Cooper [MSFT]: "Re: NTLM"
- Previous message: Shawn Rabourn \(MS\): "Re: decrypt files after lost pub/priv keys - possible?"
- In reply to: Steven Umbach: "Re: EFS Private Keys"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 30 Dec 2003 17:50:55 -0800
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. "Steven Umbach" <n9zrou@nscomcast.com> wrote in message news:AY6Ib.73134$VB2.145346@attbi_s51... > 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 > > > "Drew Cooper [MSFT]" <dcoop@online.microsoft.com> wrote in message > news:eC0iaXozDHA.3468@TK2MSFTNGP11.phx.gbl... > > 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. > > > > > > "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message > > news:QDmHb.672951$Tr4.1688097@attbi_s03... > > > 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 > > > > > > > > > "Robert" <bwooster1.nospam@yahoo.com> wrote in message > > > news:OM7pCLDzDHA.1740@TK2MSFTNGP12.phx.gbl... > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
- Next message: Drew Cooper [MSFT]: "Re: NTLM"
- Previous message: Shawn Rabourn \(MS\): "Re: decrypt files after lost pub/priv keys - possible?"
- In reply to: Steven Umbach: "Re: EFS Private Keys"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
