[cryptography] Kernel space vs userspace RNG

Kevin kevinsisco61784 at gmail.com
Fri May 6 15:33:29 EDT 2016


Alright that makes sense.


On 5/6/2016 1:48 PM, Russell Leidich wrote:
> 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 difficulty.
>
>
> On Fri, May 6, 2016 at 4:12 PM, Kevin <kevinsisco61784 at gmail.com 
> <mailto: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
>>     <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 <mailto:cryptography at randombit.net>
>>     http://lists.randombit.net/mailman/listinfo/cryptography
>
>
>
>     ------------------------------------------------------------------------
>     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 <mailto:cryptography at randombit.net>
>     http://lists.randombit.net/mailman/listinfo/cryptography
>
>
>
>
> _______________________________________________
> 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.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20160506/72af0918/attachment-0001.html>


More information about the cryptography mailing list