A colleague recently asked me about a previous post of mine:
“Mike, in your blog you mentioned you must use Syskey for real protection of EFS protected data. You said if you didn’t use Syskey, it was relatively easy to get to EFS files. So 3 questions that I haven’t been able to find an answer:
- Are there any public attacks documented or tools to get to EFS protected data, other than cracking the user desktop login password? If yes, please link. I guess this would be cracking the DPAPI secure store.
- What NTBackup options are required to keep the data encrypted in the .bkf file? If there isn’t a way, how can data files in incremental backups be safely encrypted?
- Dell is now shipping TPMv1.1 chips in their Inspiron & Latitude laptops. Can EFS private keys be stored there? How can you know that the private key is actually stored in the TPM chip?”
First I should clear up the misunderstanding I may have created regarding SYSKEY and EFS. What I meant to assert is that EFS files are relatively easy to get at (for educated attackers) unless you use either:
(a) SYSKEY boot floppy or SYSKEY boot password, or
(b) domain logon accounts (and a relatively decent password/passphrase).
As for the direct questions I *was* asked:
- There are no cryptographic “backdoors” to attack EFS data – the cryptography behind EFS, combined with the reliance on multiple layers of protection of the encryption keys, follows the usual best practices for software-based data encryption. I have faith in DPAPI to do what it sets out to do, and to be as secure as any software-based encryption implementation can be. However, there are a number of potential attacks on EFS’d data – none of them “magic”, but really just predictable consequences of both (a) the ways that keys must be stored on disk and (b) the integration of EFS with the Windows logon infrastructure.
- No parameters or configuration are necessary for NTBackup to be able to backup encrypted files – its default behaviour can natively backup EFS encrypted files. NTBackup is one of a class of applications that use the RAW APIs. Applications that call these APIs are requesting that NTFS give them the “raw” file along with the EFS alternate data streams, all in a single binary stream. This means that NTBackup gets a copy of the encrypted file and its keys, so that the backup files contain everything that’s needed to decrypt the files later. When NTBackup restores such files to an NTFS filesystem, you get back the encrypted file intact with its encryption keys. So you can backup any files you like with NTBackup – full, incremental, whatever – and rest assured that the backups are no more vulnerable than the original files. While some backup solutions end up with plaintext copies of the files, those backup apps that use the RAW APIs never expose the unencrypted file contents to later attack.
- All currently released versions of Windows are hard coded to ONLY use the native software CSPs for EFS (specifically, the Base or Enhanced CSPs) – they can’t use any other CSPs for EFS, even the oft-requested smart cards (nor the TPM-enabled CSPs). I have no idea whether there will be support for TPM storage of EFS private keys in Windows Vista, though they have announced plans to include EFS-private-key-on-smartcard support. They also mention support for a “full volume encryption” feature (AFAIK, unrelated to EFS) that would work on systems with TPM v1.2 chips. I assume the TPM software dictates how keys are managed, but until there’s any information on whether non-smartcard CSPs are supported, I can only speculate how “enforcing” TPM storage could possibly work. At this point, I believe the “enforce smartcard” option in Windows Vista EFS is a simple checkbox, so it’s probably hard-coded to look for smartcard CSPs only.
I had a quick look around the Internet for current details on leveraging a TPM (Trusted Platform Module) chip for encrypting files on disk – here’s what I learned on my first pass:
- There’s very little mention of which version of the TPM spec is supported on most PCs in the market today – or at least, that information is not easy to uncover. So far the only mention I’ve found on Dell & Toshiba’s sites is “v1.2” for certain Optiplex models, and v1.1 Infineon chips in the Toshiba Tecra M4 & Latitude systems you mentioned.
- So far I don’t know if there are any significant differences between v1.1 & v1.2 TPM chips in terms of support from the CSPs, and what application scenarios are/are not supported by each version. Maybe the differences are negligible, maybe there’s an order of magnitude more possibilities once you have v1.2. [Or maybe that just happens to be what the “full volume encryption” team was willing to test, even if v1.1 would have been just as good for this scenario.]
- Seems like every PC vendor has some models shipping with TPM chips – IBM/Lenovo (Atmel), Toshiba (Infineon), HP, Dell. Good news for us.
- Seems like there’s only a small number of application + CSP suites out there so far that enable TPM in XP:
- Dell ships one from Wave
- Lenovo systems use IBM’s “Client Security Solution“
- Toshiba ships a suite that looks like it is developed by Infineon
- Some suites leverage particular application APIs that require third party plug-ins (e.g. Dell/Wave)
- Others (e.g. Toshiba’s suite) “support” EFS features – I don’t know what this means, as the documentation I’ve seen is too vague to be sure:
- Does it merely leverage the DRA public key to provide a recovery path for the Personal Secure Drive (encrypted virtual drive)?
- Does it encrypt the contents of the user’s profile with keys protected by the TPM?
- Does it somehow provide a redirection layer so that the RSA files in the user’s profile are actually encrypted by TPM-protected keys before the Windows CSPs drop the files on disk?
This is fascinating, and a lot more than I expected to turn up. It seems that TPM has finally started to catch on with the PC vendors – I was shocked to see that pretty much all the major PC vendors had TPM-enabled PCs. It’s not that I didn’t expect this to happen, but that since I hadn’t heard any of my customers asking me about this so far, I assumed it was still “on the horizon” (like “the year of the PKI” is still just a year or two away, for the tenth year in a row).
I’m going to devote some serious research into the state of TPM-enabled data encryption, and over the next few posts I’ll be putting up my findings and opinions on where I think TPM-enabled encryption fits into the kinds of solutions I normally recommend.
Watch for it.