lkml.org 
[lkml]   [2022]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v43 01/15] Linux Random Number Generator
    On Mon, Jan 10, 2022 at 03:38:08PM +0100, Jason A. Donenfeld wrote:
    >
    > Yea, I'm not really compelled by it as something real that we'd
    > actually want to have for something serious. Keep in mind: this thread
    > isn't really about cryptography, but just about compliance nonsense.
    > BUT, if it turns out that the path to these people getting their green
    > compliance checkbox stamp isn't actually thousands of lines of new
    > code, but rather some glue bridging the /dev/urandom / getrandom(2)
    > API into the blah cryptoapi thing, that's... interesting news to me.
    > I'm not even saying, at this stage anyhow, that I want to do this, but
    > I do find it a very interesting data point.

    The last time I had the displeasure of looking into the FIPS
    certification, which granted, was over a decade ago when I was in
    IBM's Linux Technology Center, what I learned was it all depends on
    the FIPS certification lab. NIST writes the documentation, but what
    really matters is the FIPS certification lab that a hardware or
    software vendor pays $$$$ to in order to get the magic certificate
    which allows you to sell into *some* government contracts. (When I
    had to go through the all of the nonsense to get a TS/SCI clearance to
    support the real-time kernel for all of the IBM servers for the
    DDG/1000 Zumwalt Class destroyer, they didn't care about getting FIPS
    certified. I've also seen tighter security measures for computer
    rooms at NYC financial companies than at a Top Secret machine root at
    said defense contractor. Go figure....)

    The other thing I learned for those customers who *did* care, was that
    the only thing that got certified was a specific binary image. If you
    replace the kernel or OpenSSL library with, say, a bugfixed version
    that fixed an actively exploited zero day, *boom*, that would break
    the certification and the system would no longer be FIPS certified.

    Some FIPS labs would allow you to certify the "cryptographic core" of
    the OpenSSL library, which the OpenSSL library would then dlopen, and
    so as long as the bugfix was in, say, the ASN.1 parser, and you didn't
    need to change the "cryptographic core" it was OK --- and you just
    needed to hope that there weren't any bugs in the cryptographic core,
    since then you wouldn't be allowed to fix it --- since FIPS compliance
    was more important than, say, the *actual* security of the system in
    question.

    So yeah, as I said, it's all about TSA-style security theatre, and
    when I worked for IBM and there was millions of dollars on the line, I
    might have cared. For upstream development, (and blessedly, this is
    not something that my current employer has needed to worry about) I
    care far less about it.

    If we want to add a CONFIG_RANDOM_SECURITY_THEATRE build option which
    diverts getrandom and /dev/urandom to use crypto/drbg, I'm going to
    think it's a waste of time, and there are some things about
    crypto/drbg that I'm not psyched about such as the fact that only
    reseed after 2**20 calls to drbg_generate(), and the drbg statemachine
    will initialize itself from get_random_bytes() in early boot, when the
    CRNG is least likely to be securely initialized. So **I** wouldn't
    want to use it for my own personal security, but if it allows Ubuntu
    to sell into the US govnerment market, my only hope is that this
    wouldn't be inflicted on all of their customers, but only those US
    Government customers who care (and as near as I can tell, this is
    *not* all USG customers).

    > > Specifically, I think that if you change your perspective from, "how can we
    > > change the algorithms of the RNG to be FIPS" to "how can we bend FIPS within
    > > its limits so that having what customers want would minimally impact the
    > > quality of the RNG implementation or introduce undue maintenance burdens."
    >
    > We're now starting to get some idea about how this FIPS stuff bends.

    Well, if we optionally (if jitterentropy_rng is compiled in), we would
    periodically pull from it as one additional entropy source into the
    input_pool, it won't do any harm --- other than the CPU overhead
    consumed by jitterentropy, of course. Maybe that would make some
    people happy, including some FIPS Labs?

    I've also seen some FIPS certifications which didn't care about what
    the kernel did, but only cared about what was in the OpenSSL library.
    (Which is where the story about segregating out the cryptographic core
    so that you could actually patch most zero-days without having to go
    back to the FIPS certification lab, pay $$$, and wait months for the
    updated binary to be certified.)

    So I suspect that there will be a lot of anecdotal evidence, but the
    only thing we can probably say with any amount of certainity is Your
    Mileage May Vary.

    Cheers,

    - Ted

    \
     
     \ /
      Last update: 2022-01-10 18:40    [W:2.529 / U:0.280 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site