All else being equal, I would prefer to have my TRNG in the
kernel, for the aforementioned reasons of memory access security.
But in the real world, this distinction is minor. More
significantly, kernel TRNGs differ from userspace ones in their
use of hardware sources of randomness, such as network packet
contents and mouse movements. Conventionally, this is considered
to be a good thing because it provides a diversity of entropy
sources which are difficult to model, and must all be modelled in
different ways. By comparison, my own userspace TRNGs (Jytter and
Enranda) rely on only the CPU timer.
I would argue, however, that using hardware randomness is
fundamentally less secure at the only level that actually matters
(overall real world systemic security), even if the ultimate
source of the randomness is perfect in the quantum sense. The
reason has nothing to do with the source itself. Rather, it's the
bus between the CPU and the source which is so horribly
exploitable, to say nothing of the bugs invited by touching so
much hardware. It takes little sophistication or money to insert
a probe between the two, or better yet, to manufacture a
motherboard with such a tap built in. Sure, a CPU manufacturer
could record accesses to the timer which resides on die, but then
they would have the problem of needing to conspire with
motherboard vendors to radiate that data back to the cloud,
perhaps via a network chip which "accidentally" contacts a
particular IP on rare occasion. But less conspiratorially
speaking, a bus tap could be installed in an evil maid attack
using a screwdriver. For that matter, it's not too difficult to
imagine a drone which could fly into a data center and deposit a
high precision electromagnetic sensor on the outside of a server
rack, sensitive to the frequencies used on the frontside bus. At
least in principle, Fourier analysis could be used to reverse
engineer the signals travelling across the bus from the 2D slice
of radiation incident to the receiving surface of the sensor. MRI
machines have been using similar radio wave decoding math for
decades, with obvious success.
However, said evil maid could not read the inputs to a
timer-based TRNG so easily, because doing so would generally
require the root password or an OS vulnerability or a JTAG
connection to the CPU pads, in which case all of encryption is
moot anyway. If said TRNG resided in userspace, then in theory a
security hole in an application could facilitate remote
compromise, but the same could be said of applications which read
/dev/random, then store the results in their userspace memory.
If I were to use any hardware other than the CPU timer, I would
want an encrypted connection between the hardware source and the
CPU core, leaving as little decrypted raw entropy in memory or
higher level caches as possible. For example, CPU debug registers
would be preferable to a line in the level 2 cache. There is also
the question of key exchange spoofing across that leaky bus
hierarchy. And where would we get the entropy to encrypt that
connection? D'oh! Ah, but we could use trusted platform modules!
Uhm, no, because it's much easier to create weak hardware RNGs
which look solid than to engineer the CPU to poison timer-based
TRNGs with predictable timestamps, because those timestamps would
stick out like sore thumbs. And also no because TPMs reside on
the same leaky bus, usually LPC which is indirectly connected to
PCIe, affording two attacks for the price of one. I'm more
sanguine about the sort of TRNG registers that DJ mentioned,
which are readable in userspace but reside on-die, than any
external solutions, although I don't trust them completely
because weakening them in an indetectable manner would require
much less sophisticated engineering than weakening the timestamp;
they might be combined for greater security.
One criticism against timer-based TRNGs is that when booting very
simple devices disconnected from the network, their outputs will
become more predictable. This is probably true, but part of the
validation and testing of the TRNG would be to run it under such
circumstances (probably in relative cryostasis) and appropriately
adjust the lower bound entropy. It's much easier to perform such
characterization for a timer-based TRNG than a "kitchen sink"
TRNG susceptible to the unknown statistical vagaries of a wide
diversity of hardware.
In other words, it's better to have weak entropy that you know to
be weak, and can scale to strength, than strong entropy which is
susceptible to unpredictable massive downspikes in quality,
especially insofar as concerns hardware which was never intended
to behave as a TRNG, e.g. a spinning disc. What is hard for the
attacker to model is also hard for the designer to model.
It's obviously appealing, then, to think of hybridizing timer and
device entropy. All else being equal, this would seem to be the
most secure approach. If we disregard the negative implications
for bandwidth (because when you're monitoring that hardware
output, you're missing out on timer entropy), there is the issue
of ensuring homogenous mixing: we can't substitute audio entropy
for keyboard entropy, etc., because the whole point is that we
don't trust any one source in isolation. So we need to ensure
that each source is mixed into each random output, directly or
indirectly, which then further constrains bandwidth. Otherwise, a
burst of predictable behavior, such as an error storm, might
suddenly arise from one particular device, which was not
contemplated in the model developed by the programmer of the
TRNG. To the extent that such error storms might be induced by
attack, we would have a serious problem. And there's the issue of
expanding the OS security surface by sticking our fingers into so
many driver interfaces. And then there's the risk that hardware
traffic radiating across the bus would also give an attacker a
hint as to when you will read the timer. So then you downthrottle
the entropy value of the timer, yet further constraining bandwidth...
I will be the first to admit that in the present crisis of
entropy starvation, which can only get worse with the rise of
IoT, the most successful approach may well end up being the one
which is sufficiently fast and has passed the test of time,
rather than the one which is theoretically the most secure.
Starfish are evolutionarily successful because they're simple and
highly adaptable, even though they're not very smart.
For those who wish to develop hardware TRNGs, I would recommend
that you at least quantify the randomness of your raw entropy
stream by analyzing it with Dyspoissometer or the like. This
won't prove that it's not all pseudorandom, but it will help to
catch overly optimistic assumptions about said stream, especially
in rare operating modes in which it becomes temporarily much more
predictable.
On Thu, May 5, 2016 at 9:40 AM, shawn wilson <[email protected]
<mailto:[email protected]>> wrote:
Just reflecting on the Linux RNG thread a bit ago, is there
any technical reason to have RNG in kernel space?
_______________________________________________
cryptography mailing list
[email protected] <mailto:[email protected]>
http://lists.randombit.net/mailman/listinfo/cryptography
