[148473] in cryptography@c2.net mail archive
Re: [Cryptography] An alternative electro-mechanical entropy source
daemon@ATHENA.MIT.EDU (Arnold Reinhold)
Mon Dec 16 13:10:36 2013
X-Original-To: cryptography@metzdowd.com
From: Arnold Reinhold <agr@me.com>
Date: Mon, 16 Dec 2013 13:04:21 -0500
To: Bill Cox <waywardgeek@gmail.com>
Cc: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7138217978745601975==
Content-type: multipart/alternative;
boundary="Apple-Mail=_B804E31A-13E3-4F27-B7C8-477A7E14F80A"
--Apple-Mail=_B804E31A-13E3-4F27-B7C8-477A7E14F80A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 14 Dec 2013 08:04 Bill Cox wrote:
> On 12/13/2013 4:26 PM, Arnold Reinhold wrote:
>> On Dec 13, 2013, at 1:59 PM, Steve Weis <steveweis@gmail.com=20
>> <mailto:steveweis@gmail.com>> wrote:
>>=20
>>> On Thu, Dec 12, 2013 at 3:44 AM, Arnold Reinhold <agr@me.com=20
>>> <mailto:agr@me.com>> wrote:
>>>> My problem with the Intel design is that there is no way to audit =
it.
>>>> ...
>>>> Here is an idea I have been playing with to provide a slow but =
auditable
>>>> source of entropy.
>>>> ...
>>>> Both the accelerometer chips and the
>>>> vibration motors are made in huge quantities and cost under a =
dollar in
>>>> quantity. They can be audited separately. The items could be=20
>>>> mounted on the
>>>> mother board, daughter board or a USB dongle.
>>>=20
>>> A few comments:
>>> 1. You aren't trusting the CPU to generate random numbers, but =
you're
>>> trusting the motherboard and chipset that your proposed RNG device =
is
>>> plugged into. You're also ultimately still trusting the CPU which is
>>> consuming those values.
>>=20
>> The threat I am responding to is devices with no source of randomness=20=
>> other than a RNG buried in the CPU, presenting a single point of=20
>> attack that is impossible to detect or prevent. It is an emerging=20
>> threat as hard drives, which served as a dependable source of =
entropy,=20
>> are phased out in favor of solid state devices, and as the internet =
is=20
>> increasingly used to control infrastructure with diskless devices.
>=20
> I like the idea of a completely auditable source of entropy, and the=20=
> accelerometer is clever. However, why not use zener noise like many=20=
> have done before? I've used the reverse breakdown of a base-emitter =
in=20
> a common N2222 NPN transistor with excellent results - commercial =
zeners=20
> are specially designed to be quiet, but no one bothers with a reverse=20=
> Vbe. Just amplify that with discreet transistors, resistors, and=20
> capacitors until it's large enough to digitize through an A/D =
converter,=20
> and feed that into a cheap PLD for whitening. Every part of the flow=20=
> along the way is auditable.
>=20
> I've always wanted to design the entropy source directly into an IC, =
and=20
> I'll still do that with my little project, but this conversation has=20=
> convinced me that what we really need for entropy is low tech discrete=20=
> solutions. Your accelerometer idea is fine, but I'd prefer the bit=20
> rates I can get from zener noise.
I like Zener/avalanche noise as a source and have links to several =
designs on my web page http://www.std.com/~reinhold/truenoise.html. =
Here is another nice wide band design from some RF guys that I recently =
came across.: =
http://code.google.com/p/opendous/wiki/Upconverter_NoiseSource
But I am looking for something more off-the-shelf and as inexpensive as =
possible. Everyone here seems to agree that the right approach is to use =
more than one source of entropy, but this is becoming difficult as =
devices are fielded with only one source, the CPU or SoC. I'm not aware =
of any commercial system that has two purpose-built noise sources now. =
Getting vendors to include a second source will be challenging and every =
penny counts. Ultimately, I'd like to see a requirement for dual =
independent sources incorporated into industry standards like SP-800-90, =
but any such proposal will get a lot of industry pushback if the added =
expense is significant.
So I am trying to come up with several robust solutions, generators that =
could fit on a thumbnail-sized DigiSpark, shield for example. Someone =
else on this thread suggested feeding an analog output into an analog =
input and relying on the low-order-bit measurement noise. I'm not sure =
how much to trust that approach, but it's should easy to try. I'm =
thinking of including a thermistor in the voltage divider to get some =
physical variability that can be tested. =20
But accelerometers seem the best so far. Thy are cheap, widely available =
from several manufacturers and are easy to interface. They could also =
serve a second purpose as an tamper attempt detector. One could even =
afford to include two accelerometers from different manufacturers and =
compare their outputs as a check. =20
Arnold Reinhold
--Apple-Mail=_B804E31A-13E3-4F27-B7C8-477A7E14F80A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">On 14 Dec 2013 08:04 Bill Cox wrote:<div><blockquote =
type=3D"cite">On 12/13/2013 4:26 PM, Arnold Reinhold =
wrote:<br><blockquote type=3D"cite">On Dec 13, 2013, at 1:59 PM, Steve =
Weis <<a =
href=3D"mailto:steveweis@gmail.com">steveweis@gmail.com</a> <br></blo=
ckquote><blockquote type=3D"cite"><<a =
href=3D"mailto:steveweis@gmail.com">mailto:steveweis@gmail.com</a>>>=
wrote:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">On Thu, Dec 12, 2013 at 3:44 AM, Arnold Reinhold <<a =
href=3D"mailto:agr@me.com">agr@me.com</a> <br></blockquote></blockquo=
te><blockquote type=3D"cite"><blockquote type=3D"cite"><<a =
href=3D"mailto:agr@me.com">mailto:agr@me.com</a>>> =
wrote:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">My problem with the Intel design =
is that there is no way to audit =
it.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">...<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Here =
is an idea I have been playing with to provide a slow but =
auditable<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">source =
of entropy.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">...<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Both =
the accelerometer chips and =
the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">vibration motors are made in huge quantities and cost =
under a dollar in<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">quantity. They can be audited separately. The items =
could be <br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">mounted =
on the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">mother =
board, daughter board or a USB =
dongle.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">A few =
comments:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">1. You aren't trusting the CPU =
to generate random numbers, but =
you're<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">trusting the motherboard and chipset that your proposed =
RNG device is<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">plugged into. You're also =
ultimately still trusting the CPU which =
is<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">consuming those =
values.<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">The threat I am =
responding to is devices with no source of =
randomness <br></blockquote><blockquote type=3D"cite">other than a =
RNG buried in the CPU, presenting a single point =
of <br></blockquote><blockquote type=3D"cite">attack that is =
impossible to detect or prevent. It is an =
emerging <br></blockquote><blockquote type=3D"cite">threat as hard =
drives, which served as a dependable source of =
entropy, <br></blockquote><blockquote type=3D"cite">are phased out =
in favor of solid state devices, and as the internet =
is <br></blockquote><blockquote type=3D"cite">increasingly used to =
control infrastructure with diskless devices.<br></blockquote><br>I like =
the idea of a completely auditable source of entropy, and =
the <br>accelerometer is clever. However, why not use zener =
noise like many <br>have done before? I've used the reverse =
breakdown of a base-emitter in <br>a common N2222 NPN transistor =
with excellent results - commercial zeners <br>are specially =
designed to be quiet, but no one bothers with a reverse <br>Vbe. =
Just amplify that with discreet transistors, resistors, =
and <br>capacitors until it's large enough to digitize through an =
A/D converter, <br>and feed that into a cheap PLD for whitening. =
Every part of the flow <br>along the way is =
auditable.<br><br>I've always wanted to design the entropy source =
directly into an IC, and <br>I'll still do that with my little =
project, but this conversation has <br>convinced me that what we =
really need for entropy is low tech discrete <br>solutions. =
Your accelerometer idea is fine, but I'd prefer the =
bit <br>rates I can get from zener =
noise.</blockquote><div><br></div>I like Zener/avalanche noise as a =
source and have links to several designs on my web page <a =
href=3D"http://www.std.com/~reinhold/truenoise.html">http://www.std.com/~r=
einhold/truenoise.html</a>. Here is another nice wide band design =
from some RF guys that I recently came across.: <a =
href=3D"http://code.google.com/p/opendous/wiki/Upconverter_NoiseSource">ht=
tp://code.google.com/p/opendous/wiki/Upconverter_NoiseSource</a></div><div=
><br></div><div>But I am looking for something more off-the-shelf and as =
inexpensive as possible. Everyone here seems to agree that the right =
approach is to use more than one source of entropy, but this is becoming =
difficult as devices are fielded with only one source, the CPU or =
SoC. I'm not aware of any commercial system that has two =
purpose-built noise sources now. Getting vendors to include a =
second source will be challenging and every penny counts. Ultimately, =
I'd like to see a requirement for dual independent sources incorporated =
into industry standards like SP-800-90, but any such proposal will get a =
lot of industry pushback if the added expense is =
significant.</div><div><br></div><div>So I am trying to come up with =
several robust solutions, generators that could fit on a thumbnail-sized =
DigiSpark, shield for example. Someone else on this thread suggested =
feeding an analog output into an analog input and relying on the =
low-order-bit measurement noise. I'm not sure how much to trust =
that approach, but it's should easy to try. I'm thinking of including a =
thermistor in the voltage divider to get some physical variability that =
can be tested. </div><div><br></div><div>But accelerometers seem =
the best so far. Thy are cheap, widely available from several =
manufacturers and are easy to interface. They could also serve a =
second purpose as an tamper attempt detector. One could even afford =
to include two accelerometers from different manufacturers and compare =
their outputs as a check. </div><div><br></div><div>Arnold =
Reinhold</div><div><br></div><div><br></div></body></html>=
--Apple-Mail=_B804E31A-13E3-4F27-B7C8-477A7E14F80A--
--===============7138217978745601975==
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
--===============7138217978745601975==--
