Wow – personally, I think someone in marketing at Microsoft has miscalculated on this one. Don’t get me wrong, I can understand the rationale – “Well, most of the customers that have asked us for this feature are already on Software Assurance or wouldn’t have to spend much additional $$$ to get it. The smaller orgs still have EFS to be able to protect their data, and since they haven’t asked for anything else, they must be satisfied with EFS right?”
I don’t buy it – here’s my thinking:
- Just because those few organizations who’ve actually taken the time to articulate their needs happen to have the SA arrangements already made (or have the EA leverage to negotiate cheap SA rates), doesn’t mean they’re the only ones who would (or could) use this feature;
- Just because SA has been considered by many Microsoft customers to be a rip-off, and not worth buying again, shouldn’t lead to the effect (intentional or not) of holding some of the most critical features of Vista hostage from the rest of the Microsoft customer base (especially those who wish to purchase one of the premium Vista SKUs such as the rumoured Professional or Full Media editions);
- Many of the organizations who haven’t explicitly articulated a need to their Microsoft reps for Windows-native full disk encryption [at least based on my experience with them] are either (a) still struggling with their much more limited – and challenging, in most cases – deployments of some form of file encryption on user’s PCs, and are sick of talking about encryption, or (b) have committed to another technology because Microsoft hasn’t yet provided a solution for this critical business need. However counterintuitive it might sound, those organizations who fall under (b) should be given the chance to try Vista’s full-disk encryption without having to commit to SA to do so. Many organizations with whom I’ve worked have told me they’d far rather use a technology that already comes with the products they’re using, than to have to integrate yet another piece of third-party hardware into an already-overly-complex “desktop” deployment – just so long as they believe the built-in technology reasonably achieves their overall goals. Nothing like hands-on testing (and widespread talk from others also testing) to help convince them – but it’s very difficult to get that groundswell of opinion when so few organizations even qualify to be able to use a technology like Secure Startup.
It’s not like the need isn’t critical in every organization – just the opposite in fact, based on my experience with customers over the years. I wonder if it just happens that there hasn’t been enough formal market research at Microsoft to show how widespread the need really is.
Makes me wonder what ELSE is being locked up in the SA-only Vista Enterprise SKU. I’d love to hear a response to this from those at Microsoft who’ll have to defend this to the legions of Microsoft customers for whom Secure Startup won’t be available…
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).
I don’t generally recommend SYSKEY in a domain environment; instead I recommend domain accounts and strong passwords or passphrases for reasonable security against brute force attacks.
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:
- 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.