Re: Designing and implementing malicious hardware

2008-04-29 Thread COMINT
There are high assurance systems that exist that do eactly this. There are two different implementations of the security unit processing the same data. The outputs are compared by a seperate high assurance and validated module that enters into an alarm mode should the outputs differ. However,

Re: Designing and implementing malicious hardware

2008-04-28 Thread Leichter, Jerry
On Sat, 26 Apr 2008, Karsten Nohl wrote: | Assuming that hardware backdoors can be build, the interesting | question becomes how to defeat against them. Even after a particular | triggering string is identified, it is not clear whether software can | be used to detect malicious programs. It almost

Re: Designing and implementing malicious hardware

2008-04-28 Thread Ed Gerck
Leichter, Jerry wrote: I suspect the only heavy-weight defense is the same one we use against the Trusting Trust hook-in-the-compiler attack: Cross-compile on as many compilers from as many sources as you can, on the assumption that not all compilers contain the same hook. ... Of course,

Re: Designing and implementing malicious hardware

2008-04-28 Thread Perry E. Metzger
Ed Gerck [EMAIL PROTECTED] writes: Each chip does not have to be 100% independent, and does not have to be used 100% of the time. Assuming a random selection of both outputs and chips for testing, and a finite set of possible outputs, it is possible to calculate what sampling ratio would

Re: Designing and implementing malicious hardware

2008-04-28 Thread Leichter, Jerry
On Mon, 28 Apr 2008, Ed Gerck wrote: | Leichter, Jerry wrote: | I suspect the only heavy-weight defense is the same one we use against | the Trusting Trust hook-in-the-compiler attack: Cross-compile on | as many compilers from as many sources as you can, on the assumption | that not all

Re: Designing and implementing malicious hardware

2008-04-28 Thread Ed Gerck
Perry E. Metzger wrote: Ed Gerck [EMAIL PROTECTED] writes: Each chip does not have to be 100% independent, and does not have to be used 100% of the time. Assuming a random selection of both outputs and chips for testing, and a finite set of possible outputs, it is possible to calculate what

Re: Designing and implementing malicious hardware

2008-04-28 Thread Perry E. Metzger
Ed Gerck [EMAIL PROTECTED] writes: Perry E. Metzger wrote: Ed Gerck [EMAIL PROTECTED] writes: Each chip does not have to be 100% independent, and does not have to be used 100% of the time. Assuming a random selection of both outputs and chips for testing, and a finite set of possible

Re: Designing and implementing malicious hardware

2008-04-28 Thread Ed Gerck
Perry E. Metzger wrote: No. It really does not. Shannon's tenth theorem is about correcting lossy channels with statistically random noise. This is about making sure something bad doesn't happen to your computer like having someone transmit blocks of your hard drive out on the network. I assure

Re: Designing and implementing malicious hardware

2008-04-28 Thread Perry E. Metzger
Ed Gerck [EMAIL PROTECTED] writes: Perry E. Metzger wrote: No. It really does not. Shannon's tenth theorem is about correcting lossy channels with statistically random noise. This is about making sure something bad doesn't happen to your computer like having someone transmit blocks of your

Re: Designing and implementing malicious hardware

2008-04-27 Thread Ivan Krstić
On Apr 25, 2008, at 11:09 AM, Leichter, Jerry wrote: I remember seeing another, similar contest in which the goal was to produce a vote-counting program that looked completely correct, but biased the results. The winner was amazingly good - I

Re: Designing and implementing malicious hardware

2008-04-26 Thread Leichter, Jerry
On Thu, 24 Apr 2008, Jacob Appelbaum wrote: | Perry E. Metzger wrote: | A pretty scary paper from the Usenix LEET conference: | | http://www.usenix.org/event/leet08/tech/full_papers/king/king_html/ | | The paper describes how, by adding a very small number of gates to a | microprocessor

RE: Designing and implementing malicious hardware

2008-04-26 Thread Crawford Nathan-HMGT87
I suppose Ken Thompson's, Reflections on Trusting Trust is appropriate here. This kind of vulnerability has been known about for quite some time, but did not have much relevance until the advent of ubiquitous networking. - The

Re: Designing and implementing malicious hardware

2008-04-26 Thread Karsten Nohl
Jacob Appelbaum wrote: Perry E. Metzger wrote: A pretty scary paper from the Usenix LEET conference: http://www.usenix.org/event/leet08/tech/full_papers/king/king_html/ The paper describes how, by adding a very small number of gates to a microprocessor design (small enough that it would be

Re: Designing and implementing malicious hardware

2008-04-26 Thread Anne Lynn Wheeler
Leichter, Jerry wrote: While analysis of the actual silicon will clearly have to be part of any solution, it's going to be much harder than that: 1. Critical circuitry will likely be tamper-resistant. Tamper-resistance techniques make it hard to see what's

Re: Designing and implementing malicious hardware

2008-04-26 Thread Adam Fields
On Sat, Apr 26, 2008 at 02:33:11AM -0400, Karsten Nohl wrote: [...] Assuming that hardware backdoors can be build, the interesting question becomes how to defeat against them. Even after a particular triggering string is identified, it is not clear whether software can be used to detect

Designing and implementing malicious hardware

2008-04-24 Thread Perry E. Metzger
A pretty scary paper from the Usenix LEET conference: http://www.usenix.org/event/leet08/tech/full_papers/king/king_html/ The paper describes how, by adding a very small number of gates to a microprocessor design (small enough that it would be hard to notice them), you can create a machine that

Re: Designing and implementing malicious hardware

2008-04-24 Thread Jacob Appelbaum
Perry E. Metzger wrote: A pretty scary paper from the Usenix LEET conference: http://www.usenix.org/event/leet08/tech/full_papers/king/king_html/ The paper describes how, by adding a very small number of gates to a microprocessor design (small enough that it would be hard to notice them),