On CPU backdoors - Trusting hardware
theinvisiblethings.blogspot.com
theinvisiblethings.blogspot.com
In the long run, verifying the functionality and intentions of software and hardware are probably roughly the same problem, with no clear solution to either in the foreseeable future.
[1] http://www.wired.com/dangerroom/2011/08/problem-from-hell/
If you are a PhD student and aren't working on something you consider 'one of the more interesting ... problems' then you are doing it wrong. In my opinion. You seem to be doing it right.
> perhaps because it's not in their best interest to accuse the people designing their ICs of attacking them.
Would you agree that there is some value in having the capability to detect these attacks? Whether you trust the vendors or not, you need them to be aware than you can check their work, at least to encourage them to follow good security practices internally.
Both require trusting the source code (a languages problem), as well as trusting the translator. In the case of software, the translator is an end-user accessible compiler/interpreter which is itself more software, thus recursively auditable.
In the case of hardware, the translator is an entire institution, which can only be trusted if you have recourse against said institution. As an individual end-user (uber alles) can then never fully trust their hardware, it makes sense to draw a line in the sand and proceed from that assumption.
(and suuure, put a picture of a pic16f84, the chip that started the revolution of microcontroller DIY, at the top of an article on dodgy hardware..)
They do seem to be more concerned about chips the US buys from certain other countries than about the likes Intel/AMD building in backdoors.
EDIT: I should also mention that this is not just a concern of the american defence. I'm aware of the indian govt also funding this sort of research with similar motivation. However, in this instance, the professor was trying to attack the problem through the lens of formal techniques. I think the idea was to prove that if the chip interacts with the outside world through these limited set of channels then you can't sneak data out through some sort of covert channel hiding in the "regular" communication. The specific concern here was about routers/switches and the like equipment sneaking sensitive data out of a secure network.
My understanding is that the main concern here are chips in COTS equipment bought from countries that are considered by some to be untrustworthy.
Allegedly the government requiring a domestic fab for some chips is one of the biggest reasons IBM's fab remains funded.
All hearsay though.
Lots of secure labs run on the same Dells and HPs that everyone buys
http://delphi.about.com/od/humorandfun/f/w32-induc-a-delphi-...
Like, say, the US...
Now, you could go with a proportional representation system instead of a winner-in-each-district-takes-all system, but you know who the two big parties with the power would be? The same two.
What are the downsides? Well, for one thing, it might be illegal. Is it? Merely installing a backdoor could be illegal, but I sort of doubt it is. The hardware company might be compliant, or the backdoor could be installed covertly. That might make a difference.
And of course making use of the backdoor could be illegal. US citizens or other people on US soil might enjoy (various degrees of) protection against activities. But I get the impression that the rest of the world is pretty much fair game for US services. The fact that US citizens are protected is brought up again and again in such discussion and doesn't inspire me with a lot of confidence.
Even if they built in some sort of a kill-switch, how could anyone confidently say that a rogue engineer involved in the design couldn't bypass it and use the chip against Intel. Ultimately, I think there's so much danger that I have to assume Intel is competent enough not to do something so foolish as introduce deliberate backdoors.
Intel could keep track of which chipsets are vulnerable and which are not, and carefully pick which kind gets released to who.
Obviously, Intel employees aware of the strategy would only use the invulnerable chipsets themselves.
> that's not very different from trusting your compiler
if you were paranoid enough to be worrying about CPU backdoors, why would you trust your compiler?
Also, trusting your compiler is different from trusting your CPU because one is much, much easier to check than the other. You can build GCC yourself, look at the source code, manually check the output. You could even write your own compiler. In general, we can't make our own processors or verify their internals, yet.
AMD on the other hand, is going fab-less for at least some of their products. TSMC was mentioned in the past as being a partner. So you'd have to trust both AMD and TSMC.
You'd have to write an assembly program and then a hand-translated binary version that can run directly on the bare metal with no OS. And use it to compile the "real" compiler.
I wonder if one could make that simple enough to do be "somewhat reasonable," yet complex enough to compile the real compiler. Probably! Though it may take a team of people quite some time.
I wonder if government(s) have infrastructure/teams that do this already, or if there are any open source projects aimed at this kind of thing.
1. Trusting chip fabs is a non-starter. Institutional security only helps large institutions. You will not audit your fab, nor can you trust other people to do it for you. Unlike software, there is no "certificate" that is easily verified in the event of a backdoored fab.
2. There's two phases in the lifecycle of a backdoor. First, is its latent 'offline' period which is noninteractive with respect to the attacker. For example, a backdoored compiler [RoTT] basically propagates a virus to new copies of the compiler. Solving this seems tractable by eliminating bootstrapping as the sole method for compiling a compiler, and research into interpreted languages that are easily ported to new platforms for the stage0 compiler.
3. The second phase is when the introduced vulnerability is 'active' and ready to be exploited over the network by an interactive attacker. The case of a network-facing compiler-infected binary should be easily solved by solving the first problem. The case of backdoored hardware/microcode is much more insidious, and requires coming up with assumptions to frame the problem for even a chance at being tractable. (Also, it requires the trustable software tools from (2) for implementing the solution)
4. Secure 'offline' computing on its own would be a boon for things like maintaining the integrity of master cryptographic keys (although keep in mind one still has to prevent against a backdoored CPU acting as an infected stage0, but this is much easier in a noninteractive setting). I'm less familiar with state of the art in this area than I should be, but I'm guessing implementations are probably still in the dark ages of 'trust the company'.
You increase the cost of an attack - it's harder to change a processor's behavior by editing the mask than the VHDL. If you were super-paranoid you could source to multiple different fabs and run the chips you get back in parallel, with some sort of trap that goes off whenever you get different results from one or other processor.
>if you were paranoid enough to be worrying about CPU backdoors, why would you trust your compiler?
If you don't trust your compiler, why are you even bothering worrying about CPU backdoors when you've got a much easier attack vector open?
Who's to say you're going to trigger the condition that causes the backdoor? Seems very unlikely. If you have ideas on this, though, I'd be interested.
If you don't trust your compiler, why are you even bothering worrying about CPU backdoors when you've got a much easier attack vector open?
You may not trust your compiler, and therefore do certain things in a VM where e.g. access to network is limited. See [1].
So really you can only trust an analog, optical microscope. Which, also ironically, is not quite good enough to resolve individual transistors (being limited to about 200nm or so, in green light.)
Last but not least, our CPUs are always designed by other computers, so it's theoretically possible that a backdoor could propagate itself forever.
Shades of "Reflections on Trusting Trust," but in hardware. Doesn't have a complete replication loop, though, which would have the compromised hardware re-infecting the very VHDL compilers that generated the chip backdoor :-)