Re: [liberationtech] Random number generation being influenced - rumors
On Sat, Sep 7, 2013 at 6:21 PM, Maxim Kammerer m...@dee.su wrote: Personally, I wouldn't trust an embedded engineer to implement bubble sort correctly, and see no reason to trust them with security-critical implementations, even if one assumes no malice or subversion of production process. By the way, that Android PRNG fiasco? Intel's job, originally. Meet Yuri: https://issues.apache.org/jira/browse/HARMONY-872 -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Random number generation being influenced - rumors
On Sat, Sep 7, 2013 at 10:26 AM, Eugen Leitl eu...@leitl.org wrote: ... There is a hardware RNG in the AMD Geode LX. I tried very hard to find any documentation, but found effectively nothing. Am I that bad at searching, or this really a black box? the only decent on-die RNG i have used was XSTORE[0] from VIA Padlock which allowed you very high speed access to the raw, unwhitened output of the hardware RNG sourece(s). you could read from both at twice the rate for maximum throughput. it was then up to a user-space daemon to read this raw source and perform cursory and long-lived checks, even benchmarks against large volumes of TBytes of output for extended confirmation (looking at you DIEHARDER). the user-space daemon, having then verified the hardware entropy sources, performs computation blinding and compression (e.g. hashing or bocl ciphering) and mixes this obfuscated entropy with the kernel entropy pool via write to /dev/random. RDRAND/RDSEED can not be used a trusted manner with access to the unwhitened, raw output. the AMD768 RNG has not produced a detailed design like XSTORE and cryopgraphy research, nor does it support the raw mode like needed, always reading some 4 bytes: of randomness (IIRC). there are USB and other external sources for entropy if your CPU does not support it, of course. these are useful to augment any userspace entropy daemons like Havegd. 0. Evaluation of C3 Nehemiah Random Number Generator http://www.cryptography.com/public/pdf/VIA_rng.pdf -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Random number generation being influenced - rumors
On Sat, Sep 7, 2013 at 8:24 AM, Andy Isaacson a...@hexapodia.org wrote: That's the claimed design, yes. I see no particular reason to believe that the hardware in my server implements the design. I can't even test that the AES whitening does what it is documented to do, because Intel refused to provide access to the prewhitened input. I agree; I misread the Intel documentation previously, and inferred that CTR_DRBG and other high-level algorithms are implemented in microcode, with ES being accessible to it (and to reverse engineers) directly. Personally, I wouldn't trust an embedded engineer to implement bubble sort correctly, and see no reason to trust them with security-critical implementations, even if one assumes no malice or subversion of production process. In Google+ thread referenced above, David Johnston (Intel engineer in charge of RDRAND) claimed that all the specs are open and accessible; when I mentioned that the AES block size in CTR_DRBG is not even specified, I received no response (of course). Also, proponents of feeding RDRAND directly into /dev/[u]random ignore the AES-reducibility of any cryptosystem that uses RDRAND in that fashion. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Random number generation being influenced - rumors
On Fri, Sep 06, 2013 at 10:45:46AM -0700, Joe Szilagyi wrote: Does anyone put any stock into the rumors floating lately that the government may have influenced Intel and/or AMD into altering in subtle ways that CPUs handle random number generation? I keep seeing this possible FUD floating around in comments here and there on other articles. I agree with some of your premises, but disagree with the conclusion you seem to be drawing. Yes, it's just a fear of uncertainty. We do not have evidence, nor even a claim based on knowledge, that HWRNG backdooring has occurred. However, I claim that the fear is well founded and should be taken into account by all threat models. HWRNG is a nearly-uniquely difficult security problem to crack. By definition it is impossible to prove that a black-box HWRNG is safe. This is different from the security properties of a blackbox AES or MODMUL accelerator, which can be demonstrated to conform to a known specification. If your AES instructions don't do AES, then testing against a software implementation will show it! The AES logic unit will have a hard time leaking the AES keybits since there's nowhere nondeterministic to put them. etc. By contrast, a properly functioning HWRNG cannot be tested in a way that distinguishes it from the output of a stream cipher seeded with a backdoor key. And there's no way to test the behavior of HWRNG on an ongoing basis; even if you had a test to run, it might switch to stream cipher mode under the covers. This is not to say that RdRand is completely unusable. Putting RdRand entropy into a software pool implementation like /dev/urandom (or preferably, a higher-assurance multipool design like Fortuna) is a cheap way to prevent a putative backdoor from compromising your system state. Now, there is a way that we can learn that a backdoor was included; if someone does a tear-down of a HWRNG and finds circuitry that has no purpose other than being a backdoor, that would be conclusive. AFAIK nobody has tried that experiment. Weighing towards distrusting HWRNG we have the fact that NSA is reported (yesterday) to have intentionally backdoored Dual_EC_DRBG, and to have spent significant amounts of money to backdoor chip implementations, with enough success that they brag about it in administrative summaries. So, I put a lot of credence in distrusting HWRNG black box implementations. But unfortunately we need a lot more reliable entropy. A fully open source, nothing up my sleeve hardware entropy source would be a huge improvement. -andy -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Random number generation being influenced - rumors
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? -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
