Is BitLocker Misdirected?

As blogged recently by the Bitlocker crew, the behaviour of BitLocker in Windows Vista RC1 has been changed – there were originally three methods of providing the regular unlock key to Bitlocker, and this has been reduced to one without some irritating Group Policy mularkey.

The key method that is left enabled by default is that of providing the key from the on-board TPM chip, after it has verified the boot code.


The two previous methods were TPM + PIN, where the user had to enter a 4-to-20 digit numeric key; and USB, where the TPM chip didn’t necessarily play any part, but the user had to provide a 128-bit key on a USB thumb-drive.


These methods are still available, if you want to go through an onerous Group Policy change, but they are hidden from users because, apparently, they are too complex for most users to use correctly.


Given that Bitlocker is an acknowledgement that the user is carrying data that we’d like to see made inaccessible rather than hand it to hackers, I’m sceptical that we should be assuming that the user – or more precisely, the system installer, is incapable of following technical instructions.


That aside, the use of TPM alone, followed by the statement from the BitLocker crew that BitLocker is designed to protect against offline attacks on a stolen laptop, suggests that they may have lost sight of their goal.


First, yes, strictly speaking, BitLocker does protect against an offline attack on the hard drive, no matter what keying material is used – TPM, TPM+PIN, or USB.


But that’s only half of the picture.


What about an online [i.e. powered-on] physical attack?

If I steal your laptop, protected by BitLocker, with TPM alone, I have everything I need to bring the system from a powered-off, encrypted, protected state, to a powered-on, decrypted, less-protected state. If I know an attack against your OS that can be achieved through any of the numerous holes on the outside of the machine (usually labeled “ports”), I can attack that machine at my leisure, while it’s running.


Quite simply, all I need do is wait for the next Vista exploit to do the rounds, and I can attack through the network, or the USB, or the parallel connection, or the 1394, or …


And while I respect the work that has been done to secure Vista, I’m certain that there will be a way to exploit a machine, “protected” by BitLocker and TPM, to which I have physical access.


[Maybe I don’t have to wait so long – USB devices, after all, get direct access to the system’s memory.]


Better by far is a solution where the keying material is kept away from the computer (such as the USB or TPM+PIN methods), so that the computer is not only protected against incursions into the operating system before it boots, but is also prevented from booting until you can provide keys that indicate you are the owner.


As it stands, Bitlocker + TPM – the only option available by default – will only protect the operating system from pre-boot incursion. Unlike other drive-encryption software, it will then allow the boot to proceed, exposing a wider attack surface to the thief.

13 thoughts on “Is BitLocker Misdirected?”

  1. Hi Alun,

    So, what happened to “secure by design, secure by default”? Did Microsoft decide that one of their more useful security features in Vista would be better if it was crippled into close-to-uselessness?

    It sure seems that way – by default. It is secure by design, sure, but only a half-arsed implementation by default. This is a very backwards way of going forwards.

    Regards,
    HiltonT

  2. I’m with you. I like to stick with the concept that you should never assign to malice that which can be adequately explained by stupidity (or naivete, or short-sightedness, or whatever), so I have to believe that there’s reason behind this.
    My best guess is that the team were given a mandate – make it so that a hacker can’t steal my laptop, remove my hard drive, and mount it in his machine to access my data.
    If the mandate were to be reworded, “make it so that a hacker can’t steal my laptop and access my data”, it would be clear that TPM-alone is an inappropriate choice, and an inappropriate default.

  3. Ain’t TPM alone protects from HW changes only? Then the overall (physical) security (of the device) is the weakest one. You have recovery key (presumably the stronger option), but none (with TPM alone or just very weak max 20 digit numeric key with TPM+PIN) on normal boot. The dumb question – How the TPM helps if the machine is stealed? Even USB with 128bit key seems to be better, but why no USB+PIN option? Why no finger print (or iris on laptop w/ built-in videocam) + PIN option available?

  4. TPM-only is designed to protect against someone installing extra software in your boot code.  Anyone with the skills or money to go about messing with boot code is likely to go for the easier route of booting the machine with untampered code, and then finding a way in through the external ports, particularly through the network.

    TPM-only allows your system to be taken, by an attacker, from a small, relatively simple and secure environment, where the disk is encrypted, to a large, complex and less-secure environment (the running OS), where the disk is effectively decrypted.

    Realistically, of course, if your laptop is stolen, it will most likely be wiped (rendering it impossible to boot, even with TPM-only protection on Bitlocker) and sold at a pawn shop to someone who wouldn't be interested in your data, or have the tools to get at it.  However, if you're responsible for the data of thousands of people – a valuable commodity – can you afford to take that risk?

    As for your question about "why not use fingerprints?", aside from my usual note that fingerprints are not equivalent to passwords, I'll also note that the code for Bitlocker is small, and loads between the BIOS and the OS.  Bitlocker can't use as key storage anything that requires a device driver, or isn't exposed by the system BIOS.

  5. Okay, so seems BL provides just protection on boot and sits between BIOS and OS boot loader. But you mentioned it is small piece of code that BTW resides on plain unprotected 1.5GB NTFS partition. What can prevent from hacking that?
    Also, as MS stresses, BL is _not_ designed for user authentication (nor authorization?). I think the simple VM + its image container encryption is the way to go for many laptop users. Another way is BartPE (or now Vista WinPE?) booting environment with encryption sw pre-installed. Unfortunately, both have their problems (performance, ease of use). Anyway, MS BL just doesn’t seems to be the tranparent encryption security solution that effectively protect the laptop owners for instance. Sure fingerprints or iris (i.e. biometrics) aren’t that reliable yet, and a booted OS drivers are the unfortunate requirement (until PC makers will integrate pure hw + flashable eprom sensors in their machines). IMHO the one possible solution for now is using USB sticks with passphrase/PIN to boot PC/laptop with all the drives encrypted by a transparent encryption sw. Do you aware of the working solutions based on that, does this allow to have just small (maybe DOS based) encryption sw on USB stick or still forces to build entire (wanted for the target PC) OS image in there?

  6. What can prevent from hacking the unencrypted boot code? Simple – the TPM chip. The boot process requires that the boot code match the checksum stored in the TPM chip.
    Of course, another protection for hacking the boot code is to require an external key (password, USB, etc) to provide material from which you build a key that is involved in the decryption key chain. That way, you can hack the boot code all you like, but without the external keys, you can’t get at the data. [The scenario of the lost laptop returned to its owner is relatively uninteresting and should generally be protected by policy and practice – returned laptops should be backed up, then re-imaged, because you should assume that they are suspect].
    There are several other solutions out there that will encrypt the drive and use a pass-phrase, or an external token, to provide the decryption key. The ones I’ve seen aren’t as manageable, however, as BitLocker.
    At my job, we use PGP Whole Disk Encryption, but its management facilities across a large organisation are not easy.

  7. I’m sorry but I don’t understand how you can say that BL with TPM only don’t protect your data if someone steal your laptop ? It’s impossible to log on without the user’s password and data are still encrypted because the decryption/encryption is an real time action done for every read/write action.
    Thanks for your help.

  8. “Bitlocker with TPM only” only goes so far.
    If I steal your laptop, I can now turn it on, and watch it boot back at my lair.
    I can turn it off and on time and again, and I can try to log on as many times as possible.
    Or, I could ignore the logon prompt entirely, and attack the system through the network ports (how long before someone discovers a network vulnerability?), or through USB, or CDs with AutoRun (okay, so that requires that some idiot disabled the AutoRun prompting, but hey, we’re talking about a defence that could and should prevent any attack against the physical machine).
    If there is a wormable vulnerability, or an exhaustive attack exploit, I can plant my code inside the machine, and – as you point out – “encryption / decryption is a real time action for every read/write”, so I’m able to read the drive through the OS as if it was never encrypted.
    Other drive encryption methods rely on external keying material – thumbdrives, passwords, etc. They are vulnerable to these same attacks only if the thief steals the laptop while it’s powered on, and doesn’t shut it down or hibernate it (which means, in my case, that he doesn’t cloes the lid!)

  9. Why does no-one ever mention ATA-3 hard disk passwords?  An 8-digital password required during the BIOS phase might not seem secure but a 3-retry before power-cycle limit and the disk implemented low-level format before unlock with supervisor password makes it really quite good!  Plus, no overhead at all during reads or writes.

    Shame certain manufacturers watered it down by coding the supervisor password as 8 spaces.

  10. Has anyone recently implemented a usb key solution? I understand from this post and others that there are some group policy gotchas and I wonder if it is really all that bad of a config. Perhaps someone could speak to this if possible…
    Thanks.

  11. I just installed bitlocker using a USB key only. I ran the bitlocker drive preparation tool that MS provided recently which makes the process quite easy. It creates the boot partition and copies all the startup files to it. I also had to run gpedit.msc to modify the bitlocker options so I could use a USB key since my system has no TPM chip. The 300GB drive encrypted in about 2.5 hours. My only concern is that if a laptop or PC is stolen with the USB key, then the encryption is useless. I would rather have the option of requiring a password, like most of the other disk encryption products out there. Relying on a physical key alone is less secure.

  12. I’m with you there – either with TPM, or with USB, or any other solution that has a good chance of packing the key material in with the laptop (hey, passwords on sticky notes count in that category!), you have a good chance that the machine can be booted – and once booted, how many services are listening and waiting for an attack on the network port, on the USB port, on the parallel port, on the serial port, on the FireWire port, on the card reader, on the PC Card port, on the Express Card port, through the video card, the PS/2 port, the CD / DVD ROM drive, the media card reader, etc?
    One of them’s likely to be exploitable by the time your machine gets stolen. Or maybe the thief takes your laptop, and waits a month or two until an exploitable vulnerability gets released, then uses that to hack in?
    If all the keying material rides with the computer – like with the TPM chip – your data is really not that safe.

Leave a Reply

Your email address will not be published. Required fields are marked *