[Cryptography] An alternative electro-mechanical entropy source (was 'We cannot trust' Intel and Via's chip-based crypto...)

[Arnold Reinhold]

On Dec 13, 2013, at 1:59 PM, Steve Weis <steveweis at gmail.com> wrote:

> On Thu, Dec 12, 2013 at 3:44 AM, Arnold Reinhold <agr at 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.
> 
> 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. 

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. 


> 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.

> 
> 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.   

Bear wrote:

> It would also be a source of vibration which is deadly over the long 
> run to hardware, and annoying as hell to work in the same room with. 
> Sorry, but the cost of the components is irrelevant when it annoys your 
> 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. 

Phillip Hallam-Baker wrote:

> I think we should go quantum. …

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131213/727cf22e/attachment.html>