[148448] in cryptography@c2.net mail archive
Re: [Cryptography] An alternative electro-mechanical entropy source
daemon@ATHENA.MIT.EDU (Arnold Reinhold)
Fri Dec 13 17:07:44 2013
X-Original-To: cryptography@metzdowd.com
From: Arnold Reinhold <agr@me.com>
Date: Fri, 13 Dec 2013 16:26:58 -0500
To: Steve Weis <steveweis@gmail.com>, Phillip Hallam-Baker <hallam@gmail.com>
Cc: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============4162225826290041541==
Content-type: multipart/alternative;
boundary="Apple-Mail=_5F67B2A2-FBFF-4CE2-A11F-2BD2CE1F1550"
--Apple-Mail=_5F67B2A2-FBFF-4CE2-A11F-2BD2CE1F1550
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 13, 2013, at 1:59 PM, Steve Weis <steveweis@gmail.com> wrote:
> On Thu, Dec 12, 2013 at 3:44 AM, Arnold Reinhold <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 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.
The threat I am responding to is devices with no source of randomness =
other than a RNG buried in the CPU, presenting a single point of attack =
that is impossible to detect or prevent. It is an emerging threat as =
hard drives, which served as a dependable source of entropy, are phased =
out in favor of solid state devices, and as the internet is increasingly =
used to control infrastructure with diskless devices.=20
I am suggesting that good engineering practice requires more than one =
source of entropy in any system that generates mission critical keys and =
nonces. The problem is what to use for a second source of entropy that =
is independent of the CPU. Obviously at some point a system user who is =
not a cryptographer is going to have to trust one or more (preferably) =
other actors, the system vendor, consultants, in house experts, =
standards certifications etc. But allowing the security of a system to =
be completely in the hands of a CPU or SoC vendor or the vendor's =
fabricator is foolhardy and should be unacceptable.
So what to use as a second source of entropy in diskless systems? It has =
to be inexpensive if it is to have a chance of being incorporated into =
systems and standards and, I submit, it has to be auditable. That is the =
problem I am addressing with my proposal.=20
> 2. How does a CPU authenticate that it's talking to a real, audited
> RNG device and not a spoofed device?
The CPU only has to authenticate that it is talking to a working =
accelerometer. That can be done in a variety of ways such as looking =
for orientation, measuring ambient vibration, or reporting when someone =
bangs on the box. The CPU reads the accelerometer outputs, applies =
statistical tests as appropriate, and hashes the data to get an RNG =
seed. It would be very difficult for an attacker to anticipate all the =
ways an accelerometer can be tested and somehow put firmware inside to =
anticipate and spoof all attempts at verification.
> 3. I think an accelerometer measuring vibrations could be influenced
> by the CPU fans, which can be influenced by attackers running userland
> processes.
I don't see how vibration from the CPU fans can do anything but improve =
this entropy collection scheme. And manipulating fan speed provides yet =
another way to audit the accelerometer chip. Furthermore, the kind of =
devices I am most worried about, the internet of things, will mostly be =
fan-less.
>=20
> If you try to address these issues, I think you'll end up with
> something that looks like a TPM: a cheap device plugged into a bus
> with a slow RNG, persistent storage, & crypto functionality that is
> supposedly made by a trusted manufacturer.
What I am proposing is the exact opposite of a TPM. TPMs are opaque =
devices. The components I am using are simple, mass produced and widely =
available. Vibration motors are easy to verify. Accelerometer chips can =
be tested in many ways. There is no need for persistent storage, nor =
should any be allowed. Crypto functionality should be provided in the =
CPU, or, if necessary in a separate microprocessor loaded by the CPU =
with open software. =20
Bear wrote:
> It would also be a source of vibration which is deadly over the long=20=
> run to hardware, and annoying as hell to work in the same room with.=20=
> Sorry, but the cost of the components is irrelevant when it annoys =
your=20
> staff and takes a year off the five year lifetime of your $N000
> servers.
I'm not sure you'd be able to hear the vibrator buzz over the noise in a =
typical server room. There are plenty of ways to keep the noise inside =
the rack and the vibrator is only need for a few second when a system is =
initialized and periodically thereafter. Indeed in typical server =
installation an accelerometer may be all that is needed.=20
Phillip Hallam-Baker wrote:
> I think we should go quantum. =85
That would going in a completely wrong direction, IMHO. The problem is =
not a lack of ways to generate entropy, it is the difficulty of =
verifying that cryptographic applications are getting true entropy and =
not subverted bit streams. If you want entropy attributable to laws of =
physics, Johnson noise is more than adequate. Any quantum device will be =
expensive and complex, with plenty of places to hide a backdoor. And =
auditing it require not just cryptographic and electrical engineering =
skills, but a deep understanding of quantum physics. Meanwhile =
thousands of critical systems are being deployed with a single, =
untrustworthy RNG. We need simple, verifiable solutions, not advanced =
research projects.
Arnold Reinhold=
--Apple-Mail=_5F67B2A2-FBFF-4CE2-A11F-2BD2CE1F1550
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On Dec 13, 2013, at 1:59 PM, Steve Weis <<a =
href=3D"mailto:steveweis@gmail.com">steveweis@gmail.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><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>> wrote:<br><blockquote =
type=3D"cite">My problem with the Intel design is that there is no way =
to audit it.<br>...<br>Here is an idea I have been playing with to =
provide a slow but auditable<br>source of entropy.<br>...<br>Both the =
accelerometer chips and the<br>vibration motors are made in huge =
quantities and cost under a dollar in<br>quantity. They can be =
audited separately. The items could be mounted on the<br>mother board, =
daughter board or a USB dongle.<br></blockquote><br>A few =
comments:<br>1. You aren't trusting the CPU to generate random numbers, =
but you're<br>trusting the motherboard and chipset that your proposed =
RNG device is<br>plugged into. You're also ultimately still trusting the =
CPU which is<br>consuming those =
values.<br></blockquote><div><br></div>The threat I am responding to is =
devices with no source of randomness other than a RNG buried in the CPU, =
presenting a single point of attack that is impossible to detect =
or prevent. It is an emerging threat as hard drives, which served as a =
dependable source of entropy, are phased out in favor of solid state =
devices, and as the internet is increasingly used to control =
infrastructure with diskless devices. </div><div><br></div><div>I =
am suggesting that good engineering practice requires more than one =
source of entropy in any system that generates mission critical keys and =
nonces. The problem is what to use for a second source of entropy =
that is independent of the CPU. Obviously at some point a system user =
who is not a cryptographer is going to have to trust one =
or more (preferably) other actors, the system vendor, =
consultants, in house experts, standards certifications etc. But =
allowing the security of a system to be completely in the hands of a CPU =
or SoC vendor or the vendor's fabricator is foolhardy and should be =
unacceptable.</div><div><br></div><div>So what to use as a second source =
of entropy in diskless systems? It has to be inexpensive if it is to =
have a chance of being incorporated into systems and standards and, I =
submit, it has to be auditable. That is the problem I am addressing with =
my proposal. </div><div><br></div><div><br></div><div><blockquote =
type=3D"cite">2. How does a CPU authenticate that it's talking to a =
real, audited<br>RNG device and not a spoofed =
device?<br></blockquote><div><br></div>The CPU only has to authenticate =
that it is talking to a working accelerometer. That can be done in =
a variety of ways such as looking for orientation, measuring ambient =
vibration, or reporting when someone bangs on the box. The CPU =
reads the accelerometer outputs, applies statistical tests as =
appropriate, and hashes the data to get an RNG seed. It would be =
very difficult for an attacker to anticipate all the ways an =
accelerometer can be tested and somehow put firmware inside to =
anticipate and spoof all attempts at =
verification.</div><div><br><blockquote type=3D"cite">3. I think an =
accelerometer measuring vibrations could be influenced<br>by the CPU =
fans, which can be influenced by attackers running =
userland<br>processes.<br></blockquote><div><br></div>I don't see =
how vibration from the CPU fans can do anything but improve this entropy =
collection scheme. And manipulating fan speed provides yet another way =
to audit the accelerometer chip. Furthermore, the kind of devices =
I am most worried about, the internet of things, will mostly be =
fan-less.</div><div><br><blockquote type=3D"cite"><br>If you try to =
address these issues, I think you'll end up with<br>something that looks =
like a TPM: a cheap device plugged into a bus<br>with a slow RNG, =
persistent storage, & crypto functionality that is<br>supposedly =
made by a trusted manufacturer.<br></blockquote></div><br><div>What I am =
proposing is the exact opposite of a TPM. TPMs are opaque =
devices. The components I am using are simple, mass produced and =
widely available. Vibration motors are easy to verify. Accelerometer =
chips can be tested in many ways. There is no need for persistent =
storage, nor should any be allowed. Crypto functionality should be =
provided in the CPU, or, if necessary in a separate microprocessor =
loaded by the CPU with open software. =
</div><div><br></div><div>Bear =
wrote:</div><div><br></div><div><blockquote type=3D"cite">It would also =
be a source of vibration which is deadly over the long <br>run to =
hardware, and annoying as hell to work in the same room =
with. <br>Sorry, but the cost of the components is irrelevant when =
it annoys your <br>staff and takes a year off the five year =
lifetime of your $N000<br>servers.</blockquote><br></div><div>I'm not =
sure you'd be able to hear the vibrator buzz over the noise in a typical =
server room. There are plenty of ways to keep the noise inside the rack =
and the vibrator is only need for a few second when a system is =
initialized and periodically thereafter. Indeed in typical server =
installation an accelerometer may be all that is =
needed. </div><div><br></div><div>Phillip Hallam-Baker =
wrote:</div><div><br></div><div><blockquote type=3D"cite">I think we =
should go quantum. =85</blockquote><br></div><div>That would going in a =
completely wrong direction, IMHO. The problem is not a lack of ways to =
generate entropy, it is the difficulty of verifying that cryptographic =
applications are getting true entropy and not subverted bit streams. If =
you want entropy attributable to laws of physics, Johnson noise is more =
than adequate. Any quantum device will be expensive and complex, with =
plenty of places to hide a backdoor. And auditing it require not =
just cryptographic and electrical engineering skills, but a deep =
understanding of quantum physics. Meanwhile thousands of critical =
systems are being deployed with a single, untrustworthy RNG. We =
need simple, verifiable solutions, not advanced research =
projects.</div><div><br></div><div><br></div><div>Arnold =
Reinhold</div></body></html>=
--Apple-Mail=_5F67B2A2-FBFF-4CE2-A11F-2BD2CE1F1550--
--===============4162225826290041541==
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
--===============4162225826290041541==--
