Tamperproof devices and backdoors

[David Honig]

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 at wasabisystems.com