|
||
|
14 July 2013. Add coderman and Maxwell messages.] 13 July 2013. Add Nielsen message 3. 13 July 2013 Intel In Bed with NSA From Cryptography mail list: http://lists.randombit.net/mailman/listinfo/cryptography
Date: Fri, 12 Jul 2013 16:20:55 +0200 ----- Forwarded message from Matt Mackall <mpm[at]selenic.com> -----
Date: Thu, 11 Jul 2013 17:34:48 -0500 On Thu, 2013-07-11 at 13:47 -0700, Andy Isaacson wrote: > > Linux now also uses a closed RdRand [2] RNG if available. It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. From a quick skim of current sources, much of that has recently been rolled back (/dev/random, notably) but kernel-internal entropy users like sequence numbers and address-space randomization appear to still be exposed to raw RdRand output. (And in the meantime, my distrust of Intel's crypto has moved from "standard professional paranoia" to "actual legitimate concern".) -- Mathematics is the supreme nostalgia of our time. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys[at]stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________
ICBM: 48.07100, 11.36820
http://ativel.com
http://postbiota.org
cryptography mailing
list [Mail footers omitted hereafter.]
[Donald message 1.] On 2013-07-13 12:20 AM, Eugen Leitl [forwarding Matt Mackall <mpm[at]selenic.com>] wrote: It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. Is there a plausible rationale for bypassing the entropy pool? How unauditable is RdRand? Is RdRand unauditable because it uses magic instructions that do unknowable things? Is it designed to actively resist audit? Has Intel gone out of its way to prevent you from knowing how good their true random generation is?
[Nielsen message 1.] On Fri, Jul 12, 2013 at 2:48 PM, James A. Donald <jamesd[at]echeque.com> wrote: On 2013-07-13 12:20 AM, Eugen Leitl [forwarding Matt Mackall <mpm[at]selenic.com>] wrote: Throughput? Not bypassing means having to wait until enough randomness has been gathered from trusted sources. Or maybe it's just trusting Intel and assuming that RDRAND provides better randomness.
[ianG message 1.] On 12/07/13 21:54 PM, Patrick Mylund Nielsen wrote: On Fri, Jul 12, 2013 at 2:48 PM, James A. Donald <jamesd[at]echeque.com> wrote:On 2013-07-13 12:20 AM, Eugen Leitl [forwarding Matt Mackall <mpm[at]selenic.com>] wrote: Typically, the entropy pool is used to feed a PRNG. Throughput isn't really an issue because modern PRNGs are fast, and there are very few applications that require psuedo-RNs at that sort of speed. Or maybe it's just trusting Intel and assuming that RDRAND provides better randomness. This thread has been seen before. On-chip RNGs are auditable but not verifiable by the general public. So the audit can be done then bypassed. Which in essence means the on-chip RNGs are mostly suitable for mixing into the entropy pool. Not to mention, Intel have been in bed with the NSA for the longest time. Secret areas on the chip, pop instructions, microcode and all that ... A more interesting question is whether the non-USA competitors are also similarly friendly. iang
Date: Fri, 12 Jul 2013 15:38:09 -0500 [Williams: BTW, when responding to a message forwarded, do please fix the quote attribution.] On Fri, Jul 12, 2013 at 2:29 PM, ianG <iang[at]iang.org> wrote: > This thread has been seen before. On-chip RNGs are auditable but not I'd like to understand what attacks NSA and friends could mount, with Intel's witting or unwitting cooperation, particularly what attacks that *wouldn't* put civilian (and military!) infrastructure at risk should details of a backdoor leak to the public, or *worse*, be stolen by an antagonist. I would hope that talented folks at the NSA would be averse to embedding backdoors in hardware (and firmware, and software) that they could lose control of, especially in light of recent developments. I'm *not* saying that my wishing is an argument for trusting Intel's RNG -- I'm sincerely trying to understand what attacks could conceivably be mounted through a suitably modified RDRAND with low systemic risk. For example, there might be a way to close a backdoor in a hurry, should it leak. Understanding the attacks that sigint agencies might mount in this fashion might help us understand the likelihood of their attempting them. I think it's important to highlight the systemic risk caused by embedding backdoors everywhere. See "Security Implications of Applying the Communications Assistance to Law Enforcement Act to Voice over IP", by Bellovin, Blaze, et. al. Systemic failures can be extremely severe. The 2008 financial crisis was a systemic failure, and, sadly, I can imagine far worse systemic failures. Minimizing systemic risk should be a key policy goal in general, but management of systemic risk is inherently not in the interests of any short-term political actors, therefore it's important to ensure institutional inertia for systemic risk minimization. The NSA that once worked to strengthen DES against differential cryptanalysis clearly thought so (or, rather, the people who made that happen did) -- is today's NSA no longer interested in the nation's civilian and military security?! Nico
From: Steve Weis <steveweis[at]gmail.com> I think compromising microcode update signing keys would be the easiest path. Then you don't need backdoors baked in the hardware, don't need Intel's buy-in, and can target specific systems without impacting the public at large. This is a pretty interesting analysis showing that these updates are 2048-bit RSA signed blobs: http://inertiawar.com/microcode/ On Fri, Jul 12, 2013 at 1:38 PM, Nico Williams <nico[at]cryptonector.com> wrote: I'd like to understand what attacks NSA and friends could mount, with
Date: Fri, 12 Jul 2013 17:00:23 -0400 I would hope that talented folks at the NSA would be averse to embedding backdoors in hardware (and firmware, and software) that they could lose control of, especially in light of recent developments. Unfortunately it appears that for security reasons at least some chips are being backdoored. For instance see "Breakthrough silicon scanning discovers backdoor in military chip". The chip designers have admitted in that case that the backdoor was designed as part of the security scheme. Actel inserted the backdoor, I would assume with NSA permission since backdooring sensitive chips without NSA permission would be extremely risky. The NSA that once worked to strengthen DES against differential cryptanalysis clearly thought so (or, rather, the people who made that happen did) -- is today's NSA no longer interested in the nation's civilian and military security?! But remember that the NSA weakened DES by reducing the key size from 128 bits to 54 bits. It appears that the preferred the ability to break DES to issues of civil security even back then.
[Donald message 2.] On 2013-07-13 4:54 AM, Patrick Mylund Nielsen wrote: On Fri, Jul 12, 2013 at 2:48 PM, James A. Donald <jamesd[at]echeque.com> wrote:On 2013-07-13 12:20 AM, Eugen Leitl wrote [forwarding Matt Mackall <mpm[at]selenic.com>]: Or maybe it's just trusting Intel and assuming that RDRAND provides better randomness. Often, when the computer boots up, it needs to do things that require some true randomness. This is a potential disaster, therefore there should be a non blocking wait for randomness.
[Gutmann message 1.] Nico Williams <nico[at]cryptonector.com> writes: >I'd like to understand what attacks NSA and friends could mount, with Intel's Right. How exactly would you backdoor an RNG so (a) it could be effectively used by the NSA when they needed it (e.g. to recover Tor keys), (b) not affect the security of massive amounts of infrastructure, and (c) be so totally undetectable that there'd be no risk of it causing a s**tstorm that makes the $0.5B FDIV bug seem like small change (not to mention the legal issues, since this one would have been inserted deliberately, so we're probably talking bet-the-company amounts of liability there). >I'm *not* saying that my wishing is an argument for trusting Intel's RNG -- Being careful is one thing, being needlessly paranoid is quite another. There are vast numbers of issues that crypto/security software needs to worry about before getting down to "has Intel backdoored their RNG". Peter.
[Yager message 2.] There are plenty of ways to design an apparently random number generator so that you can predict the output (exactly or approximately) without causing any obvious flaws in the pseudorandom output stream. Even the smallest bias can significantly reduce security. This could be a critical failure, and we have no way to determine whether or not it is happening. As for preventing potential security holes and making the backdoor deniable, that takes a little more thinking. And for legal issues, there are any number of hand-wavy blame-shifting schemes that Intel and whoever would want to backdoor their RNG could use. I contest the idea that we should ignore the fact that Intel's RNG could be backdoored. Just because other problems exist doesn't mean we should ignore this one. I agree that perhaps worrying about this constitutes being "too paranoid", but no cryptographer ever got hurt by being too paranoid, and not trusting your hardware is a great place to start. [Gutmann's message 1 omitted.]
[Nielsen message 2.] On Sat, Jul 13, 2013 at 1:38 AM, William Yager <will.yager[at]gmail.com> wrote: not trusting your hardware is a great place to start. Heh, might as well just give up. http://cm.bell-labs.com/who/ken/trust.html (I know what you meant, just couldn't resist.) [Gutmann's message 1 omitted.]
[Gutmann message 2.] William Yager <will.yager[at]gmail.com> writes: >no cryptographer ever got hurt by being too paranoid, and not trusting your And while you're lying awake at night worrying whether the Men in Black have backdoored the CPU in your laptop, you're missing the fact that the software that's using the random numbers has 36 different buffer overflows, of which 27 are remote-exploitable, and the crypto uses an RSA exponent of 1 and AES-CTR with a fixed IV. Peter.
[Yager message 3.] It's nice that you can be so cavalier about this, but if your system's RNG is fundamentally broken, it doesn't really matter so much whether your other stuff is well-programmed or not. At least if my web browser is remotely exploitable, it doesn't break my disk encryption software, GPG, SSH, every other web browser I'm using, and pretty much every crypto appliance on my machine. I'd rather have a rickety shed built on solid ground than a castle built on quicksand. [Gutmann's message 2 omitted.]
Date: Sat, 13 Jul 2013 16:43:23 +1000 On Sat, Jul 13, 2013 at 4:32 PM, Peter Gutmann [Gutmann's message 2 omitted.] A good point, of course. So what should everyone do? -- Noon Silk
[Donald message 3.] [Messages omitted by Patrick Mylund Nielsen, William Yager, Peter Gutmann, Nico Williams.] Arrange that a certain specific sequence of data operations, which can be triggered by processing an incoming packet, switches the random number generator from true random mode to pseudo random mode based on a key found in that data.
[Gutmann message 3.] Noon Silk <noonslists[at]gmail.com> writes: >A good point, of course. So what should everyone do? Look for things, and fix things, in order of likelihood of occurrence and exploitability. (Strong) Crypto is bypassed, not penetrated, so address that first. Once you've addressed all of those issues, then you can start looking for the tape measure to determine how much tinfoil you'll need for the hat. Peter.
[Gutmann message 4.] William Yager <will.yager[at]gmail.com> writes: >It's nice that you can be so cavalier about this, but if your system's RNG is Well I'm not sure what thread you're coming in from, but the current one was about the issue of unnecessary paranoia about MIB's backdooring CPUs (and their RNGs). Good RNG design is an entirely different issue, see e.g. https://www.usenix.org/legacy/publications/library/proceedings/sec98/gutmann.html. >At least if my web browser is remotely exploitable, it doesn't break my disk If your browser is remotely exploitable then it breaks everything on what used to be your machine. Peter.
[Laurie message 1.] On 13 July 2013 03:20, Peter Gutmann <pgut001[at]cs.auckland.ac.nz> wrote: [Gutmann message 2 omitted.] But what's the argument for _not_ mixing their probably-not-backdoored RNG with other entropy?
[Gutmann message 5.] Ben Laurie <ben[at]links.org> writes: >But what's the argument for _not_ mixing their probably-not-backdoored RNG Oh, no argument from me on that one, mix every entropy source you can get your hands on into your PRNG, including less-than-perfect ones, the more redundancy there is the less the chances of a single point of failure. (Look at the Capstone design to see what the MIB are actually doing, they have a noise-based RNG, and ANSI X9.17 generator, and a straight counter, all fed into a SHA-1 PRNG, for redundancy). And then run every static source code analysis tool you can find on your RNG, and implement dynamic analysis if you can, and perform entropy checks, and run a self-test with known-good test vectors on startup, and ... well, you get the picture. This is just careful engineering. Worrying about what the MIB are up to is paranoia. If you apply your security engineering well, you don't need to worry about paranoia. (Well, up to a certain extent anyway. Checked your keyboard firmware and wiring recently? Was that TSOP always there? It looks newer than the surrounding circuitry). Peter.
[ianG message 2.] On 13/07/13 09:32 AM, Peter Gutmann wrote: [Gutmann message 2 omitted.] ;) has everyone had a read of this: http://www.infoworld.com/d/security/in-his-own-words-confessions-of-cyber-warrior-222266 iang ps, my comments here: http://financialcryptography.com/mt/archives/001439.html
[Laurie message 2.] On 13 July 2013 10:11, Peter Gutmann <pgut001[at]cs.auckland.ac.nz> wrote: > and run a self-test with known-good test vectors on startup, and ... well, you get the Amusing story: FIPS 140 requires self-tests on the PRNG. There was a bug in FIPS OpenSSL once where the self-test mode got stuck on and so no entropy was fed into the PRNG. Also, back when I was doing FIPS 140 they made me remove some of the entropy feeds into the PRNG - particularly ones that protect against pool duplication over forks.
[ianG messge 3.] On 13/07/13 09:43 AM, Noon Silk wrote: > So what should everyone do? Risk analysis. Which starts with your business model. What you do is go talk to your customers and figure out what happens to them. Formally, you would figure out the frequency of these events, and multiply them by the damages. Order them that way. Concentrate on the top one first, munch your way down the list. If you do this, in ordinary business, you will find that the NSA isn't even on the list, unless for some reason you targetted some space that they also targetted [0]. <advert> E.g, in my current business I'm dealing with savings for v. poor women in Africa. The threats that are hitting them are shakedowns by police, government, scammers, banks, merchants, each other, family, and self, not necessarily in the order we westerners expect. Sometimes with violence. So those are the things I'm building the system to protect against, which of course takes some cryptography to preserve and lock down assets rather than hide them, mixed with a lot of other things... your classic old 1990s CIA models aren't going to help a lot here. </> iang [0] jihadist websites, CAs and chat systems for Americans spring to mind.
Date: Sat, 13 Jul 2013 17:17:57 -0400 On Fri, Jul 12, 2013 at 3:29 PM, ianG <iang[at]iang.org> wrote: On 12/07/13 21:54 PM, Patrick Mylund Nielsen wrote:On Fri, Jul 12, 2013 at 2:48 PM, James A. Donald <jamesd[at]echeque.com wrote:On 2013-07-13 12:20 AM, Eugen Leitl wrote: It seems that this indeed was the reason. In the original thread, Linus made the comment: "The fact is, even if you worry about some back door for the NSA, or some theoretical lack of perfect 32-bit randomness, we can pretty much depend on it. We still do our own hashing on top of whatever entropy we get out of rdrand, and we would still have all our other stuff. Plus the instruction is public and testable - if Intel did something wrong, they'll be *very* embarrassed. It still makes sense if you need so much random data that /dev/random doesn't have sufficient entropy in time to re-seed the PRNG.
Date: Sat, 13 Jul 2013 18:39:24 -0700 On Sat, Jul 13, 2013 at 2:17 PM, Patrick Mylund Nielsen <cryptography[at]patrickmylund.com> wrote: > ... 1. this is a weak argument; the kernel entropy pool is the proper place to _securely_ mix entropy into the available host pool. while sufficient for hash tables or stochastic shaping, it is insufficient for cryptographically strong entropy. 2. the RDRAND instruction is designed and implemented in such a way that you are unable to verify any noise source bias or working condition yourself - instead intentionally stone walled off from purview with the sole reviewer a third party company issued a non-production, test piece of hardware. there is a tedious thread in cryptography at random bit for the masochists among us which discuses all of these considerations and more! in short: this design does not inspire confidence. worth mixing into host entropy pool? sure. using directly or as the sole source of entropy in a system? not advisable. > ... and allow us to you can do this with a proper user space entropy daemon that validates and enforces the correct behavior (or at least not permitting clearly broken behavior) from physical entropy sources available on a system. again, these work best with access to the raw physical bit stream sampled from the entropy sources. the output of AES/$digest post-TRNG processing is of little use for statistical or correctness checks. yet this is all RDRAND provides...
From: Peter Maxwell
<peter[at]allicient.co.uk> On 13 July 2013 07:32, Peter Gutmann <pgut001[at]cs.auckland.ac.nz> wrote: William Yager <will.yager[at]gmail.com> writes: Hmmm. The problem with flawed sources of randomness is their effects can be somewhat more pervasive than a single vulnerable host or vulnerable piece of software. Remember when Debian's OpenSSL implementation had been accidentally mangled causing the PRNG to produce predictable output (circa 2008, irrc)? Twas a bit of a pain in the bahookie for security administrators at the time. It's a basic tenant of computing: crap in => crap out. If a RnRand is in any way flawed then we can presume a state-level actor would be able to find that flaw, which would render vulnerable anything that relies on RnRand as its sole source of entropy ... no matter how fancy the PRNG algorithm it seeds. Granted there are two assumptions there - that RnRand is the only source of entropy and that it is indeed flawed - but given how easy it is to mix entropy sources, the decision not to seems rather, well, silly... especially when one considers a context other than a home laptop such as, say, a certificate authority or generating keys in a defence/military application.
Subsequent messages, if any: http://lists.randombit.net/mailman/listinfo/cryptography
|