lkml.org 
[lkml]   [2017]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v12 3/4] Linux Random Number Generator
    On Tue, Jul 18, 2017 at 09:00:10PM -0400, Sandy Harris wrote:
    > The only really good solution I know of is to find a way to provide a
    > chunk of randomness early in the boot process. John Denker has a good
    > discussion of doing this by modifying the kernel image & Ted talks of
    > doing it via the boot loader. Neither looks remarkably easy. Other
    > approaches like making the kernel read a seed file or passing a
    > parameter on the kernel command line have been suggested but, if I
    > recall right, rejected.

    It's actually not that _hard_ to modify the boot loader. It's not
    finicky work like, say, adding support for metadata checksums or xattr
    deduplication to ext4. It's actually mostly plumbing. It's just that
    we haven't found a lot of people willing to do it as paid work, and
    the hobbyists haven't been interested.

    > As I see it, the questions about Jitter, or any other in-kernel
    > generator based on timing, are whether it is good enough to be useful
    > until we have one of the above solutions or useful as a
    > defense-in-depth trick after we have one. I'd say yes to both.
    >
    > There's been a lot of analysis. Stephan has a detailed rationale & a
    > lot of test data in his papers & the Havege papers also discuss
    > getting entropy from timer operations. I'd say the best paper is
    > McGuire et al:
    > https://static.lwn.net/images/conf/rtlws11/random-hardware.pdf

    So here's the problem that I have with most of these analyses. Most
    of them are done using the x86 as the CPU. This is true of the
    McGuire, Okech, and Schiesser paper you've cited above. But things
    are largely irrelevant on the x86, because we have RDRAND. And while
    I like to mix in environmental noise before generating personal
    long-term public keys. I'm actually mostly OK with relying on RDRAND
    for initializing the seeds for hash table to protect against network
    denial of service attacks. (Which is currently the first user of the
    not-yet-initialized CRNG on my laptop during kernel boot.)

    The real problem is with the non-x86 systems that don't have a
    hardware RNG, and there depending timing events which don't depend on
    external devices is much more dodgy. Remember that on most embedded
    devices there is only a single oscillator driving the entire system.
    It's not like you even have multiple crystal oscillators beating
    against one another.

    So if you are only depending on CPU timing loops, you basically have a
    very complex state machine, driven by a single oscillator, and you're
    trying to kid yourself that you're getting entropy out the other end.
    How is that any different from using AES in counter mode and claiming
    because you don't know the seed, that it's "true randomness"? It
    certainly passes all of the statistical tests!

    Hence, we have to rely on external events outside of the CPU and so we
    need to depend on interrupt timing --- and that's what we do in
    drivers/char/random.c already! You can debate whether we are being
    too conservative with when we judge that we've collective enough
    unpredictability to count it as a "bit" of randomness. So it's
    trivially easy to turn the knob and make sure the CRNG gets
    initialized more quickly using fewer interrupt timings, and boom!
    Problem solved.

    Simply turning the knob to make our entropy estimator more lax makes
    people uncomfortable, and since they don't have access to the internal
    microarchitecture of the CPU, they take comfort in the fact that it's
    really, really complicated, and so something like the Jitter RNG
    *must* be a more secure way to do things. But that's really an illusion.

    If the real unpredictability is really coming from the interrupts
    changing the state of the CPU microarchitecture, the real question is
    how many interrupts do you need before you consider things
    "unpredictable" to an adequate level of security? Arguing that we
    should turn down the "interrupts per bit of entropy" in
    drivers/char/random.c is a much more honest way of having that
    discussion.

    - Ted

    P.S. In the McGuire paper you cited, it assumes that the system is
    fully booted and there are multiple processes running which are
    influencing the kernel scheduler. This makes the paper **not** an
    applicable at all. So if you think that is the most compelling
    analysis, I'm definitely not impressed....

    \
     
     \ /
      Last update: 2017-07-19 03:52    [W:3.757 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site