Wednesday, January 21, 2009

Why do I miss Microsoft BitLocker?

In the previous post, I wrote the only one thing I really miss after I've switched from Vista to Mac is the BitLocker Driver Encryption. I thought it might be interesting for others to understand my position, so below I describe why I think BitLocker is so cool, and why I think other system disk encryption software sucks.

So, it's all about the Trusted Boot. BitLocker does make use of a trusted boot process, while all the other system encryption software I'm aware of, does not. But why the trusted boot feature is so useful? Let's start with a quick digression about what the trusted boot process is…

Trusted boot can be implemented using either a Static Root of Trust or a Dynamic Root of Trust.

The Static Root of Trust approach (also known as Static Root of Trust Measurement or SRTM) is pretty straightforward — the system starts booting from some immutable piece of firmware code that we assume is always trusted (hence the static root) and that initiates the measurement process, in which each component measures the next one in a chain. So, e.g. this immutable piece of firmware will first calculate the hash of the BIOS and extend a TPM's PCR register with the value of this hash. Then the BIOS does the same with the PCI EEPROMs and the MBR, before handling execution to them. Then the bootloader measures the OS loader before executing it. And so on.

An alternative method to implementing trusted boot is to use Dynamic Root of Trust (often called Dynamic Root of Trust Measurement or DRTM). Intel's TXT technology, formerly LaGrande, is an example of a DRTM (more precisely: TXT is more than just DRTM, but DRTM is the central concept on which TXT is built). We will be talking a lot about TXT next month at Black Hat in DC :) This will include discussion of why DRTM might sometimes be preferred over SRTM and, of course, what are the challenges with both.

Essentially, both SRTM and DRTM, in the context of a trusted boot, are supposed to provide the same: assurance the system that just booted is actually the system that we wanted to boot (i.e. the trusted one) and not some modified system (e.g. compromised by an MBR virus).

BitLocker uses the Static Root of Trust Measurement. SRTM can really make sense when we combine it with either TPM sealing or attestation feature. BitLocker uses the former to make sure that only the trusted system can get access to the disk decryption key. In other words: BitLocker relies on the TPM that it will unseal (release) the decryption key (needed to decrypt the system partition) when and only when the state of chosen PCR registers is the same is it was when the decryption key was sealed into the TPM.

Ok, why is this trusted boot process so important for the system disk encryption software? Because it protects against a simple two-stage attack:
  1. You leave your laptop (can be even fully powered down) in a hotel room and go down for a breakfast… Meanwhile an Evil Maid enters your room. She holds an Evil USB stick in her hand and plugs it into your laptop and presses the power button. The system starts and boots from the USB. An Evil version of something similar to our BluePillBoot gets installed into the MBR (or to a PCI EEPROM). This Evil Program has only one task — to sniff out the encryption software's password/PIN and then report it back to the maid next time she comes...
  2. So, you come back to your room to brush your teeth after the breakfast. Obviously you cannot refrain from not turning on your laptop for a while. You just need to enter your disk encryption passphrase/PIN/whatever. Your encryption software happily displays the prompt, like if nothing happened. After all how could it possibly know the Evil Program, like BluePillBoot, has just been loaded a moment ago from the MBR or a PCI EEPROM? It can not! So, you enter the valid password, your system gets the decryption key and you can get access to your encrypted system...
  3. But then you have an appointment at the hotel SPA (at least this little fun you can have on a business trip, right?). Obviously you don't want to look so geeky and you won't take your laptop with you to the SPA, will you? The Evil Maid just waited for this occasion… She sneaks again into your room and powers up your laptop. She presses a magic key combo, which results in the Evil Program displaying the sniffed decryption password. Now, depending on their level of subtleness, she could either steal your whole laptop or only some more important data from the laptop. Your system disk encryption software is completely useless against her now.
(Yes, I know that's 3 bullets, but the Evil Maid had to sneak into your room only twice:)

So, why the BitLocker would not allow for this simple attack? Because the BitLocker software should actually be able to know that the system gets compromised (by the Evil Program) since the last boot. BitLocker should then refuse to display a password prompt. And even if it didn't and asked the user for the password, still it should not be able to get the actual decryption key out from the TPM, because the values in the certain PCR register(s) will be wrong (they will now account for the modified hashes of the MBR or PCI EEPROM or BIOS). The bottom line is: the maid is not getting the decryption key (just as the user now), which is what this is all about.

At least this is how the BitLocker should work. I shall add a disclaimer here, that neither myself, nor anybody from my team, have looked into the BitLocker implementation. We have not, because, as of yet, there have been no customers interested in this kind of BitLocker implementation evaluation. Also, I should add that Microsoft has not paid me to write this article. I simply hope this might positively stimulate other vendors, like e.g. TrueCrypt (Hi David!), or Apple, to add SRTM or, better yet, DRTM, to their system encryption products.

Of course, when we consider an idiot-attack, that involves simply garbbing somebody's laptop and running away with it (i.e. without any prior preparation like our Evil Maid did), then probably all system disk encryption software would be just good enough (assuming it doesn't have any bugs in the crypto code).

Some people might argue that using a BIOS password would be just as good as using trusted boot. After all, if we disable booting from alternate media in BIOS (e.g. from USB sticks) and lock down the BIOS using a password (i.e. using the Power-On password, not just the BIOS supervisor password), then the above two-stage attacks should not be feasible. Those people might argue, that even if the Evil Maid had cleared the CMOS memory (by removing the CMOS battery from the motherboard), still they would be able to notice that something is wrong — the BIOS would not longer be asking for the password, or the password would be different from what they used before.

That is a valid point, but relaying on the BIOS password to provide security for all your data might not be such a good idea. First problem is that all the BIOSes have had a long history of various default or "maintenance" passwords (I actually do not know how the situation looks today with those default passwords). Another problem is that the attacker might first clear the CMOS memory, and then modify her Evil MBR program to also display a fake BIOS password prompt, that would accept anything the user enters. This way the user will not be alerted that something is wrong and will be willing to provide the real password for drive decryption when prompted later by the actual drive encryption software.

One might ask why can't the attacker use the similar attack against BitLocker? Even if the real BitLocker uses trusted boot process, we can still infect the MBR, display the fake BitLocker PIN prompt and this way get into the possession of the user's PIN.

This attack, however, can be spotted by an inquisitive user — after all, if he or she knows they provided the correct PIN, then it would be suspicious not to see the system being booted (and it won't boot, because the fake BitLocker will not be able to retrieve the password from the TPM). If the fake BitLocker wanted to boot the OS (so that user didn't suspect anything), it would have to remove itself from the system and then reboot the system. Again this should alert the user that something wrong is going on.

There is also a much more elegant way of defending against the above attack (with fake BitLocker prompt) — but I'd rather let Microsoft to figure it out by themselves ;)

By the way, contrary to a popular belief the BitLocker doesn't protect your computer from boot-stage infections, e.g. MBR viruses or BIOS/PCI rootkits. As we have been pointing out since the first edition of our Understanding Stealth Malware training at Black Hat in August 2007, BitLocker should not be thought as of a system integrity protection. This is because it is trivial, for any malware that already got access to the running Vista, to re-seal the BitLocker key to arbitrary new system firmware/MBR configuration. Everybody can try it by going to Control Panel/BitLocker Driver Encryption, then clicking on the "Turn Off BitLocker" and choosing "Disable BitLocker Drive Encryption". This will simply save your disk decryption key in plaintext, allowing you to e.g. reflash your BIOS, boot Vista again and then to enable BitLocker again (this would generate a new key and seal it to the TPM with the new PCR values).


This functionality has been provided obviously to allow user to update his or her firmware. But what is important to keep in mind is that this process of disabling BitLocker doesn't involve entering any special password or PIN (e.g. the BitLocker's PIN). It just enough that you are the default user with admin rights or some malware running in this context. Pity they decided on the simplest solution here. But still BitLocker is simply the one coolest thing in Vista and something I really miss on all other OSes...

23 comments:

MathieuMa said...

Excellent reading, very detailed with clear explanation - a particular achievement for a complex subject as this one :)

There is one thing that troubles me with this tight security though - you'd better have nice backups as from what I understood, any modification (bios, mbr, pci) would render the access unusable.

You now have another point to secure : a proper backup system (don't tell me it will be as secure as this)

joanna said...

Buckups are always a good idea ;) Nevertheless Bitlocker does create some recovery keys that are saved on external medias (USB) during installation (and that should be kept in some secure place), just in case somebody forgot to make a backup. Never tried to use those, though.

Jason said...

Great article as usual, Joanna. But does that one benefit really make you trust BitLocker over an open-source system like TrueCrypt? The simple fact that BitLocker is closed-source makes me hesitant to trust it.

Anonymous said...

Curious joanna, what are you using now on your mac for disk encryption?

Anonymous said...

PGP Whole Disk Encryption supports TPM as well

joanna said...

@anonymous: "TPM support" doesn't automatically mean that the product also implements trusted boot process! I haven't looked at the PGP Whole Disk Encryption. Can anybody confirm it does trusted boot? If so is it SRTM or DRTM?

joanna said...

http://www.pgp.com/products/wholediskencryption/

...so, it doesn't seem PGP WDE supports trusted boot. Yes, it does support some tokens, but they do not prevent against described above Evil Maid Attack (The Evil Program AKA BluePillBoot can simply sniff the decryption key itself, once it becomes unlocked, instead the passphrase).

Anonymous said...

Why did you switched from Vista to MacOS?

joanna said...

Why did you switched from Vista to MacOS?
Because I prefer Mac OS X's look-and-feel :)

Anonymous said...

Wouldn't it be easier and more logical for the EVIL maid to use a hidden web-cam capture your password instead of going to this extreme?

Joe

joanna said...

@Joe: Where and how would you like to mount the camera? Remember it would have to have a good sight at the keyboard. It is very hard to do in practice (maybe it works well for ATMs on a busy street, but definitely much harder for a laptop).

Also, I doubt one could mount a h/w keystrokes sniffer, assuming the victim uses some modern branded laptop, e.g. MacBook Air (and probably any other recent MacBooks) -- there just is not enough space in modern branded laptops to fin a sniffer in there.

Anonymous said...

don't know if laptop mobo`s, but desktops has various features against the viruses in MBR or bios alternation...
I wonder what will your maid do when i am using 10MB file on the usb stick instead of stupid password...

joanna said...

@anonymous: What "various features [in desktops] against the viruses in MBR or bios" you refer to?

As to what the Evil Maid should do in case you used a keyfile, e.g. on a USB, instead of a passphrase? The attack would be not much different -- the Evil Program would just have to sniff this keyfile, instead of the keystrokes.

joanna said...

@anonymous (cont.): As you might have noticed I didn't write about "BIOS infection", but rather about PCI EEPROM.

Anonymous said...

yes but the size of memory is limited as well of MBR sector...

joanna said...

yes but the size of memory is limited as well of MBR sector...

I think you assume that the Evil Program can get access to only the first 640kB of RAM and only to the first sector of the disk, is it what you're saying here?

This is absolutely not a correct assumption. If you look e.g. at the design of our BluePillBoot, you will notice that it switches to Protected Mode at the very start. This allows it to access all the RAM memory installed in the system. Of course, the original MBR's code is being run in a VM that might be in real mode (at least until this code decides to switch to protected), but that is irrelevant.

Also, I don't see why would the Evil Program (even if something much simpler then BluePillBoot was used) would have to be limited to accessing only the first disk sector?

Anonymous said...

following your conversation with anonymous, i wonder what will happen to data on encrypted disk when you will write something to the next drive sectors?
If he (anonymous) is using 10 MB key or file, whatever when your program will have to catch there is definitely no space in MBR...
Paul.

joanna said...

@Paul: there is no need to store the sniffed passphrase in the MBR. It could be stored e.g. in some unencrypted partition, or it could be transmitted over the network, once the system gets booted.

Also, if the user uses a large passphrase (or a keyfile), then there would be no point in sniffing out the whole passphrasee/keyfile, but rather to sniff the resulting decryption key (e.g. 256 bits for AES), something very small.

Anonymous said...

I think usually have laptops one partition and if they have two i would encrypt them both. But you have truth about the pass phrase. we are using pointsec in company and you have to have smardcard and pin to boot to system so it is probably something like preboot authentication, is it your evil program so skilled that can overtake pointsec capi and sniff desired information?
Paul

Anonymous said...

Trusted Computing must still be considered experimental. You can see that from your own findings on Intel TXT. Many vendors ship buggy TPMs, BIOSes or have bad deployment chains.

I would never trust BitLocker to do the stuff right that other projects with strong security in mind still fail to completely implement. See for example here: http://os.inf.tu-dresden.de/papers_ps/kauer07-oslo.pdf

However, you can implement something similar with Linux today. Using a compliant platform(HP/Intel), TrustedGrub or OSLO and trousers in an initramfs. IBM even documented how to do that in google.com/search?q=IBM+blueprint+ecryptfs trousers

joanna said...

@Anonymous: Of course Trusted Computing is still in the beta stage. But still is light years ahead of the conventional non-trusted-computing, software-only solutions, that are vulnerable by design, at least against some attacks, like e.g. against the Evil Maid Attack described above.

As for your argument: I would never trust BitLocker to do the stuff right that other projects with strong security in mind still fail to completely implement. -- I really don't get your point here. Why would you think that a bunch of opensource developers would produce better quality code then a bunch professional developers working for a company that has been recently known for their great focus on security? (Yes I'm talking about Microsoft)

Have you actually tried using by yourself any of those opensource TC projects you mentioned? Because it seems that:
1) OSLO is only for AMD processors, which makes it completely useless today, where 99% of notebooks are Intel-based. Also it seems to be an abandoned project, since 2007.
2) TrustedGRUB seems also dated -- look at the list of hardware it supports:
http://trousers.sourceforge.net/grub.html
3) The IBM's paper you quote doesn't explicitly mention any program to perform trusted boot. Even if we used the method they propose with e.g. TrustedGRUB, it seems to me like there would be lots of holes in such a configuration -- e.g. there is a huge gap in the trusted chain between the boot loader (that might be trusted boot loader) and the moment we start the eCryptfs (via /etc/init.d scripts!!!).

Anonymous said...

Joanna,

it is not just a bunch of OSS developers. Please take a look at the OpenTC project. Right now, I don't know of any OSS TC software that does not have its roots in one of the OpenTC partners. And I have more trust in what these people do, because they don't have obscurity on their side. MS is the only big vendor that tries to sell this highly experimental stuff already. This only confirms what I think about their opinions on security. As it happens I'm working in OTC myself. Call me biased. :-)

And of course I agree with you, there is quite some potential in this technology. Unfortunately, current OSes are not designed to benefit from this stuff. The basic element of TC is the measurement of some code. But if your code is unstable and updated every week, measurements become useless before anybody can "trust" them to do what is expected.

Regarding number three:

One of the most critical thinks in this area is good architecture. And you are totally right, Linux has a huge and volatile TCB. As does Windows and OSX.

But at least for full disk encrytion, there you can work around that. TrustedGRub measurs all the binaries it loads, including the menu.lst. So when ecryptfs in loaded from a ramdisk(initrd) before starting stuff from disk, you're okay.

We're investigating ukernel-based systems in that matter. The capabilities for isolation, reliability, modularity and seperate TCB make them look quite promising.

Anonymous said...

I'm not that familiar with this technical level, but if the Vista/Win2008 machine would run in a VMWare/XEN environment, could/would Bitlocker defend against MBR rootkits?
As I understood it, it would do the job if Vista/W2k8 would be installed as the host on the hardware and due to EULA it can't/mustn't be used in a VM... but could it technically do the job of preventing an virtual Server to be subverted between Hypervisor and OS?

Thank You for the insights!