How Does Win2k's Encrypted File System Really Work?

cyberbrian asks: "At work, I administer Windows NT 4.0 and 2000 servers and I have been researching Win 2000's EFS (Encrypted File System) and I have detected some Very Odd Behavior. I am currently leaning towards using PGP Disk instead of EFS but I really want to know what is going on here. For instance, one of the tests I made is that I backed up an encrypted file and restored it to a FAT partition. The resulting file had zero bytes. For true encryption, shouldn't there be data in the file, but scrambled according to the encryption algorythem and key file? IMHO, Microsoft may not be using encryption at all, but instead perhaps the "encryption" is actually a hidden NTFS deny/allow permission that is tied to a certificate. Has anyone tested this by trying to decrypt a EFS file under Linux? Also, I would be very interested in any URLs people could point me to where this is explained in detail."

Not Surprised

[forkspoon]

Actually I wouldn't be surprised if it was only a flag and they didn't really encrypt the data. First, when my 2000 Pro system crashed last winter, I simply reinstalled 2000 Pro onto the same drive. The new administrator account had access to all the files on the hard drive, whether they were "encrypted" or their permissions were explicitly for another group. It seems that the actual files are simply on the disk, the installed instance of the OS is what performs access control, so there is no real alteration of data with permissions or encryption. However, the compressed files were still compressed when I installed the second time.

Thanks,

Travis
[e-mail]

Re:Not Surprised

[Anonymous Coward]

I get the idea that EFS isn't really all that effective unless you have the whole ActiveDirectory PKI that goes along with it

Anyway: Here's [microsoft.com] the manual section on EFS. I don't need the karma, so someone can repost and get it.

Funny how...

[Anonymous Coward]

...you can make a baseless disparaging comment (refuted by a quick search, BTW) about MS without any backing and be marked 'interesting' for it. Try posting TRUE negatives about Linux, and you're modded down.

Loooooooooooove the moderation guys. Keep up the good work, pretty soon you'll silence all the reasonable voices.

Re:Not Surprised

[Anonymous Coward]

The data is really encrypted. It uses public key crypto, as someone else pointed out. By default, the file is encrypted to the user's key, and to the administrator's key. So assuming you didn't delete the administrator key, anyone with access to this key has access to all your encrypted files. I'm not sure if the adminstrator key is encrypted on the disk - did you use the same admin password when you reinstalled?

Re:Not Surprised

[geekopus]

I'm pretty sure this isn't true. I screwed the pooch on my installation (Note to self: Don't manually select the ACPI HAL if Windows didn't do it for you already), and ended up having to reinstall on top of the existing system. I used the exact same parameters when I reinstalled. When the machine finally came off life support and booted on it's own, I had access to everything but the encrypted files.

BTW, I don't think it's just a flag. When you use anything that can read NTFS 5.0 *besides* Win2K (the DOS NTFS drivers, etc.), the data is just junk. Even text files. I'm pretty sure. You can try it yourself if you want. You would think that they would just not honor a flag if that's all it took.

Dead Silence

[Daengbo]

I guess that people aren't jumping in head first into this one means that you've really asked a good "Ask Slashdot" question -- one that 80% of the guys can't answer. No one's even brave enough. Congrats! Oh yeah, looks like maybe I got 1st post

Re:Dead Silence

[Anonymous Coward]

I guess that people aren't jumping in head first into this one means that you've really asked a good "Ask Slashdot" question -- one that 80% of the guys can't answer. No one's even brave enough. Congrats! Oh yeah, looks like maybe I got 1st post

Or it's not a front page article, you moron.

Anyway, Windows encrypted files are encrypted against a random key per file, and the a copy of that key is encrypted against each user's public key. Their private key is used to decode it.

Encryption is weak, and can be compromised overnight with the public password hash, found locally or over the net by watching domain authentication. Supposedly it's possible to turn on better encryption. (I don't know how, or how much better.) The decryption routine will accept arbitrary length keys, although I haven't determined whether the stored tags have any length limits.

Physical and logical security are still your best friends. All this does is slow a user down. Within a month or so, we'll have a patch to let the linux ntfs driver access all encrypted files if you have the administrator password, or a priveledged user's password or hash.

It ain't that great from what I've heard.

[pi_rules]

You might want to check out bugtraq archives or securityfocus.com for vulerabilities in the EFS system. I've seen it come up a few times in the past though because I don't use it I paid little attention to what they had to say about it. It -does- act weird, and I'm pretty sure it's a rather weak when it comes to actually protecting any data.

Justin Buist

Well..

[NevarMore]

Microsoft.com has no information that I saw on EFS that lists what level of encryption is used. It has continual references stating that it uses public key encryption. The entire thing is user based rather than key based. I wouldn't trust it, even the most dim users would be less likely to give out that key to the super-secret accounting document than 'just' thier login password.

Google wasn't much more help. Admittedly I
didn't look too hard, but there were a few hits on googlge from a newsgroup discussion of "pgpdisk vs. win2k efs" might want to find those and keep an eye on 'em.

artstechnica EFS information

[atomice]

This like on arstechnica has some information on Windows 2000 EFS:
http://www.arstechnica.com/paedia/n/ntfs/ntfs5-3 .h tml
To quote from the above article:
"EFS uses a public key crypto scheme, which uses a public and private key. Encrypting a file will cause EFS to assign that file a randomly generated FEK (file encryption key). The user that encrypts this file does so with their public key, but to decrypt that file requires the usage of their private key to authenticate past the file's randomly generated FEK. DDFs (Data Decryption Fields) and DRFs (Data Recovery Fields) exist as NTFS attributes, storing a list of FEKs. Public and private keys are stored separately from the FEKs. "
but also note this warning on www.sysinternals.com:
"Even when you encrypt files with Win2K's Encrypting File System (EFS), a file's original unencrypted file data is left on the disk after a new encrypted version of the file is created."

Re:artstechnica EFS information

[coyote-san]

This raises some rather obvious questions.

• What's the modulus size used for the key pair? 1024 bits? 512? 256?!
• What's the algorithm used? RSA? DSA? something else?
• What's the key length of the symmetrical cipher used to actually encrypt the data? 128 bits? 64? 56? 40? (Remember that a *lot* of Windows software defaulted to 40 bit encryption due to ITAR restrictions.)
• What's the algorithm used to actually generate these "random" symmetrical keys? Can it be easily predicted?
• What's the symmetrical cipher used? What mode does it use? (Specifically, is it "Electronic Code Book (ECB)" or "Cipher Block Chaining (CBC)"? The former is *much* easier to crack than the latter. Does it use a constant IV, or block-based IVs? Again, the former is *much* easier to crack than the latter.

The Microsoft web page offers one answer. Triple DES is supported, if you are running Windows XP Professional, but all earlier platforms and even WXP by default use "DESX, a variation of the DES standard." In other words, absolute crap - the *only* way to know that a cipher is solid is to expose it to prolonged cryptanalysis by knowledgable people. DES is considered weak now (due to brute force attacks), 3DES is usually considered acceptable but I wouldn't use "DESX" to encrypt my grocery list since it's a total unknown. The mere fact that they choose this oddball variant, instead of any of the newer, IP-free ciphers, screams WARNING - there are unacknowledged motivations here!.

I didn't see any mention of ECB vs. CBC, changing IV vectors, etc., all basic information that you would expect to see for the buzzword factor alone. Since they never wipe the plaintext files, it sounds like someone got a copy of Krypto4Kiddies and never got past the first few chapters.

Re:artstechnica EFS information

[matman]

Key strength doesn't matter really. Why? Because there's way less entropy in the user's password (likely) than there is in the encryption key, and having the user's password will get you the FEK.

Re:artstechnica EFS information

[karlm]

DESX was proposed by RSA Data Security Incorporated as standard to strengthen DES as a stop gap until AES was selected. It uses a 120 bit key. 56 of the bits are used as a des key and the other 64 bits are expanded into two 64-bit pads. The pads are used fro pre- and post- whitening of the DES block. I would assume that they use DESX in ECB or counter mode in oreder to allow random access.

I think they use RSA. Any of the discrete log schemes (such as EL Gamal) would use up twice as much space as RSA for the same modulus size. Shame on anyone who uses public key moduli smaller than 768 bits. Actually, I wouldn't be surprised if they used an eliptic curve system. Personally, I don't like eliptic curve systems. They are based on getting away with smaller RSA keys because the best known attacks on RSA need a notion of smothe that nobody has been able to define on eliptic curves. It seems to me kind of like using 64-bit-key-reduced-round-AES for efficiency and space reasons.

Microsoft claims that DESX is 128 bit encryption, but they forget (more likely chose to neglect) that 8 byte DES keys ignore 1 bit per byte.

In any case, trusting M$FT for you security is like trusting you 3 year old to wash your fine china.

Personally, nowadays I would be skeptical of anything that didn't use an AES finalist (or possibly 3DES or Blowfish) in CBC, CFB, counter, or OCB mode. There really aren't any excuses for using anything else. Even the die-hard "3DES has not been broken in X-years. 3DES is the only thing I trust" people should feel safe using Serpent. The Seprent people chose security over efficiency every step of the way. Sure speed played a big part in chosing Rijndael, but the NIST did a good job of picking the best of each of several design strategies as AES finalists. There should be an AES finalist for everyone.

My understanding is this:

[maunleon]

1. It is a public key encryption method.

2. It is linked to your SID. Therefore no other user can read your files unless they have access to your account.

3. When you encrypt a file, the file is saved in plain text, then encrypted. Therefore, there is a chance that the data is unencrypted on disk somewhere.

I've noticed strange behaviour with this file system so I don't use it often. Most of the behaviour had to do with copying files to and from an encrypted directory. I would get frequent failures (such as "file is in use"). Also, since for some reason my temp directory ended up encrypted, some installshield based programs failed to install.

I am specifically talking about Win 2000 here. I have not yet used it on XP.

The Social Issues

[fm6]

As usual, this discussion of data security pays too much attention to mathematical cryptography to the exclusion of the social side.

Whatever the theoretical strengths and weaknesses of NT's encryption software, what really matters is how the software works in the real world. Are there bugs? Back doors? How hard is it for an unauthorized person to infiltrate back door code? Etc.

And of course we can't answer these questions, because we can't look at the source code. Someone in Redmond has presumably done that. I don't cop the usual cynical attitude towards MS, but I'm still sceptical of any system verified only by people with a vested interest in it.

Which isn't to say that OSS cryptography is necessarily any better. In theory, everybody who uses PGP encryption can either verify the source code or get fingerprinted executables from somebody who has. But how many people actually do that? Or make sure that the software isn't patched after it's installed?

In the end, the question "How strong is this encryption" is less important than "How much security do you need, and how much trouble are you willing to go to to get it?" I've seen banking web sites where they insist that the customers use browsers with 128-bit encryption -- and then use 4-digit PINs as the sole means of user verification! That's silly.

Here's a more relevent example. I have some files on my laptop I would not care for any random stranger to see. But they're not sensitive enough to require really extreme measures. They're just rather personal. If I were running NT on the laptop (I used to, but the system isn't really powerful enough), I'd have no qualms about uses NT encryption. So instead I use PGPdisk. Which is theoretically more secure than NT, but the way I use it (fairly weak passphrases, unverified software) it's not really any more secure than it would be under NT. But that's fine. If I ever become a CIA operative, I will certainly take stronger measures.

My experiences with the encryption

[Shook]

The big thing that I didn't like about the encryption (implementation-wise) is that it didn't obscure the file names. I would have preferred that each user directory would be a total black box to all other users.

I didn't know that much about the algorithm (and know very little about encryption anyway_, but figured it would be better than nothing. Still, I would prefer something that works well better than something that works poorly or not at all.

Can't even make it work

[man_ls]

I've had even less luck with Windows 2000 NTFS file system encryption. Every file I "encrypt" with my account (it has administrator privlidges) is viewable by every other user of my computer no trouble at all. Open it up, copy elsewhere, delete, modify, whatever, done with 128-bit encryption over it. Aside from the fact that those users *shouldn't have access* to the files (I used NTFS resource-level permissions to deny all except myself for this resource) it "works" in that it doesn't kill things...*frustrated rant off*

Errr...

[Xenex]

ROT13 [everything2.com] of course!

I mean, Microsoft have used 'encryption' of that quality in the past [cegadgets.com], why improve now?

There are Good resources for EFS at SANS

[Jeremiah Cornelius]

WARNING: KARMA WHORE ALERT!

Try looking in the "Windows" section of the Reading Room [sans.org] from SANS website.

Specific articles of interest are:

Encrypting File System Primer [sans.org], from July 6, 2001

and

Windows 2000 Encrypting File System [sans.org], from July 27, 2000.

Both of these articles are heavily referenced with links to other techincal source material about Windows EFS. Most notably:

Mark Russinovich, "Inside Encrypting File System, Part 1" [win2000mag.com], June 1999, Windows 2000 Magazine

Mark Russinovich, "Inside Encrypting File System, Part 2" [win2000mag.com], July 1999, Windows 2000 Magazine.

This auto satisfy any questions about the limited protection offered by EFS in stand-alone and default modes, as well as provide direction for configuring EFS to operate with a very decent level of confidentiality and availability.

What I really want to know

[Cryogenes]

Is there some way to protect my Win2000 installation in such a way that someone who steals (ok, confiscates) my computer will not be able to read the registry?

Re:What I really want to know

[atomice]

Yes - use VMware or similar with a virtual disk which is stored on a an encrypted file system under Linux or Windows 2000/XP. Make sure the key for the encypted FS is on a floppy disk, CD-ROM or similar and hide it very well (preferably not on your premises if you don't mind the inconvenience). Then install Windows 2000 on that virtual disk.