<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div>On Wed, 20 Nov 2013 00:53:20, Far' wrote:<br><blockquote type="cite">On Tue, Nov 19, 2013 at 10:52 PM, Bear <<a href="mailto:bear@sonic.net">bear@sonic.net</a>> wrote:<br><blockquote type="cite">Honestly, I think the best we can do for secure crypto devices is<br>to develop and publish schematics and parts shopping guides for<br>build-your-own kits. Along with parts testing guides and software<br>so you can be absolutely sure each component of the device is doing<br>exactly what it's supposed to do.<br><br></blockquote>I don't think we're there yet, but eventually we will be.<br><br>Trustable computing is computing that possesses an auditable bootstrap<br>path from trustable sources. That is why efforts like those of Alan<br>Kay, Ian Piumarta, etc., or the DARPA CRASH-SAFE program, matter.<br><br>Of course, in the next step of the trust war, to avoid overly easy<br>pattern recognition and subversion of the initial bootstrap elements,<br>you need not just a fixed schematics, but a random generator of<br>schematics that are equivalent at a high-level, but hard to recognize<br>and latch on at a low-level, thereby making a recognizer hard to hide<br>in the lower-level substrate that you're building upon. Happily, we're<br>not that far along the arms race yet.<br><br></blockquote><br><div>One of my pet ideas is to build an FPGA-based CPU with an S-box in its instruction decoder, so each instance of the CPU would have a different instruction set. Ideally the CPU would have a fixed size op code field in the instruction format, so any instruction could have any op code, and an op code space bigger than the number of operations implemented. The S-box would be populated when each FPGA was loaded and the binary image of its software would be translated for that instance's S-box at the same time. A remote attacker would have no way to create a binary module that the CPU would execute. Of course one would have to make sure the software did not include a high level interpreter that could execute malware. Software upgrades would involve reprogramming the FPGA with a new random S-box, unless records were kept of the fielded S-boxes. If peripheral support circuits were implemented on the FPGA as well, there would be few places for malicious silicon to hide. </div><div><br></div><div>Arnold Reinhold</div><div><br></div><div><br></div></body></html>