Schneier on Security

Sounds good. Everybody's got a USB key nowdays. Boot level protection with abundant tech support if you screw something up.

Looks nice.

Another option for drive encryption, at least of user profiles, is Truecrypt with the TCgina.dll extension. This works at least on Windows XP, and possibly other, older Windows versions, too.

Here's a potential concern, though: Truecrypt recently fixed a problem with the way it did on-the-fly encryption. It had been using CBC mode, and there was a problem with leakage of plaintext. I don't recall exactly, but key recovery might have been one of the possible outcomes.

They've since gone to using LRW mode. Would Vista's use of CBC mode result in the same weakness?

The TPM contains a secret key. The recovery password is a function of that key and is sufficient to decrypt the disk. Do we know that one cannot reconstruct the TPM secret key from the recovery password?

If reconstruction is possible, then attacking the administrator of a system of computers to get recovery passwords would yield TPM secret keys for the machines.

Sounds good to me (and I want to dual boot and use Linux, OS X not windows mainly).

Hoewever, 3 questions:

Is the encryption at the level of the physical disk or the partition? i.e. Will you need 2 hard disks in your machine in order to have partitions for Linux and shared data?

I presume that this could be made to work for any OS (i.e. Open Source) apart from the necessity of licensing patents?

Or, is this all implemented below XP in hardware/bios so that once you have a BitLocker machine you have obtained all necessary rights? One expects not :-(

A useful feature derived from Treacherous Computing ... sounds like a good PR move to me.

What does the TPM improve here ?
It only bundles the drive to your hardware, making it impossible to replace a broken mainboard.
There's enough other tools out there that use software-only encryption. Some drives even contain internal encryption that is controlled by a password settable in the bios.

I think that hardware-bundling thing is just to push TMP into the market, to afterwards use it as a customer restriction management solution.

"The problem is that it's impossible to distinguish between a legitimate dual boot system and an attacker trying to use another OS -- whether Linux or another instance of Vista -- to get at the volume."

Why would they care if the system started to be dual boot or not, if the Vista system files are encrypted, and the TPM can even verify the code of Vista? It is still strange that BitLocker doesn't run because of dual boot, if the partitioning for dual boot was done from Vista (or the partition was free).

> It allows people to stop worrying about their drives getting lost or stolen.

Ah, careful, Bruce! If someone loses the USB key the same time they lose the laptop (or worse, they tape their password to the bottom of the laptop case because they can't remember it), the encryption doesn't help much :)

My only worry about this sort of thing is that corporation X will issue the new machines to the executives, write a policy that forbids them to write down their password or carry their USB key in the same bag as their laptop, but not enforce anything. Then executive Joe loses his laptop with 100,000 social security numbers on it on the subway, and the company doesn't disclose the loss, "because the data was all encrypted". So much for California's data privacy protection law.

I think this is well done, though. This sort of encryption is necessary (although I don't know I'd want to use it in production until bugs are worked out.)

As a tanget -> IMO, dual boot systems are a bad idea (although they're not as bad as they used to be.) It's hard enough to keep Windows patched and safe to use when you use it regularly. If you have a dual boot machine and you use the Windows OS every year or so, you're asking to get nailed when you boot the machine.

If you want to run Windows and hate WINE, use VMWare. At least then when you boot the Windows OS you have the Linux host as a built-in firewall.

Does this mean the end of mounting an NTFS partition from a non Microsoft Approved OS? (OS X, Linux)

Why is the TPM hardware module required?

What does it matter if the initial OS boot code (to load key from USB and decrypt the remainder of volume) is not encrypted?

Seems like a nice excuse to DRM enable mass market computers plus reduce the allure of trying Knoppix, Ubuntu or other Live CD operating systems.

In the basic mode, if someone steals your laptop, they still have full access to the drive's data. It's only when the drive is separated from the motherboard that it offers any protection.

Perhaps that would be helpful with desktop computers where a hard drive could be easily snuck out of a building but the whole computer could not.

But since so many of the recent, notorious data losses have involved losing the entire laptop, the basic mode would offer no real protection.

It is possible to move the keys from a TPM to another using products like http://www.wavesys.com/products/ktm.html . However I would prefer the TPM to be part of the HDD, rather then the HDD using the TPM on the motherboard.

TPM built into HDD makes the HDD portable, and provides the same level of security. Seagate FDE drives aims to provide this. See http://www.xml-dev.com/lurker/list/fde.en.html for more info.

People who had concerns about the passwords being revealed, should look at www.secude.com which provides biometric + multi-factor authentication for TPMs.

@ Anonymous

> this mean the end of mounting an NTFS partition

I'd imagine so, since your non-Windows OS probably won't talk to the TPM. Maybe you could deploy the "no-TPM" version Bruce mentions and still get at your NTFS partition using the USB key.

> reduce the allure of trying Knoppix or other Live CD operating systems.

You can still boot off of CD. You could still have a non-"BitLocked" partition on your hard drive to share data between OSes (remember the BitLock only works on the system root partition, ie, the "c" drive).

@ Bob

> In the basic mode, if someone steals your laptop they still have full access
> to the drive's data

Not if they don't know your password. If they can't log in, they can't access the hard drive data. If they boot to (for example, a Knoppix CD), they won't be able to read the c partition, even with an NTFS driver, because it is encrypted. And if they yank the drive, they can't read it at all.

I don't buy it.

There would be NO way to optimize a truly encrypted harddrive.

My bet is the structure of the date is encrypted, but the files themselves are not.
Imagine an audio, video, or database file. Truly encrypting the drive would require fragmenting the file and spreading it around the disk in a way that you could only realistically recall the file if you could decrypt it.
Fragmenting would be the only way you could keep a foreign OS from reading the drive and mapping the common known files. But, by fragmenting the drive you would kill performance.

I don’t buy it.

@ Rich
> The TPM contains a secret key. The recovery password is a function of that key and is sufficient to decrypt the > disk. Do we know that one cannot reconstruct the TPM secret key from the recovery password?
> If reconstruction is possible, then attacking the administrator of a system of computers to get recovery >passwords would yield TPM secret keys for the machines.

Depends on the key you are talking about. A TPM has many different kind of keys. e.g. SRK, binding key, storage key, signing key etc. The SRK is stored in the TPM, and used for wrapping other cryptographic keys, and is non-migratable. Getting hold of the password or the recovery password will now allow you get access to the SRK.

A nice idea, indeed. But, as with most of Microsofts good ideas, the implementation is far from perfect.

So, the TPM-hardware shall store the key within the same hardware as the encrypted data? The security of the TPM is then bound to the security of the whole system. Where can I download the design description and the circuit code of the TPM in use? How do I know for sure, that the design description and the circuit code belongs to the TPM in use?

The de/encryption will be done with software? Where can I download the (formaly) documented and easily readable sourcecode of the _complete_ implementation?

What happens if the used algorithm had been cracked or significantly weakened? Can I exchange the algorithm easily? (should be able to do with three lines of perl or alike, but Microsoft is known for messing up even much simpler things ;-)

> There aren't any back doors for the police, though.

I don't know if I can believe the information behind _that_ link ;-)
But a hidden backdoor ist not even necessary because there's already a public one called "recovery key" and there is a not very low probability of a backdoor in the TPM.

There seems to exist an FPGA(? why do I always forget to bookmark the most interresting links? ;-) coprocessor for the Opteron socket. That would be much more interessting for fast hardware encryption.

CZ

> Getting hold of the password or the recovery password will now allow you get access to the SRK.

I meant:
Getting hold of the password or the recovery password will NOT allow you get access to the SRK.

@ CZ

Well, I doubt that the Air Force communication guys are going to rely on BitLocker and Windows to provide secure devices for configuring RF snooping antenna arrays. But they don't use normal computers for that sort of thing anyway :)

Hacking a TPM isn't exactly a low-skill task. Sure, you *are* agreeing to trust that they're implementing AES-CBC correctly, but you're trusting most of your software (even the open source stuff) to do this correctly in most cases.

I would imagine if someone publishes a useful break of AES you (the user) couldn't easily change the algorithm. However, a useful break against AES would probably produce enough market pressure to push Microsoft to do it relatively quickly.

@Pat Cahalan
The Internet has made many High-Skill task very Low-Skill.

@Jim Dermitt
Update your drivers for your DVD/Cd-Rom or goto Megagames.com and find a NoCd game fix
AND Try and stay on topic next time

@ AG

> The Internet has made many High-Skill tasks very Low-Skill

Point taken.

@Jim Dermitt
The community is asking for a layed security approach and Microsoft is giving that...software, hardware, and design. Of course it will not be unbreakable, but it will be a hurdle to breaking a system.
On Trout Fishing; http://stores.ebay.com/JUDSONS-CUSTOM-FLYFISHING-FLIES
And AGAIN try and stay on the topic of security

"But it does mitigate a specific but significant risk: the risk of attackers getting at data on drives directly. It allows people to throw away or sell old drives without worry. It allows people to stop worrying about their drives getting lost or stolen. It stops a particular attack against data."

This is relying on the fact that AES-128 is not going to be broken (or feasibly broken) in the future. Of course this is a concern in other areas of security/cryptography, but with the case of a HDD that has been sold, one does not have the opportunity to go back and implement another level of encryption.

@rob bainbridge
I agree on the point that the encryption will only be good as long as it is not exploited.
I disagree on the implementing another different level of encryption. I see no reason the BitLocker could not be upgraded in the future.

@Jim Dermitt
Am I missing some movie or book reference? Or are you stark raving mad?
:-P

So many questions and inaccuracies, it's like everyone commented without reading the article!

Here we go...

Felix_The_Mac: Encryption is at the partition level.

Anonymous: "It only bundles the drive to your hardware, making it impossible to replace a broken mainboard." - this is what the recovery key is for, and why you don't want to disable its creation! When you replace the broken mainboard, BitLocker detects this as an attack, and requires the recovery key before it will boot.

AC: The reason dual boot creation is seen as an attack is that BitLocker also encrypts the boot manager. Dual-boot creation requires changing the boot manager.

Anonymous: "Does this mean the end of mounting an NTFS partition from a non Microsoft Approved OS? (OS X, Linux)" No, only if you've enabled BitLocker.
"Why is the TPM hardware module required?" To create the starting point of a chain of trust. The TPM is there and its key verifies / decrypts the bootmanager, so the bootmanager is trusted, etc. Without the TPM, there's no starting point, so the chain of trust is much weaker.
"What does it matter if the initial OS boot code (to load key from USB and decrypt the remainder of volume) is not encrypted?" If you can read and alter the initial OS boot code, you have subverted the chain of trust. You now can do anything up to, and including, virtualising the decryption process. The machine is yours.
"Seems like a nice excuse to DRM enable mass market computers plus reduce the allure of trying Knoppix, Ubuntu or other Live CD operating systems." From my perspective, as an Information Security Engineer at a health-insurance company, I see it (and other drive encryption products) as a means of keeping my company's name out of the six-o'clock news, and of keeping your proctology results private. This doesn't have anything to do with DRM.

Jim Dermitt: "Proprietary encryption is a joke." As noted, it uses AES encryption, so that's not proprietary encryption. Read the technical paper - exactly what part do you feel is inappropriately proprietary?

Bob: "In the basic mode, if someone steals your laptop, they still have full access to the drive's data. It's only when the drive is separated from the motherboard that it offers any protection." No, in the basic mode, if someone steals your laptop, they have full access to the drive's data _if_ they can log on using a cached credential. But they can't boot to a separate operating system to crack the cached credentials, because when they do that, the drive is still encrypted. To decrypt it, they have to run the secured code in the BIOS, which is protected by the TPM, and can only be run when booting the original OS.

AG: "There would be NO way to optimize a truly encrypted harddrive." Sure there is - from inside the operating system once it boots. To the OS, it looks like an ordinary disk partition. From the outside, it's encrypted using a block encryption scheme.
"My bet is the structure of the date is encrypted, but the files themselves are not." Your bet is based on a flawed understanding, and is wrong to boot. The structure of the data is not encrypted, it's still MFT, but the contents of the files - and of the MFT - is encrypted. So, that master block in the MFT is still where it always was, but it's encrypted, so you can't see what other blocks it points to.

Saqib Ali: "Getting hold of the password or the recovery password will now allow you get access to the SRK." No, getting hold of the recovery password allows you to get access to the key that was used to encrypt the drive. This key is encrypted using a key from the TPM. The recovery password gives no access to the TPM key. Glad to see you corrected this later - but I thought I'd cover it here and explain _why_ you don't actually expose the TPM key.

Christoph Zurnieden: "How do I know for sure, that the design description and the circuit code belongs to the TPM in use?" You trust the vendor from whom you bought your hardware to have correctly implemented the TPM spec. The key for the hard drive is decrypted by the TPM - another faked TPM will not be able to decrypt it unless it was faked up with the same key as your original TPM was created with.
"The de/encryption will be done with software? Where can I download the (formaly) documented and easily readable sourcecode of the _complete_ implementation?" It's AES. Go look.
"What happens if the used algorithm had been cracked or significantly weakened?" You decrypt your drive, download the patch, and re-encrypt your drive.
"But a hidden backdoor ist not even necessary because there's already a public one called "recovery key" and there is a not very low probability of a backdoor in the TPM." Yes - in the event of a police investigation, you will likely be asked by the police to provide your recovery key. If this concerns you, you will of course have created your drive encrypted without a recovery key. But then you run the risk of losing your data completely if your motherboard blows out. Your choice.

Rob Bainbridge: "This is relying on the fact that AES-128 is not going to be broken (or feasibly broken) in the future." Yes, but it's better than not doing anything. There are always risks, and your job as a security guy is to assess risks, not to claim that you've prevented them all.

@everyone:

Please Do Not
Feed The
Trolls

@Pat Cahalan:

It isn't just California. When I looked at the "encrypt the data and lose it and the key" loophole in state notifications (like Cali's SB1386), only 2 or 3 state laws handled this properly. A state by state summary with links to each law is available at
http://www.cwalsh.org/cgi-bin/blosxom.cgi/2006/04/20#breachlaws
for those who are interested.

This is much more reasonable than the Reg quote....

Sounds like a boot sector virus becomes the ultimate nightmare.

Since you can't boot a known good alternate OS to do an anti-malware sweep or hardware diagnostics, you're rather screwed if you get a nasty virus, spyware, other malware, or a hardware failure on the drive.

I'm also wondering how a forensic copy of the drive could be done. I'm guessing special tools will need to be created to deal with the information recovery issues.

@derf: Yeah, that's what the recovery key is for. You can fully decrypt the drive offline if you have the recovery key. This solves all your suggested problems. Sure, it's slightly less easy than the unencrypted drive, but if your big risk is theft of the machine / drive, that's a pain you'll just have to bear.

"Or are you stark raving mad?"

I think he is.

And for one, I do not expect serious objectors in this respect - I think that is one opinion all the people who read this blog can agree with.

Entire disk encrypted, all the time. Yeah, way to burn more CPU cycles to help Intel sell more and faster processors....

Unixronin: Why, are you being forced to encrypt your drive against your will?

So what it comes down to is, how secure is the TPM module against attacks by someone with physical possession of the host machine?

There are celebrated examples of specialized security hardware yielding to specialized laboratory attacks (Paul Kocher's 1998 feat of inferring secret keys on smart card security chips by analyzing their power consumption comes to mind).

If TPM is potentially vulnerable to this sort of thing, then in effect a back door *does* exist --- an organization with the resources and knowledge required to mount such an attack can read Vista encrypted partitions (all resemblance between such an organization and the FBI or the Mafia is purely coincidental).

Can anyone with actual knowledge of TPM describe how hardened these modules are against this kind of non-software attack?

Are we supposed to trust a black box?

If I have in my possession the recovery key and the hard disk, I should be able to decrypt the drive using open source software (or in theory, software I write myself).

If I have in my possession the passphrase and main passphrase-encrypted key, I should be able to do the same thing.

So it should be possible to read and write from this drive from Linux, BSD, etc. If not, why not?

Why not instead use Truecrypt or its equivalent?

One more thing... by Kerckhoffs' law, cryptographic security should not depend on any secrets other than the key itself. So there cannot be any valid security-related reason for closing this software off from Linux and other OS's.

Beware a major security hole.

Consider that if not using a PIN or USB key (i.e. basic mode), even though a thief cannot log in, all the ports are hot and all that's required is to send a net packet containing a buffer overflow exploit and voila, the thief now has their code running in kernel mode in the TCP/IP stack and they own the machine.

For bitlocker to be secure, you MUST use either a PIN or USB key **AND** make sure the computer/laptop is either off or hibernated when not physically secured, StandBy Mode is subject to an exploit atttack.

David

David: BitLocker is one component of a security solution. That there are other attack routes is no surprise, and is no failing of BitLocker's. Note that it also doesn't protect against me forcing you to log on by holding a gun to your head.

All this really does is protect the data from compramise if a drive is stolen or a powered-down system is physically accessed by intruder (assuming the user didnt leave themself logged in or leave the key plugged in or on the desk).

The TPM + 4-digit key idea is similar to the USB + TPM idea. But, the drive must be in the original system and the user must know the PIN key. The only difference is that it authenticates on what the users knows AND what they have. I think this is the best method, although the knowledge requiremens are very weak. Since the user must login anyway, its still really only adding 1 more vector: the user who owns the network account also knows the key for the given physical machine. This seems to fail if a users need to roam from machine to machine.

Regardless, all this is only protecting the data from those with physical access to the hardware. Once the system is running and a user is logged in, all that goes out the Window (excuse the pun). Anyone with logical access to the system via the network needs only attack the software, which already has full access to the data, post-encryption and post-authentication. Doesn't it make more sense to just improve physical security? However, the USB key and PIN method may be usefull for notebooks. But, some vendors already include similar solutions in hardware that will be more compatable for more than one OS platform. I can see the MS motive.

If the goal really is to protect the important data, then I dont see how protecting the physical drive does this in most cases. The same access method unlocks ALL the data, and flaws exist in utilities that have access, post-authentication. The primary problem still exist: remote compramise over the network.

A better solution would be to encrypt each instance of the critical documents (Office documents, in Microsoft's case). An infrastructure would need to be in place to integrate encryption on the shared data store, user permissions to access the file (would decrypt and xfer securely to the user), and user-based encryption under each user's working space (for saved and working instances, on the workstation). Until they can get something like this, we can keep dreaming and debate the less relevant.

I see one problem here - the recovery key is linked to key in TPM, so what if TPM goes bad (or is replaced)? It seems to me from the description, that it would make the data inaccessible.

Another fine reason to avoid TC plague...

I'm not any good with crypto, but does the fact that you have 4+ Gigs of known plaintext reduce the security at all?

The Vista Os has to be at least 4G so you have a lot of known palintext in the form of executables and dlls does that make the security vulnerable? Or does the fact that the disk is fragmented resolve that issue?

@Paranoid
> I see one problem here - the recovery key is linked to key in TPM, so what if TPM goes bad (or is replaced)? It >seems to me from the description, that it would make the data inaccessible.

Key escrow???? Master key??? See
http://www.wavesys.com/products/ktm.html

Hmmmmm...

Make a thumb drive and have the power switch be a USB port that rotates, like the ignition lock on a car, make some "rrrr" noises and then the PC starts up, all using a paradigm that people are used to.

Of course my *real* problem w/ the tech is that it's designed to lock out Linux.

@Carlo Graziani

You asked if the TPM is secure from a physical attack, e.g. grinding off the plastic and analyzing the circuitry. As I understand the specifications it is not designed to be protected from a physical attack.

Paranoid Mike: The recovery key is not tied to the TPM in any way, so that you can recover if the motherboard goes toast. This is what, the third time I've said this here?
Jason Lash: Encryption of data is already there, in EFS. But the EFS keys are stored in the user profile, which is subject to the possibility of cracking the cached credentials if you can get access to the drive. I don't think that EFS is portable to other operating systems, though, so you'd obviously use some other solution for that.

@Alun: But... recovery key is always 128 bits while actual encryption key may be 256. Where do other 128 bits come from when you want to decrypt data during recovery?

The recovery key is used to decrypt the actual encryption key. The encryption key for the disk needs to be bigger than the key that encrypts it, because it's subject to attack based on a large ciphertext. The recovery key can be smaller, because it has a small ciphertext, and is very infrequently (on the order of "once") used.

Encrypting one key with another is a common tactic in cryptography, used in numerous situations. In SSL, for instance, the bulk of your traffic is protected by a shared secret key in symmetric encryption. That secret key is built in an exchange between the two parties that is at least partly encrypted using the server's public key, so that only the two parties know the shared secret.
Similarly, in EFS, any number of people may be given rights to decrypt the file - this happens by encrypting the file with an initial key, and using each user's own key to encrypt that initial key.

Thanks Bruce!
May I ask where you got the encryption particulars from? I can see on the Vista beta 5308 I'm running the group policy settings for AES 128, 256, etc, but where did you learn about the 48 char recovery key being an AES-128 bit key?

Also, what exactly is stored in the TPM, or USB startup key, or recovery key? Are these different keys used to encrypt the actual drive encryption key? If so, where is the encrypted blob stored - somewhere on the harddrive?

Ah - looks like Alun has answered some of my questions already - so its a key to encrypt *the* key... but where's the blob stored...

Unless Microsoft publishes the source code, I wouldn't trust it. Use PGP Disk encryption instead. Long history, proven technology, and full public disclosure of the source code.

This reminds me of the websites where you have to enter a password at least 12 characters long, with numbers digits and punctuation, but not any of your past 10 passwords, and you get to chose 'What's my dog's name?' as a password recovery option.

This looks like it could be useful in the most secure mode, but most circumstances will forbid it (anywhere where the system isn't well managed, say, home users, most small businesses) because the system can either never be recovered or the security of the system is reduced to the posession of the recovery key. If you have a recovery key, you might as well just use software encryption since the TPM module isn't helping with security other than improving convenience.

@Alun

How does this keep your users' data safe from a laptop thief any better than a software + USB solution with the bootloader in the clear?

The user (and OS) being able to trust his own laptop is not relevant.

That is why this is mostly about DRM and very little about keeping corporate data safe.

In fact, software + USB is the better choice for corporate data since the use of a potentially dangerous "recovery / one-to-rule-them-all" key is not required to recoup from a failed motherboard.

Stupid question: how on earth do you use CBC - Cipher Block Chaining - on a hard disk, which is innately going to be randomly accessed? You'd have to reencrypt the entire drive after writing to the first sector!

It's far more likely they'd use ECB, or bastardize CBC so it re-initializes every 16kb or so. (Perhaps with an address-dependent IV - like Linux, IIRC).

Does it really only encrypt the C drive? This seems a poor choice. Wouldn't a sensible setup be to have only OS and software packages on C:, and all data elsewhere? Then the sysadmin can safely restore C: from image to recover from malware, and it is simpler to backup data without needlessly backing up OS & software packages. But under this scheme, if only C: is encrypted, the encryption is pointless.*

(I'm not a Windows Sysadmin, so likely there are relevant complications I'm unaware of.)

Also, after skimming one of the links, you need two partitions: "The first partition, called the system volume, contains the boot information in an unencrypted space. The second partition, called the operating system volume, is encrypted and contains the operating system and user data." The first partition is at least 450Mb!!! OK, so disks are big these days, but why do they need 450Mb for a glorified boot loader?

* OK, almost pointless: it prevents an attack where the HD is removed and put in another machine to write a compromised version of the OS onto it, then returned.

Alun's done a great job of explaining things here, but people seem to keep missing things.

To summarise (again): This protects against a specific but significant threat.

If your machine is logged in with the partition encryption keys in memory, you're screwed. This system is much like the original EFS, but with a hardware side to it, and one or two other things.

The general idea is this:
To get at the data with the HDD in the machine, as usual, you need to log in. Logging in will give you the normal access to files that you want. If an attacker can steal your laptop and log in, you're screwed. Bitlocker is not made to protect against this.

Bitlocker is for protecting against a sort of "offline attack". Windows login protects your data when the machine is booted up normally. The files aren't encrypted, but ACLs and whatnot protect your files when the OS is "up" and running. Bitlocker is to stop access to the files when the OS *isn't* running, such as removing the HDD to another machine.

It's simple, and it's specific. Two cases. Windows is running? OS-level protection. Window's isn't running? Encryption protection, backed by TPM. This is *not* DRM. Get it right.

"Stupid question: how on earth do you use CBC - Cipher Block Chaining - on a hard disk, which is innately going to be randomly accessed? You'd have to reencrypt the entire drive after writing to the first sector!"

My guess: each sector is encrypted independently, and the IV is calculated by some hardware address on the disk.

@Pat Cahalan
> Well, I doubt that the Air Force communication guys are going to rely on BitLocker and Windows to provide secure devices for configuring RF snooping antenna arrays.

Wasn't there once a NAVY-vessel, that came to the ship-equivalent of a screeching halt because of some, ahem, software glitches? ;-)

> Hacking a TPM isn't exactly a low-skill task.

Testing it isn't quite simple too and that's the problem I see with all kinds of hardwired algorithms including TPM: it's very difficult and expensive to check the actual implementation against the Verilog-listings, more so if you don't have any sources, but it's quite easy and cheap to check software which runs on general purpose hardware, more so if you have all listings.
I really don't care about a chip in a plane, a lot of people check these silicone and a lot of money and votes are at risk if something goes, well, down too fast. I trust these implementations. But the stock price of Microsoft (and a lot of others, it's just the biggest company) shows that actually nobody cares if the PC doesn't work as described; a patch comes out, will be installed on some or even most of the machines over time and end-of-story.
I don't see any sense in the usage of the TPM here, and it seems as if I'm not alone with that opinion.
Is it just a PR stunt by Microsoft because of the listless of the users to upgrade to Vista, or do I have to look up for cheap tinfoil? As the stockprice of Microsoft went down a bit after the not-so-good quartely report I guess it's more of the former.
But it is a bit suspicious that it only encrypts one partition which is the default partion for Windows, isn't it? ;-)

> but you're trusting most of your software (even the open source stuff) to do this correctly in most cases.

No, I don't, but I must admit of course, that I have the skills to check the implementations myself and I take only software reviewed by a lot of people over a long time in the first place. Yes, that means, that I do not trust anybody including myself ;-)
And it's rarely the algorithm itself that is badly coded, it is the environment, the whole implementation that is very often very buggy and at too many times horribly insecure.

> However, a useful break against AES would probably produce enough market pressure to push Microsoft to do it relatively quickly.

Why do you use the word "relatively" in this context? ;-)

BTW: would "Movable Type 3.2" even stand an AES-break?

@Alun Jones
> You trust the vendor from whom you bought your hardware to have correctly implemented the TPM spec.

I can't test it easily and cheap in contrast to software. It's only a small point, but it nonetheless is one.

> It's AES. Go look.

I didn't underlined "complete" in "_complete_ implementation" without reason. Microsoft probably has C&P the algorithm directly from the textbooks, at least I hope so. It's the rest of the implementation which is unknown and according to Microsoft's history ...
I don't have enough details yet but it seems as if the implementations might have some holes. Let's see when the first buisines versions come out this autumn.

> You decrypt your drive, download the patch, and re-encrypt your drive.

If the average Windwos user has to do it actively it won't be done. Yes, I can see where that leads to; I don't like it and I guess some of the corporate clients won't like it too.

> Yes - in the event of a police investigation, you will likely be asked by the police to provide your recovery key.

If it is used in the simplest way, which seems to be--who's surprised?--the default way, they simply have to boot that machine and use some of the scripts available in the darker corners of the internet.
I guess booting would be sufficient, but who knows the final implementation and Microsoft might surprise us all and do it right the first time?
Hehe, OK, just kidding ;-)

> But then you run the risk of losing your data completely if your motherboard blows out.

That's a problem I won't have with "standard" software FS-encryption.

> Your choice.

So, what do we have here:
A FS-encryption which encrypts one partition of one harddrive. The partition where the OS sits in most of the installation, the data may sit on this or one of many other partitions: the encryption seems to take more of the OS than of the data of the users.
In the simplest and probably default implementation is the password saved in a little piece of difficult and expensive to test hardware on the motherboard of the same machine where the encrypted data sits. You can add another key on an USB-stick, which is of the same kind as the key on the TMP: "something you have". To add a key of the kind of "something you know", you have the single option of a four(!) digit PIN. You have no option for "something you are" here, which is probably one of the better sides of the implementation.
Because of the encryption of the OS-partition you have a lot of known text: an oracle.
You have a short key as a public backdoor. I don't have any details how and how well it is implemented.

The only benefit in using BitLocker in the default installation I see is, that nobody can easily pirate your OS if you throw the harddrive in the bin without destructing it before.

So, my Choice? Wait and see.

CZ

>In its basic mode, an attacker can still
>access the data on the drive by
>guessing the user's password, but
>would not be able to get at the drive
>by booting the disk up using another
>operating system, or removing the
>drive and attaching it to another computer

Perhaps I'm missing something here but why would the attacker bother with another OS or slaveing the drive while he can simply boot from this drive as a legitimate user using the guessed passsword?

@almost everyone:

One of the fundamental mistake that most of the people make is that they assume that a TPM replaces a USB cryptographic key device / token. The is completely NOT true. A TPM only compliments smart card or USB token.

A USB token/smart card authenticates the user whereas a TPM authenticates a machine. Please keep this in mind when posting comments to this topic.

I am a greenhorn, nevertheless I appear to be missing something here. Everyone seems to be thinking in established Microsoft mind sets.

Shouldn't protection of data on all hard drives occur exclusively on board the hardware devices with key management for hardware encryption at bios level using an external token via USB or card reader to unlock the drives, before *any* system (MS, Unix, Linux etc.) boots?

Surely it is not so difficult to come up with some hardware and encryption standards that BIOS and HD manufacturers would not mind adhering to?

No one has mentioned performance issues!

I see that story about the passwords repeated so often (though in the original version they got a *pen*, not a chocolate bar), and nobody seems to see the obvious: most of those users *lied* about their passwords in order to get the pen. And then the journalists wrote an article about how many passwords they got.

@Jim Dermitt
> ChocolateBits Pudding
> 6 ounces semisweet chocolate chips
> 1 cup whole milk
> 1 tablespoon sugar
> 1 teaspoon vanilla extract
> Pinch table salt
> 3 large eggs
> Whipped cream or vanilla ice cream for > garnish
> GOOD EATING.

Yes, and very crispy with the three eggshells!
Please, Jim, if you want to publish cooking recipes it needs some preparation advice too. (Nitpicking: the title is a bit misleading, you can't make a technical correct pudding with the listed ingredients)
But let's see what we can do with all of that stuff.

Freeze the chips in such a way, that you don't have a big blob after the freezing (spread them on a plate or two before freezing). Seperate the yolks from the egg whites (be carefull: put no yolk or other kind of fat in the egg white!). Whip the egg white with a pinch of salt and add some sugar and vanilla halfway of the whipping. (you may add a pinch of potato- or cornstarch, it stabilizes the whipped egg by binding some of the water). Store it at a cold place (don't freeze!).
Boil the milk with the rest of the sugar and vanilla and another pinch of salt up one time and pour it over the yolks while(!) stiring the whole mass. Pour it back into he pot and warm it while(!) stiring until it thickens. It's a risky process, you'll get scrambled eggs if you heat it to much! Pour it back into the bowl and stire from time to time until it's cold enough (below 30 degrees Celsius, but better below 20). You may put the bowl in ice water to speed it up, but the frozen chips will do their part, because it's now time to add them. Add the whipped cream, add the whipped egg white, be carefull while stiring. Cool. Eat.

It's not a very good recipe, mainly because of the relation of the quantities of chocolate and mousse, it's too much chocolate. Feel free to ask me if you want me to try and test a working recipe based on the given list (semi sweet chocolate chips, milk, sugar, vanilla, salt, eggs, cream or vanilla ice cream).
It'll work faster if you have a formal description of taste, temperature and structure of the final product ;-)

CZ

@Christoph Zurnieden: "Wasn't there once a NAVY-vessel, that came to the ship-equivalent of a screeching halt because of some, ahem, software glitches? ;-)" - not quite, it was towed to port as a safety measure after discovering a bug in a control system during a test of that control system.
"Testing it isn't quite simple too" - you either trust your vendor, or you trust your security testers who test the vendor's product.
"I don't see any sense in the usage of the TPM here, and it seems as if I'm not alone with that opinion." Pick a president - any president that you disagree with - and you'll agree that mere popularity does not make your opinion right. Use of the TPM protects against a specific threat, as designed. That you see no sense in it after it's been explained several times simply suggests that I should stop trying to explain it to you.
"But it is a bit suspicious that it only encrypts one partition which is the default partion for Windows, isn't it? ;-)" No - it is designed to protect against a specific threat. Other threats are protected in other means. You want to protect your data? Use EFS or other encryption tools. BitLocker is designed to protect your operating system against being subverted prior to its being started. [BitLocker in Longhorn is planned to extend to apply to data disks]
"If the average Windwos user has to do it actively it won't be done." BitLocker is not for the average Windows user. It's for the Windows user who needs to protect his system against the particular threat that BitLocker is designed to protect against.
"That's a problem I won't have with "standard" software FS-encryption." BitLocker isn't designed to replace standard FS encryption. It's designed to protect the OS against undetected and unapproved outside interference.
"You have no option for "something you are" here, which is probably one of the better sides of the implementation." That's actually what the basic version is designed to verify - it's not verifying you, the user, it's verifying the system - the hardware, the BIOS, and using that to secure the integrity of the OS prior to boot. Your logon to Windows is where you verify who you, the user, are. You're trying to criticise a door-lock by saying that it doesn't protect the chimney - it's because it isn't designed to protect the chimney, and you should be using something else to protect that if it needs protecting.

Thanks for the information and answers, Alun. Sounds like an interesting solution to a particular problem.

It does seem that the OS would have to retain the encryption key in memory while running, and I wonder about the security implications: but I'm no security expert.

BitLocker is not a DRM system. However, it is straightforward to turn it into a DRM system. Simply give programs the ability to require that files be stored only on BitLocker-enabled drives, and then only be transferrable to other BitLocker-enabled drives. How easy this would be to implement, and how hard it would be to subvert, depends on the details of the system.

@Jim Dermitt: So far, the only person I've heard make this claim is you.

@Alun: "BitLocker is designed to protect your operating system against being subverted prior to its being started."

Isn't this a far-fetched threat compared to threats against exposure of your data? The threat protected against requires either someone booting your computer to an alternative OS, or attaching the drive to a different computer, and then, having had access to your hardware, instead of just nicking it, they install a nasty OS hack. (Or, if they're intent on espionage, they could add a keylogger.)

Note that it does nothing to protect the OS once it is running. (The OS tries to protect itself, but history says it is very often unsuccessful.)

Compare this to the "lose your laptop and have your {customer's credit card details | secret business plan | compromising photos of you and your celebrity partner | illegal porn | criminal accounting} exposed" threat, which is far more likely.

Yes, it protects against a threat, but one which would be well down my list of priorities - unless (tinfoil hat time) I had a DRM OS which I wanted to protect against the user. (It doesn't even do this, due to the fact that it is optional.)

I will continue using PGP 8.0 thanks, but for microsoft I will not trust any more , you really think it dont have any class of backdoor please ¡¡¡¡¡¡¡¡¡¡¡¡¡¡

AES is already broken by the NSA for this reason dont need to put one backdoor because for this class of people is easy to crack such disk

AES is recommended by the NSA for encryption of data of top secret classification (search archive of this blog).

I do not believe that an algorithm which they could easily break would pose enough of a security margin for them to recommend it so that other government agencies secure their data agains forein intelligence services with it.

Filias: It may seem like an unlikely scenario to you - but it's the "final mile" in protecting encrypted data on your laptop. Right now, if you steal a laptop, you can mount the drive from another OS (or in another computer), and read from it the cached credentials, which you then use to get at EFS-protected files. With BitLocker, you can't crack the cached credentials without first decrypting the disk. You can only do this with the recovery key, or from within the known-trusted OS once you provide the very credentials that you're hoping to crack.

@Alun Jones

> "Testing it isn't quite simple too"
> you either trust your vendor, or you
> trust your security testers who test
> the vendor's product.

That's the way for software. You test it ones and are easily able to verify that the software you use is the software you tested at any later time. Not so for hardware: there is no easy and cheap way to verify that the design of the chip you use is the design of the chip you tested. You would have to test a black box, because the chip will probably break if you disassemble it and it is not very cost effective too. And testing a black box seems to be not possible at all (I can prove that for some cases with infinite sets but I'm still unsure about finite sets which are obviously more relevant here) but is at least very costly, too much for any practical considerations.
This all means, that you have to trust a black box, produced by a company which is quite probable be forced by it's gouvernment to build a backdoor in, for personal(!) security. I may make sense for you, but it doesn't make sense for me.

>You're trying to criticise a door-lock
>by saying that it doesn't protect the
>chimney

No, I criticise a doorlock that protects the door and nothing else. Nobody is able to steal my door now, but everyone can steal the rest of my house as easily as before. Such a doorlock makes only sense for the insurance company insuring my door.

I'm sorry, but it's all a bit suspicious to say at least.

@the anonymous cooking engineer
I didn't know, that "pudding" is synomymous for a dessert in general in your speech-area. I meant the standard definition of "pudding" and the standard in case of cooking is still a french one (sorry, Signora de Medici, you're forgotten in France ;-): http://fr.wikipedia.org/pudding.

CZ

What impact will this have on Pointsec and other similar encryption products for Windows? Are they destined to go the way of all Microsoft "partners"?

@CZ: I doubt that I'll be able to persuade you of anything on this, but really, this component is designed to protect one point of entry into the system. Other technologies and administrative measures are responsible for protecting others.

@Moz: As usual, other products offer different features that Microsoft hasn't covered. PGP, for instance, encrypts the whole drive, whether it's a single system partition, or multiple partitions. PGP encrypts to be decrypted by a boot-time pass-phrase or a hardware key, but not a regular USB drive. Pointsec likely has its own set of unique features.

Something Alun and others have mentioned, but it appears most people have missed:

*** Windows XP is already capable of encrypting data on an NTFS 3.1 drive by way of the EFS feature in the filesystem. ***

EFS was introduced with NTFS 3.1, which came with Windows XP in 2001. The current shortcoming of EFS is that the key is stored in the user's profile and uses their logon password as its passphrase. This meant that if an attacker can copy the user's key file and obtain the user's login password (most likely by cracking the SAM, which is very do-able), then they have everything required to decrypt those files.

Side note: EFS also has a "recovery agent" feature, which can be set by Group Policy as well as manually. This is required because if a user's password is reset (by an administrator or via chntpw) instead of being changed manually, the passphrase for the EFS key cannot be changed as part of this process.

From the article's information, it appears that BitLocker is designed to protect the operating system partition; this includes the user's profile and thus the file containing the user's EFS key (if EFS is in use.) This adds another layer of security to the EFS protection *already in Windows* and makes it a much more viable solution.

As always, the devil is in the details. Once I read through Alun's excellent explanation, I realised that most people are underestimating Microsoft's intelligence... which I suppose is a common mistake. :P

To Moz's post on May 7,

Wouldn't Pointsec, PGP Whole Disk and other encryption products all be incompatible with Bitlocker since all WDE/FDE products alter the MBR. It could be pretty scary if a user accidently enables Bitlocker on a previously encrypted system.

Alun Jones wrote:
"Right now, if you steal a laptop, you can mount the drive from another OS (or in another computer), and read from it the cached credentials, which you then use to get at EFS-protected files. With BitLocker, you can't crack the cached credentials without first decrypting the disk. You can only do this with the recovery key, or from within the known-trusted OS once you provide the very credentials that you're hoping to crack."

This is an excellent resume.
The hashes of user's local passwords can be found in the SAM file, hashes of network passwords can be found in the file Security. The file SYSTEM contains the obfuscated level 1 SYSKEY. These files can be fetched to several password cracking applications in order to reveal the passwords. Activating SYSKEY 2 or 3 prevents this particular attack (you would need to guess SYSKEY 2 ou 3 key in order to be able to decrypt SAM or Security file)

My question regarding BitLocker, hopping someone knows the answer, how does the OS authenticate itself to the TPM? If you can boot another OS that can provide the needed credentials, the OS will get the disk decryption key.

I'm considering joining a company called Absolute Software. www.absolute.com I'd sure welcome input from the experts here before I make this move. Their argument for why you need this tool above and beyond encryption is that 70% or so data breaches are internal and these rogues may well have access to encryption keys. If the drive could be erased by triggering BIOS code remotely, then the data is gone and compliance is met. Thoughts? Thanks in advance.

So it all boils down to this:

Bitkeeper protects Vista(yes, yes data in fact), not simply data. By protecting Vista it protects data, cause you cant get hashes from Windows sysfiles to crack them and gain access to crypted data. Hack up TPM and get all puzzle pieces to gain access to crypted data. Or boot system up and hack up windows when bitkeeper already is decrypting data. Thats main scenario for 90% vista users who will not use USB sticks PINs and so on. If you are using usb stick with key - it stops there. Either you need usb stick with key or recovery key. Both of them must be stored.

Also recovery key does not have to anything with TPM or usb stick or PIN. It is just letting you access data if TPM goes bad, USB stick lost and PIN forgotten.

Bitlocker not Bitkeeper. Bitkeeper just simply sits too deep in my brain ;)

Hi All Experts:

If I read all of you correctly, BitLocker provides encryption of the OS partition, and thus it protects the user credential and data on the same partition when the HD is powered off. If the data is on a seperate partition but on EFS, then it is also protected since the key to decrypt EFS is protected by BitLocker.
Am I correct?

Although technically BitLocker is meant to complement instead of replacing SmartCard, somehow in terms of business I got a feeling that a bean counter high up in the corporate world may argue if a laptop is stolen in the public place by someone who has no knowledge of you, how can he recover your password if the OS partition is encrypted by BitLocker? Guessing from the login screen is not realistic. Windows inserts a long long timeout after a few failed attempts. On the other hand, if it's internal espionage, most spies can get whatever they want by simply asking a naive co-worker!
Since BitLocker and TPM will come with new PCs by default, they may just slash the budget for SmartCard. What do readers of this blog think? Any advice for these bean counters?

Folks here have also mentioned that although the HD is decrypted by BitLocker after the startup phase, the OS would protect credentials like passwords once it's running. Is it really so? I don't have a copy of Vista, but I remember with XP or prior OS, the installation CD allows you to access many of the system files if you boot to a 'repair console' (I don't remember the exact name). I am not sure if a user credential can be accessed from the repair console though, but does anyone know for sure it cannot be done?

Lastly does anyone know on a laptop with a built-in fingerprint login device, where is the fignerrprint credential kept and when is it checked? Is it stored just like a Windows login password and checked in the same fashion?

If the repair console did allow access to password or fingerprint, then BitLocker in the basic mode without a PIN or USB drive is useless in my opinion.

Thanks!
New Guy

Speaking from recent experience with software based drive encryption. I am hoping the microsoft hardware assisted effort is a lot better. The software we had to install basically cut my battery life in half on my laptop. As well as slowed overall system performance when it comes to IO related task.

So I for one am hopefull that the hardware assisted effort done inteligently will restore some of the perform lose that can be experienced from a software based only implementation.

And yes this is a fairly new laptop. From what I can tell with this particular software installs a device driver layer that basically runs all the time. The problem with that is that it never allows the power saving features of the laptop to really kickin.

Unfortunately, this software is on disk protection. i.e. the key to decrypt the drive is stored on the drive. From what I can tell the package loads some type of executable before the os boots. Which basically means all I have to do is connect the drive to a different system find where the executable is being load from (bootsector anyone). And go after the decrytion routines from there, and where the key is stored.

By storing the key off the system microsoft is tring to aviod the flaws from the above. What good is the 256 bit AES encrytion if the key is stored locally? Any good game cracker can break the above software implementation.

The sad part of this is that legally the company meet the requirements placed on them. But from a real security standpoint, the only thing the did was add to the cost of support. Since I was told the users with older system were getting blue screens and disk corruption after installing the software package. Those user will have to get new systems that have a bois that can handle the software.

Of course microsoft's solution would require new hardware also. But they do offer a more secure solution to the problem.

Hi Lone-Wolf,

Thanks for sharing your experience with software based solution. I didn't know it compromises so much performance and battery life!
However, I'm not sure Vista + TPM will make any difference in the performance and power saving area. My understanding is that with the new solution the encryption key for your data is STILL stored on the hard drive, but rather than protected by a whimpy password, it's scrambled by another key which is now stored in the TPM chip.
It is STILL your CPU doing the encryption of your data. When they say TPM would do encryption, it only encrypts the key stored on the hard drive, not your user data!
On the other hand, since TPM only exists on newer machines, which may have better power management system, but that is a different issue.

Sincerely,
New Guy

Even if hardware is getting faster every day, won't this kind of encryption slow down the system?

Why implement boot-level encryption to a HD using the operating system. The bios offers that for years and there are commercial sollutions out there (also bios based) that make up even a nice interfiace.

My fear is that Microsoft overdoes it with features and failes again at what they should do: deliver the product with all promised features. Result: most users will disable this functionality just like the good old "indexing service" that came with XP and related releases.

And... what about WinFS which is still unfinished and the new Crypto stuff? Will it be compatible or wil it produce just some more security leaks?

Bah, I love my MAC notebook. ;)

will bitlocker works if there is a third partition (fat32 for recovery) ?

What about a dishonest RAM?

0 Steal laptop.
1 Replace RAM with dual ported RAM connected to some other system.
2 Boot system in default mode.
3 Look for and modify any code you know will be run with high privilege as a result of an external event.
4 Trigger by letting that event happen, your code now reaches the cleartext of C: and can send it over a network port.

I guess the TCP stack or any GUI code run during login would work.

What will happen if I or MS screws up my OS and I need to do some repairments. Yesterday I lost my ntldr file on my XP machine, needed to boot with a boot disk to fix it...

One problem with bitlocker is that you can only encrypt the C drive. Is there any way to encrypt a second drive? Note that my pc does not have TPM so I use a USB key.

one question, can a c drive with bitlocker in usb mode be accessed at all? even by top world law agencies?

A BIT OF WARNING WHEN USING BITLOCKER !!!

Imagine the following scenario:

You are evaluating a fake "OEM-activated" windows vista and your primary disk is encrypted with bitlocker.

Everything goes well but suddenly your mainboard fails badly and you have to change it.

As you change motherboard, vista loses its activation, and, because you are running as vista-demo, bitlocker disappears.

If you don't have bitlocker, you cannot unencrypt your disk to copy it to another device

THIS MEANS THAT
The first serious hardware failure makes your data disappear! YES !

______________________

YOU LOSE YOUR DATA.
______________________

Solution:

No bitlocker in system partition,
Use truecrypt for the other partitions.

OR

Use bitlocker on a very small system partition with no precious data
so you can easily format it.
Use truecrypt for the other partitions.

My experience w/ BitLocker has been good. I don't have a TPM so I lug around a USB to unlock the machine. The impact on I/O seems to be negligible.

It's always interesting to see those "but BitLocker doesn't defeat THIS attack!" posts (not necessarily on this blog), as though BitLocker is supposed to be a panacea for ALL possible attacks. That's just silly. I am disappointed that BitLocker doesn't support multiple volumes (via the Control Panel applet, that is), but I believe that's being remedied in SP1.

And no, I don't think that law enforcement will easiliy crack through BitLocker with their imaginary super-computers. However, there's a good chance they'll force users to reveal their PINs/USBs through persuasion....

About the concern for "A BIT OF WARNING WHEN USING BITLOCKER !!!"

I do not believe this scenario will happen. Even if your mobo fries and it is replaced. You Windows Vista edition doesn't change. What you have inside is still Vista Ultimate, but unvalidated. You should still be given a chance to activate it. Bitlocker should not turn itself off.

You encryption key doesn't change. Assuming its stored on a USB. Its basically a text file so to speak.

The only situation that happens is an attempt to install a different version of Vista (thus overwriting the unencrypted partition).

Welcome, correct me if I am wrong.