[cryptography] Kernel space vs userspace RNG

Russell Leidich pkejjy at gmail.com
Fri May 6 13:48:49 EDT 2016

Kevin, first of all, Krisztian says that the kernel has access to more
entropy, while you say that userspace does. In a sense, you're both
correct: For its part, the kernel has access to a wider array of devices,
and it's in a better position to ascertain the extent to which timing
entropy is attributable to physical entropy instead of, say, the
pseudorandomness of memory accesses. On the other hand, in a "real world"
situation, userspace is richer because it's active maybe 2 or 3 orders of
magnitude more often than the kernel, and so can afford to accrue much more
timing entropy, some of which is bound to be physical in origin. One can
imagine an implementation in which the kernel gathers timing entropy, then
provides it to a single userspace context before discarding it, but in any
event, this is not likely to happen anytime soon.

But to answer your question, if we assume that the TRNG resides in the
kernel, I see no way in which an acoustic attack could defeat it, even if
the implementation sourced its randomness exclusively from the microphone,
as too much audio precision would be required to create a predictable byte
stream of any significant length in a realistic server environment with
lots of fan noise and multipath arrival issues. So unless you're trying to
attack a purely audio TRNG in a recording studio -- and probably not even
then -- this route seems hopeless. Alternatively, you could try to attack a
timer-based TRNG by shooting sound at the booting machine in the hopes that
the sound device would send incoming sample packets to main memory on a
predictable schedule, but this, too, seems hopeless because even ensuring
timing correlation between timestamp counters on different cores is a
perpetual annoyance to software developers; hoping to sync the audio and
core clocks is much harder. The very existence of the RDTSCP instruction,
which reads the timestamp on a specified core, is evidence of this

On Fri, May 6, 2016 at 4:12 PM, Kevin <kevinsisco61784 at gmail.com> wrote:

> I may be way off but it seems to me that a colonel level RNG can only pick
> up entropy from boot which means hardware noise.  Isn't that easy to beat
> with an acoustic attack?  Maybe user space is a bit better because you have
> more entropy to be gathered.
> On 5/5/2016 7:58 PM, Russell Leidich wrote:
> 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 <ag4ve.us at gmail.com> wrote:
>> Just reflecting on the Linux RNG thread a bit ago, is there any technical
>> reason to have RNG in kernel space?
> _______________________________________________
> cryptography mailing listcryptography at randombit.nethttp://lists.randombit.net/mailman/listinfo/cryptography
> ------------------------------
> [image: Avast logo]
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20160506/44a67db4/attachment.html>

More information about the cryptography mailing list