[liberationtech] Random number generation being influenced - rumors

[Leif Ryge]

The NYT article doesn't explicitly say they've backdoored hardware RNGs, but
it separately says they've backdoored hardware somehow and and are recovering
keys somehow:

> By this year, the Sigint Enabling Project had found ways inside some of the
> encryption chips that scramble information for businesses and governments,
> either by working with chipmakers to insert back doors or by exploiting
> security flaws, according to the documents.
[...]
> N.S.A. documents show that the agency maintains an internal database of
> encryption keys for specific commercial products, called a Key Provisioning
> Service, which can automatically decode many messages. If the necessary key is
> not in the collection, a request goes to the separate Key Recovery Service,
> which tries to obtain it.
> 
> How keys are acquired is shrouded in secrecy, but independent cryptographers
> say many are probably collected by hacking into companies’ computer servers,
> where they are stored.

Sure, the Key Recovery Service might sometimes involve "hacking into companies’
computer servers". But, if they're in the business of inserting hardware
backdoors, going after RNGs seems like one of the most obvious things to do
because they could use those backdoors passively without risk of being caught.

There is a lengthy ongoing discussion right now between Theodore Ts'o
(maintainer of Linux's /dev/random) and David Johnston (designer of Intel's
RDRAND) about using RDRAND directly vs mixing it into Linux's entropy pool:
https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J

Here are a few highlights:

David Johnston:
> I've examined my own RNG with electron microscopes and picoprobes. So I and a
> number of test engineers know full well that the design hasn't been
> subverted. For security critical systems, having multiple entropy sources is
> a good defense against a single source being subverted. But if an Intel
> processor were to be subverted, there are better things to attack, like the
> microcode or memory protection or caches. 
[...]
> I understand that I'm in the privileged position of being able to understand
> and examine my own design, where most people cannot. What I would like is for
> people to stop presenting the straw-man argument that the government leant on
> someone, so they must have subverted my RNG design. I would like (and we've
> made this argument to the kernel developers) that there should be a policy
> option so people can choose to benefit from the hardware they paid for and
> choose to trust, or can decide to be more conservative and require the kernel
> to mix more sources.

Theodore Ts'o:
> I never said that the NSA had definitely subverted your design.  Just that it
> is prudent and responsible to acknowledge that they might have done so, and
> so we need to make sure the Linux kernel is robust against that kind of
> failure.  And remember, the random driver is generic code.  Even if Intel is
> clean, maybe AMD, TI, or Qualcomm were successfully leaned on by the US
> Government, and their chips are dirty.   We don't know, and we can't know.
> 
> As far as making it be an option to the user, I fail to see the benefit. If
> you can't trust the kernel because the attacker can read arbitrary kernel
> memory, you're doomed anyway.   But unlike the proprietary intel chip, at
> least it's possible to audit the kernel to look for security breaches.
[...]
> If I were the NSA, I'd much rather compromise RDRAND, and then try to
> convince people that it's safer and faster to just use the raw RDRAND when
> creating session keys for IPSEC and GPG and VPN's.  You wouldn't need to get
> compromised code into the target machines, other getting out a meme out to
> developers that using the output of RDRAND directly as a session key was
> somehow "best practice".   Wouldn't that be much easier than introducing a
> vulnerability into the page table handling, especially if the goal is to do
> bulk data collection, dragnet-style?