defending against evil in all layers of hardware and software

[Perry E. Metzger]

John Denker <jsd at av8n.com> writes:
> This is an important discussion  
>
> The threats are real, and we need to defend against them.

I'm not sure how to feasibly defend against such things. It would seem
to require complete control over the entire design and supply chain,
which involves so many thousands of people who could be bribed that I
have serious doubts that it can be done perfectly.

> This should not be an occasion for idly wringing our hands, nor 
> sticking our head in the sand, nor looking under the lamp-post 
> where the looking is easy.  We need to look at all of this stuff.  
> And we can.  We are not defenseless.

I'll believe that when I see feasible defenses. So far as I can tell,
if you can't trust the hardware supplier, you're meat. I don't think
it is possible even in principle to validate the hardware after the
fact. Even if you could apply formal methods successfully, it isn't
even obvious how you would specify the property of the system that
you're trying to prove. "Never does anything bad" is kind of nebulous
if you're doing proofs.

> As in all security, we need not aim for absolute security.  An 
> often-useful approach is to do things that raise the cost to 
> the attacker out of proportion to the cost to the defender.

Well, this sort of thing is already not that interesting to an
ordinary spammer or phisher -- they have no trouble making loads of
money without engaging in such stuff.

If you're talking about what a national government might pay to get
such a back door in hardware, though, I think that it is probably
worth billions to such an entity. After all, a decent bomber these
days costs a billion dollars, and clearly this is a lot more potent.

Given that, I don't see what would work in practice. If a major power
wanted to turn a couple of engineers at the right place in the design
or supply chain, the amount of money needed is far below the amount in
play.

> For software, for firmware, and to some extent even for silicon
> masks, SCM (source code management) systems, if used wisely, can
> help a lot.

If you have a rotten apple engineer, he will be able to hide what he's
trying to do and make it look completely legit. If he's really good,
it may not be possible to catch what he's done EVEN IN PRINCIPLE. All
an SCM can do is tell you who put the bad stuff in much after the fact
if you ever catch it at all. That's not exactly "defense". It is at
best "post mortem".

> Of course we should insist on an open-source boot ROM code:
>   http://www.coreboot.org/Welcome_to_coreboot

Won't help. A bad apple can probably manage a sufficiently subtle flaw
that it won't be noticed by widespread code inspection. See Jerry's
earlier posting on the subject.

> Another line of defense involves closing the loop.  For example,
> one could in principle find Ken's trojan by disassembling the
> compiler and looking for code that doesn't seem to "belong".

Only if the bad guy doesn't anticipate that you might do that.

I'm pretty sure we can defend against this sort of thing a lot of the
time (by no means all) if it is done by quite ordinary criminals. If
it is done by really good people, I have very serious doubts.


-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com