[cryptography] Kernel space vs userspace RNG

Kevin kevinsisco61784 at gmail.com
Fri May 6 12:12:47 EDT 2016

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 
> <mailto: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 list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography

This email has been checked for viruses by Avast antivirus software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20160506/b37a2cdb/attachment-0001.html>

More information about the cryptography mailing list