[121856] in cryptography@c2.net mail archive
Re: "Designing and implementing malicious hardware"
daemon@ATHENA.MIT.EDU (Ed Gerck)
Mon Apr 28 15:22:21 2008
Date: Mon, 28 Apr 2008 11:04:34 -0700
From: Ed Gerck <edgerck@nma.com>
To: Cryptography <cryptography@metzdowd.com>
In-Reply-To: <Pine.SOL.4.61.0804281001580.12794@mental>
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, you'd end up with a machine no faster than your slowest
> chip, and you'd have to worry about the correctness of the glue
> circuitry that compares the results.
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 provide an adequate confidence level -- a good
guess is 5% sampling.
This should not create a significant impact on average speed, as 95%
of the time the untested samples would not have to wait for
verification (from the slower chips). One could also trust-certify
each chip based on its positive, long term performance -- which could
allow that chip to run with much less sampling, or none at all.
In general, this approach is based on the properties of trust when
viewed in terms of Shannon's IT method, as explained in [*]. Trust is
seen not as a subjective property, but as something that can be
communicated and measured. One of the resulting rules is that trust
cannot be communicated by self-assertions (ie, asking the same chip)
[**]. Trust can be positive (what we call trust), negative (distrust),
and zero (atrust -- there is no trust value associated with the
information, neither trust nor distrust). More in [*].
Cheers,
Ed Gerck
References:
[*] www.nma.com/papers/it-trust-part1.pdf
www.mcwg.org/mcg-mirror/trustdef.htm
[**] Ken's paper title (op. cit.) is, thus, identified to be part of
the very con game described in the paper.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
