[8734] in cryptography@c2.net mail archive
Re: Tamperproof devices and backdoors
daemon@ATHENA.MIT.EDU (David Honig)
Fri May 25 15:20:37 2001
Message-Id: <3.0.6.32.20010525100435.007cd790@pop.sprynet.com>
Date: Fri, 25 May 2001 10:04:35 -0700
To: dmolnar <dmolnar@hcs.harvard.edu>,
Enzo Michelangeli <em@em.no-ip.com>
From: David Honig <honig@sprynet.com>
Cc: <cryptography@wasabisystems.com>, <coderpunks@toad.com>
In-Reply-To: <Pine.OSF.4.33.0105250423040.22259-100000@hcs.harvard.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 05:17 AM 5/25/01 -0400, dmolnar wrote:
>We have (at best)
>
> * a device design - specifying a function f() the box is
> "supposed to compute"
> * the tamperproof device - a black box for f()
> which really outputs some function BOX()
> * the ability to query the box and make
> a trace of the box's inputs and outputs
> (x, BOX(x))
>
You hint at this in your discussion, but if you were building a
backdoor into a chip (say a block cipher) you *must* make
the trigger a *sequence* rather than a single input, since
1. testing the specified (one input -> one output) behavior
is what the tester will look for -that's what's specified
2. with a sequence of inputs, the search-space expands to where the tester
has no hope of finding the magic words ---the MTBF of the devices will
happen first.
Any device (CPU, NIC, OS) which sees an externally generated stream is
succeptible. The next Metallica song could contain a trigger that
irreversibly
destroys a certain model MP3 player if its played...
Not even mentioning the in-field-programmable wireless devices
coming to a future near you.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
