[148200] in cryptography@c2.net mail archive
Re: [Cryptography] Moving forward on improving HTTP's security
daemon@ATHENA.MIT.EDU (Arnold Reinhold)
Wed Nov 20 17:31:07 2013
X-Original-To: cryptography@metzdowd.com
From: Arnold Reinhold <agr@me.com>
Date: Wed, 20 Nov 2013 12:39:22 -0500
To: Far? <fahree@gmail.com>
Cc: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7648441727607744791==
Content-type: multipart/alternative;
boundary="Apple-Mail=_A0A90A07-5097-4CCD-85F5-B81C0419034D"
--Apple-Mail=_A0A90A07-5097-4CCD-85F5-B81C0419034D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Wed, 20 Nov 2013 00:53:20, Far' wrote:
> On Tue, Nov 19, 2013 at 10:52 PM, Bear <bear@sonic.net> wrote:
>> Honestly, I think the best we can do for secure crypto devices is
>> to develop and publish schematics and parts shopping guides for
>> build-your-own kits. Along with parts testing guides and software
>> so you can be absolutely sure each component of the device is doing
>> exactly what it's supposed to do.
>>=20
> I don't think we're there yet, but eventually we will be.
>=20
> Trustable computing is computing that possesses an auditable bootstrap
> path from trustable sources. That is why efforts like those of Alan
> Kay, Ian Piumarta, etc., or the DARPA CRASH-SAFE program, matter.
>=20
> Of course, in the next step of the trust war, to avoid overly easy
> pattern recognition and subversion of the initial bootstrap elements,
> you need not just a fixed schematics, but a random generator of
> schematics that are equivalent at a high-level, but hard to recognize
> and latch on at a low-level, thereby making a recognizer hard to hide
> in the lower-level substrate that you're building upon. Happily, we're
> not that far along the arms race yet.
>=20
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.=20
Arnold Reinhold
--Apple-Mail=_A0A90A07-5097-4CCD-85F5-B81C0419034D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"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=3D"cite">On Tue, Nov 19, 2013 at 10:52 PM, =
Bear <<a href=3D"mailto:bear@sonic.net">bear@sonic.net</a>> =
wrote:<br><blockquote type=3D"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>=
--Apple-Mail=_A0A90A07-5097-4CCD-85F5-B81C0419034D--
--===============7648441727607744791==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============7648441727607744791==--
