chip verification ( Was: Tollhouse Cookies :-)
"The crucial chips could be built under "open inspection" conditions, much like having source code for inspection prior to compilation on one's own--presumably trustworthy--machines. Several such vendors could be used, with independent auditors observing the processing steps throughout. (Merely the threat of a surprise inspection is probably enough to head off obvious attempts to insert hardware trapdoors and the like.) This seems like a solvable problem." It seems to me that an ostensibly digital device with a fixed number of pins could be regarded as a finite state system, and systematically analyzed accordingly, IE, traverse the set of possible combinations of pins and signal levels and verify that it behaves in accord with pub- -lically available specifications. I'm no circuit designer ( yet ), but it seems to me that the microchip might be subject to design to make it conform to such tests, yet still contain additional circuitry which is undocumented. It might also have analog circuitry, I suppose, although I cannot immediately conceive of a use for such a thing. ( Of course, nanotech rears its ugly head, but that sword cuts both ways and, until it manifests, is irrelevant. ) Perhaps a chip could be tested, at the cost of additional time, by a systematic profiling of the finite boundaries of the device as repre- -sented by the combination of pins being stimulated, the combination of pin input voltage levels, and the resulting pin output voltages. If you want to be fanatical, you can also profile the resulting fields. It seems to me that it would be difficult to defy such a systematic profiling. ( I guess one could also test the I:E:R ratios at each of the states to further detect bogus circuitry, as well as borderline products. ) Why quality assurance lines don't do this on a chip-by-chip level now is beyond me. I'll bet the Japanese do now, or are working on it ... -- richard ===== -- richard childers rchilder@us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within.
It seems to me that an ostensibly digital device with a fixed number of pins could be regarded as a finite state system, and systematically analyzed accordingly, IE, traverse the set of possible combinations of pins and signal levels and verify that it behaves in accord with pub- -lically available specifications.
This is not useful, because devices can have internal state. For example, a device could do the same thing in response to an input for 1000 times, and then do something different when a counter reaches 1001. I've been employed writing test vectors for chips. It *is* possible to write a set of tests that will verify that a piece of hardware matches its design (which, BTW, is software, stored on a disk in a database). Every chip vendor does this on every chip they make, to detect manufacturing defects. These tests will not detect hardware that has been deliberately modified to pass the tests, but to do something different in actual operation. This is an obvious risk when the tests are necessarily publicly available. Of course, if a particular form of modification is suspected, people can write new tests that look for it. But it becomes like the virus protection game: looking for the signatures of known viruses doesn't protect you from unknown ones. There's no proven way to detect all modifications. John Gilmore PS: See also Ken Thompson's paper, "reflections on trusting trust", which was published as an ACM Turing Award lecture among other places. Your CAD software could have been modified so that it inserts a mod into your chip that doesn't appear in the chip's source code. The compiler used to build the CAD software could've been modified to insert the above mod into your CAD software binaries as they are compiled. A compiler binary used to build the *compiler* sources into binaries could have been modified to insert the compiler mod described above. Even if you have full sources, you can't trust the system -- you have to trust the people who bootstrapped it, and all the people who wrote the tools *they* used. "Proving" anything becomes very slippery here.
participants (2)
-
gnu -
Richard Childers