Trusting Hardware

So, you're a decent paranoid person, running only open source software on your box: Linux, GNU, etc. You have the feeling you could, if you only wanted to, review every single line of code (of course you will probably never do this, but anyway). You might be even more paranoid and also try running an open source BIOS. You feel satisfied and cannot understand all those stupid people running closed source systems like e.g. Windows. Right?

But here's where you are stuck — you still must trust your hardware. Trust that your hardware vendor has not e.g. built in a backdoor into your network card micro-controller…

So, if we buy a laptop from vendor X, that might be based in some not-fully-democratic country, how do we know they didn't put backdoors there? And not only to spy on Americans, also to spy on their own citizens? When was the last time you reverse-engineered all the PCI devices on your motherboard?

Scared? Good!

Enters the game-changer: IOMMU (known as VT-d on Intel). With proper OS/VMM design, this technology can address the very problem of most of the hardware backdoors. A good example of a practical system that allows for that is Xen 3.3, which supports VT-d and allows you to move drivers into a separate, unprivileged driver domain(s). This way each PCI device can be limited to DMA only to the memory region occupied by its own driver.

The network card's microcontroller can still compromise the network card driver, but nothing else. Assuming we are using only encrypted communication, there is not much an attacker can gain by compromising this network card driver, besides doing a DoS. Similarly for the disk driver — if we use full disk encryption (which is a good idea anyway), there is not much an attacker can gain from compromising the low-level disk driver.

Obviously the design of such a system (especially used for desktop computing) is not trivial ans needs to be thoroughly thought out. But it is possible today(!), thanks to those new virtualization technologies.

It seems than, that we could protect ourselves against potentially malicious hardware. With one exception however… we still need to trust the CPU and also the memory controller (AKA northbridge AKA chipset), that implements that IOMMU.

On AMD systems, the memory controller has long been integrated into the processor. Also Intel's recent Nehalem processors integrate the memory controller on the same die.

This all means we need to trust only one vendor (Intel or AMD) and only one component, i.e. The Processor. But should we blindly trust them? After all it would be trivial for Intel or AMD to build in a backdoor into their processor. Even something as simple as:

if (rax == MAGIC_1 && rcx == MAGIC_2) jmp [rbx]

Just a few more gates in the CPU I guess (there are apparently already about 780 million gates on Core i7, so a few more should not make much difference), and no performance penalty. Exploitable remotely on most systems and any more complex program I guess. Yet, totally undetectable for anybody without an electron microscope (and tons of skills and knowledge).

And this is just the simplest example that comes to mind within just a few minutes. I'm sure one could come up with something even more universal and reliable. The fact is — if you are the CPU vendor, it is trivial for you to build in an effective backdoor.

It's funny how various people, e.g. European government institutions, are afraid of using closed source software, e.g. Windows, because they are afraid of Microsoft putting backdoors there. Yet, they are not concerned about using processors made by some other US companies. It is significantly more risky for Microsoft to put a backdoor into its software, where even a skilled teenager equipped with IDA Pro can find it, than it is for Intel or AMD, where effectively nobody can find it.

So, I wonder whether various government and large corporate customers from outside the US will start asking Intel and AMD to provide them with the exact blueprints of their processors. After all they already require Microsoft to provide them with the source code under an NDA, right? So, why not the "source code" for the processor?

Unfortunately there is nothing that could stop a processor vendor to provide its customers with a different blueprints than those that are used to actually "burn" the processors. So, the additional requirement would be needed that they also allow to audit their manufacturing process. Another solution would be to hire some group of independent researchers, equip them with an electron microscope and let them reverse engineer some randomly chosen processors… Hmmm, I even know a team that would love to do that ;)

A quick summary in case you get lost already:

1. On most systems we are not protected against hardware backdoors, e.g. in the network card controller.
2. New technologies, e.g. Intel VT-d, can allow to protect against potentially malicious hardware (requires specially designed OS, e.g. specially configured Xen)…
3. … except for the potential backdoors in the processor.
4. If we don't trust Microsoft, why should we trust Intel or AMD?

BTW, in May I will be speaking at the Confidence conference in Krakow, Poland. This is gonna be a keynote, so don't expect new attacks to be revealed, but rather some more philosophical stuff about trusted computing (why it is not evil) and problems like the one discussed today. See you there!