Closed Source Conspiracy

Many people in the industry have an innate fear of closed source (AKA proprietary software), which especially applies to everything crypto-related.

The usual arguments go this way: this (proprietary) crypto software is bad, because the vendor might have put some backdoors in there. And: only the open source crypto software, which can be reviewed by anyone, can be trusted! So, after my recent post, quite a few people wrote to me and asked how I could defend such an evil thing as BitLocker, which is proprietary, and, even worse, comes from Microsoft?

I personally think this way of reasoning sucks. In majority of cases, the fact something is distributed without the accompanying source code does not prevent others from analyzing the code. We do have advanced disassemblers and debuggers, and it is really not that difficult to make use of them as many people think.

Of course, some heavily obfuscated programs can be extremely difficult to analyze. Also, analyzing a chipset's firmware, when you do not even know the underlying CPU architecture and the I/O map might be hard. But these are special cases and do not apply to majority of software, that usually is not obfuscated at all.

It seems like the argument of Backdoored Proprietary Software usually comes from the open-source people, who are used to unlimited accesses to the source code, and consequently do not usually have much experience with advanced reverse engineer techniques, simply because they do not need them in their happy "Open Source Life". It's all Darwinism, after all ;)

On the other hand, some things are hard to analyze, regardless of whether the source code is available or not, think: crypto. Also, how many of you who actively use open source crypto software, e.g. TrueCrypt or GnuPG, have actually reviewed the source code? Anyone?

You might be thinking — maybe I haven't looked at the source code myself, but because it is open source, zillions of other users already have reviewed it. And if there was some backdoor in there, they would undoubtedly have found it already! Well, for all those open source fetishists, who blindly negate the value of anything that is not open source, I have only one word to say: Debian.

Keep in mind: I do not say closed source is more secure than open source — I only resist the open-source fundamentalism, that defines every proprietary software as inherently insecure, and everything open source as ultimately secure.

So, how should one (e.g. a government institution) verify security-level of a given crypto software, e.g. to ensure there are no built-in backdoors in there? I personally doubt it could be performed by one team, as it just usually happens that the same people who might be exceptionally skilled in code review, system-level security, etc, at the same time are average cryptographers and vice-versa.

Imagine e.g. that you need to find out if there are any weaknesses in your system drive encryption software, something like BitLocker. Even if you get access to the source code, you still would have to analyze a lot of system-level details — how is the trusted boot implemented (SRTM? DRTM? TPM interaction?), which system software is trusted, how the implementation withstands various not-crypto-related attacks (e.g. some of the attacks I described in my previous post), etc…

But this all is just system-level evaluation. What should come later is to analyze the actual crypto algorithms and protocols. Those later tasks fall into cryptography field and not into system-level security discipline, and consequently should be performed by some other team, the crypto experts.

So, no doubt, it is not an easy task, and the fact if there is or there is not C/C++ source code available, is usually one of the minor headaches (a good example is our attack on TXT, where we were able to discover bugs in Intel's specific system software, which, of course, is not open source).

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...

Attacking Intel® Trusted Execution Technology

Press people: please read our press release first and also refer to the disclaimer at the end of this blog post. Thank you!

Update: 1/5/2009 19:21 CEST: minor typos/spelling corrections. Thanks to Jarred for point out some of the typos.

A word about Trusted Computing
The term Trusted Computing and related technologies, like Palladium, Trusted Platform Module, LaGrande, have always caused lots of controversy in the IT world. Most of the fear, however, has been a result of the lack of understanding of how a particular technology really works.

Nevertheless, Trusted Computing is becoming part of our lives, whether we want it or not. These days almost every new laptop comes with an on-board Trusted Platform Module (TPM). Microsoft's Palladium initiative have been renamed so many times in the recent years, that probably even people working at Microsoft are confused now. Nevertheless, some of the Palladium technologies made their way into Vista, and Microsoft BitLocker is, without doubt, the most successful, widely deployed product that is based on the idea of Trusted Computing. (In fact the Bitlocker is the only one thing that I really have been missing since I switched from Vista to Mac some time ago).

On the hardware side, besides the famed TPM, we also have had the LaGrande technology, that is often connected with things such as Remote Attestation, Protected Execution and other scary terms…

A word about Trusted Execution Technology
LaGrande, recently renamed Trusted Execution Technology (TXT), is Intel's response to the Trusted Computing trend. TXT is currently part of the vPro™ brand, and for about a year now users can buy a vPro/TXT compatible hardware in regular computer stores (the first one was the DQ35J desktop board with certain Core 2 Duo processors, which I was able to buy at the end of 2007 — remember that TXT requires support from both the CPU and the chipset).

TXT is not an alternative to TPM, in fact TXT heavily relies on the TPM to provide basic services like e.g. secure storage of measurements done by the TXT. Also, Palladium, or whatever it is called these days, is not a competition to TXT. Intel TXT can provide building blocks to e.g. Vista Bitlocker, arguably making it more secure then it is now (Current Bitlocker implementation, AFAIK, relies on a so called Static Root of Trust for Measurement, which requires TPM, but not TXT).

What kind of measurement would TXT like to store in our TPM? Well, the whole TXT is, in fact, all about making and storing software measurements, or, using a more familiar language, secure hashes of certain software components.

The sole purpose of Intel TXT technology is to provide a trusted way for loading and executing system software, e.g. Operating System kernel or Virtualization Machine Monitor. What is extraordinary here is that TXT doesn't make any assumptions about the state of the system before loading the software, thus making it possible for a user to ensure secure load of an OS or VMM, even in a potentially compromised machine.

In other words, our system can be all full of boot sector viruses and BIOS rootkits, and god-knows-what-else, and still TXT should allow to load a clean VMM (or OS kernel) in a secure way, immune to all those rootkits present in the system in a moment just before the load process. This TXT-supported load process is called Late Launch, and is implemented via a special new CPU instruction called SENTER.

It's a good place to mention that AMD has its own version of the late launch implemented via SKINIT instruction. We haven't looked at the AMD technology thoroughly yet, so I will refrain from commenting on this.

The late launch is a pretty amazing thing, when we think about. It promises to effectively provide all the benefits of a computer restart without actually restarting it.

It is hard to overemphasize the potential impact that a technology such as TXT could have on computer security. One can immediately see that it could eliminate all the system-level persistent malware — in other words we can easily build systems (VMMs or even standard OSes) that would be immune to attacks that try to compromise system binaries on disk, or attack the system right from the bootloader or BIOS. Combining this with VT-x and VT-d technologies, system developers (for the first time, at least as far as the "PC" platform is considered) have gotten extremely strong tools into their hands that should allow them to create really secure VMMs and OSes…

Hopefully by now, my Dear Reader, you should have the feeling what kind of an animal Intel TXT is and how desperately the world needs it...

And now, we are going to move on and show practical attacks on current TXT implementations... :)

Attacking Intel TXT!
Ok, not in this post today, but rather at the upcoming Black Hat conference in Washington, DC in February. Over the recent months, Rafal and I have been looking at the Intel TXT technology as part of a work done for a customer, to see if this could be used to improve security of a product, from a typical user's perspective. We figured out that it definitely could, but that there are also some issues…

And those "issues" gave us a starting point in developing a proof-of-concept (albeit very reliable) exploit that shows how we can bypass trusted boot process implemented by Intel's tboot.

Tboot, which is also part of (scroll down to the end of the page) the Xen hypervisor, can be though of as a reference implementation of TXT-based system loader, that could be used to securely load either the Xen hypervisor or the Linux kernel, when run on a vPro/TXT compatible hardware.

[copy-and-paste from the press release follows]

Our attack comprises two stages. The first stage requires an implementation flaw in a specific system software. The second stage of the attack is possible thanks to a certain design decision made in the current TXT release.

While evaluating the effectiveness of the Intel® TXT technology, as part of a work done for a customer, we have identified several implementation flaws in the Intel's system software, which allowed to conduct the above mentioned stage-one attack. We have provided Intel with extensive description of the flaws in December 2008, and Intel is currently working on fixing those vulnerabilities.

We have also been in touch with Intel about the possibility of conducting the second-stage attack since November 2008. In December, after providing Intel with the details about the first-stage attack, Intel promised to release, in the coming weeks, an updated TXT specification for developers that would explain how to design their TXT-based loaders in such a way that they are immune to our attack. Intel claims the current Intel® TXT release does contain the basic building blocks that could be used to prevent our second-stage attack and the release of the additional specification would make it feasible in practice.

More details in February in DC :)

TXT useless?
Some people are skeptical about the TXT technology, and not only because of the Irrational Fear of the Trusted Computing (IFTC), but rather because they point out to the complexity of the whole technology. The complexity is bad, because 1) it leaves more space for potential attacks, and 2) it discourages developers (ISVs) from using the technology in their products (e.g. neither Microsoft, nor VMWare make use of TXT in any of their bare-metal hypervisors, even though TXT is very well suited for this kind of software).

It is true that TXT is a very complex technology (the SENTER instruction is probably the masterpiece of the CISC architecture!), but I personally like it. In my opinion this is the first technology available for the PC platform that has the potential to really change something, much more then the NX-feature did a few years ago. Before people will run to the comment box — if you would like to argue about the usefulness/uselessness of Trusted Computing/TXT, please base your opinions on technical facts (read the spec!) and not on your feelings!

Disclaimer (for press)

Starting January 2009, we (at Invisible Things Lab), decided to issue press releases in addition to this blog. The general rule is: press releases are written for journalists, while the blog is mainly written for other researchers, security enthusiast, etc.

The wording of our press releases is carefully chosen to minimize the potential of a possible misinterpretation. The press releases carry less information, but, we think, are better suited for a more general public, that doesn't have background in computer science, programming and security.

The blog is written in a much more casual way, without thinking for half an hour on every sentence. The articles on this blog might present some facts as extremely exciting, because e.g. for me, a person deeply involved in a system-level security research, they indeed might be very exciting, which might not be the case for a general audience. I sometimes might also use shortcuts, metaphors, or irony, and other figures of speech, that might not necessarily be obvious for a more general public.

If you are a journalist and you think you just found something very sensational on my blog, I would suggest that you double-check with me, before writing about it.

Thank you for your cooperation.
Joanna Rutkowska,
Founder and CEO,
Invisible Things Lab.