lkml.org 
[lkml]   [2018]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux messages full of `random: get_random_u32 called from`
    On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote:
    > On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote:
    > > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE
    >
    > Okay, but /dev/urandom isn't a solution to this problem because it isn't usable
    > until crng init is complete, so it suffers from the same init lag as
    > /dev/random.

    It's more accurate to say that using /dev/urandom is no worse than
    before (from a few years ago). There are, alas, plenty of
    distributions and user space application programmers that basically
    got lazy using /dev/urandom, and assumed that there would be plenty of
    entropy during early system startup.

    When they switched over the getrandom(2), the most egregious examples
    of this caused pain (and they got fixed), but due to a bug in
    drivers/char/random.c, if getrandom(2) was called after the entropy
    pool was "half initialized", it would not block, but proceed.

    Is that exploitable? Well, Jann and I didn't find an _obvious_ way to
    exploit the short coming, which is this wasn't treated like an
    emergency situation ala the embarassing situation we had five years
    ago[1].

    [1] https://factorable.net/paper.html

    However, it was enough to make us be uncomfortable, which is why I
    pushed the changes that I did. At least on the devices we had at
    hand, using the distributions that we typically use, the impact seemed
    minimal. Unfortuantely, there is no way to know for sure without
    rolling out change and seeing who screams. In the ideal world,
    software would not require cryptographic randomness immediately after
    boot, before the user logs in. And ***really***, as in [1], softwaret
    should not be generating long-term public keys that are essential to
    the security of the box a few seconds immediately after the device is
    first unboxed and plugged in.i

    What would be useful is if people gave reports that listed exactly
    what laptop and distributions they are using. Just "a high spec x86
    laptop" isn't terribly useful, because *my* brand-new Dell XPS 13
    running Debian testing is working just fine. The year, model, make,
    and CPU type plus what distribution (and distro version number) you
    are running is useful, so I can assess how wide spread the unhappiness
    is going to be, and what mitigation steps make sense.


    What mitigations steps can be taken?

    If you believe in security-through-complexity (the cache architecture
    of x86 is *sooooo* complicated no one can understand it, so
    Jitterentropy / Haveged *must* be secure), or security-through-secrecy
    (the cache architecture of x86 is only avilable to internal architects
    inside Intel, so Jitterentropy / Haveged *must* be secure, never mind
    that the Intel CPU architects who were asked about it were "nervous"),
    then wiring up CONFIG_JITTERENTROPY or using haveged might be one
    approach.

    If you believe that Intel hasn't backdoored RDRAND, then installing
    rng-tools and running rngd with --enable-drng will enable RDRAND.
    That seems to be popular with various defense contractors, perhaps on
    the assumption that if it _was_ backdoored (no one knows for sure), it
    was probably with the connivance or request of the US government, who
    doesn't need to worry about spying on itself.

    Or you can use some kind of open hardware design RNG, such as
    ChoasKey[2] from Altus Metrum. But that requires using specially
    ordered hardware plugged into a USB slot, and it's probably not a mass
    solution.

    [2] https://altusmetrum.org/ChaosKey/


    Personally, I prefer fixing the software to simply not require
    cryptographic grade entropy before the user has logged in. Because
    it's better than the alternatives.

    - Ted

    \
     
     \ /
      Last update: 2018-04-30 00:05    [W:4.583 / U:0.840 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site