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."

Comments

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.

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.

Errr...

[Xenex]

ROT13 of course!

I mean, Microsoft have used 'encryption' of that quality in the past, why improve now?