5 ms·

I am so glad I resisted pressure from engineers working at Intel to let /dev/random in Linux rely blindly on the output of the RDRAND instructure. Relying sole

by tytso 13y ago

I am so glad I resisted pressure from engineers working at Intel to let /dev/random in Linux rely blindly on the output of the RDRAND instructure. Relying solely on an implementation sealed inside a chip and which is impossible to audit is a BAD idea. Quoting from the article... "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..."

magicalist 13y ago
Was that really a seriously considered plan? I don't see how that would ever be a suitable /dev/random replacement. Obviously it works for /dev/urandom, but it should be added to the entropy pool for /dev/random at most.
- lambda 13y ago
  Matt Mackall, the former maintainer of /dev/random, actually stepped down over this issue, because Linus overrode Matt and applied Intel's patch that used their hardware random number generator directly: http://comments.gmane.org/gmane.comp.security.cryptography.randombit/4689 http://comments.gmane.org/gmane.comp.security.cryptography.r... > 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. Ted Ts'o later reverted this, separating out Intel's hardware random number generation into a separate function that could be used to seed the entropy pool but wouldn't be trusted directly as the main kernel source of random numbers: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
  - Zoepfli 13y ago
    Sounds like Linus has some explaining to do...
    - gaius 13y ago
      Indeed. Where's Mr Sweary now, eh?
  - tytso 13y ago
    If Matt protested, he did so quietly/privately. I wasn't aware of the fact that he had stepped down until the authors of the paper described in http://factorable.net http://factorable.net showed up and pointed out we had a really bad problem for embedded devices on the internet. I had always assumed he had gotten too busy and distracted on other interests, since I do follow LKML, and I didn't see any kind of public debate/controversy about the change to the random driver described above. If I had to guess what happened, some intel people pushed this as a feature, probably pushing it via one of the x86 git trees, and Linus either (a) didn't notice, or (b) didn't understand the implications, and then Matt quit in a huff --- by just stopping to do work, and not even updating the entry in the MAINTAINERS file. (That didn't happen until I took over the random driver again.)
    - lambda 13y ago
      You're right, if he did so, it must have been in private; I searched for a while to find a message on a public mailing list about it, and could not, so resorted to linking to that later message. Regardless, I'm glad that paranoia did eventually prevail, despite Linus's original strong objections.
    - lambda 13y ago
      Ah, here's the thread I was looking for: http://thread.gmane.org/gmane.linux.kernel/1173350/focus=1173517 http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... It doesn't really look like he had NAKed it on paranoia grounds, but more on design grounds; others brought up the paranoia arguments. You were even involved in that thread, so you should have seen his stepping down, although he didn't submit a patch to MAINTAINERS.
- tytso 13y ago
  Not only did it happen before, just TODAY I had to fight back an attempt by a Red Hat engineer who wanted to add a configuration option which would once again allow RDRAND to be used directly, bypassing the entropy pool: https://lkml.org/lkml/2013/9/5/212 https://lkml.org/lkml/2013/9/5/212
  - Create 13y ago
    "It's unlikely that Intel (for example) was paid off by the US Government to do this, but it's impossible for them to prove otherwise --- especially since Bull Mountain is documented to use AES as a whitener. Hence, the output of an evil, trojan-horse version of RDRAND is statistically indistinguishable from an RDRAND implemented to the specifications claimed by Intel. Short of using a tunnelling electronic microscope to reverse engineer an Ivy Bridge chip and disassembling and analyzing the CPU microcode, there's no way for us to tell for sure." --- "The NSA's codeword for its decryption program, Bullrun, is taken from a major battle of the American civil war. Its British counterpart, Edgehill" "N.S.A. spends more than $250 million a year on its Sigint Enabling Project, which “actively engages the U.S. and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs” to make them “exploitable.”" -- http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryp... -- Bull Mountain, is Intel's code name for both the RdRand instruction and the underlying random number generator (RNG) hardware implementation. -- bull [mountain|hill] [intel|processor] http://www.googlewhack.com/ http://www.googlewhack.com/ https://xkcd.com/936/ https://xkcd.com/936/ http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-in-that-password/ http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-i...
  - rauar 13y ago
    kudos. did Linus ever comment on the roll-back ?
lambda 13y ago
Thank you for that, and I hope that the people who keep arguing "if you can't trust your hardware, you can't trust anything, so we may as well just blindly trust the hardware" keep this in mind. A bug deliberately introduced in an AES instruction, or in general purpose instructions that detects crypto operations and leaks information somehow, is much, much harder to implement and hide than a pseudo-random number generator that passes all tests that you apply to it, but produces predictable output for someone who knows some secret key.

by tytso 13y ago

magicalist 13y ago

Was that really a seriously considered plan? I don't see how that would ever be a suitable /dev/random replacement. Obviously it works for /dev/urandom, but it should be added to the entropy pool for /dev/random at most.

lambda 13y ago
Matt Mackall, the former maintainer of /dev/random, actually stepped down over this issue, because Linus overrode Matt and applied Intel's patch that used their hardware random number generator directly: http://comments.gmane.org/gmane.comp.security.cryptography.randombit/4689 http://comments.gmane.org/gmane.comp.security.cryptography.r... > 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. Ted Ts'o later reverted this, separating out Intel's hardware random number generation into a separate function that could be used to seed the entropy pool but wouldn't be trusted directly as the main kernel source of random numbers: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
- Zoepfli 13y ago
  Sounds like Linus has some explaining to do...
  - gaius 13y ago
    Indeed. Where's Mr Sweary now, eh?
- tytso 13y ago
  If Matt protested, he did so quietly/privately. I wasn't aware of the fact that he had stepped down until the authors of the paper described in http://factorable.net http://factorable.net showed up and pointed out we had a really bad problem for embedded devices on the internet. I had always assumed he had gotten too busy and distracted on other interests, since I do follow LKML, and I didn't see any kind of public debate/controversy about the change to the random driver described above. If I had to guess what happened, some intel people pushed this as a feature, probably pushing it via one of the x86 git trees, and Linus either (a) didn't notice, or (b) didn't understand the implications, and then Matt quit in a huff --- by just stopping to do work, and not even updating the entry in the MAINTAINERS file. (That didn't happen until I took over the random driver again.)
  - lambda 13y ago
    You're right, if he did so, it must have been in private; I searched for a while to find a message on a public mailing list about it, and could not, so resorted to linking to that later message. Regardless, I'm glad that paranoia did eventually prevail, despite Linus's original strong objections.
  - lambda 13y ago
    Ah, here's the thread I was looking for: http://thread.gmane.org/gmane.linux.kernel/1173350/focus=1173517 http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... It doesn't really look like he had NAKed it on paranoia grounds, but more on design grounds; others brought up the paranoia arguments. You were even involved in that thread, so you should have seen his stepping down, although he didn't submit a patch to MAINTAINERS.
tytso 13y ago
Not only did it happen before, just TODAY I had to fight back an attempt by a Red Hat engineer who wanted to add a configuration option which would once again allow RDRAND to be used directly, bypassing the entropy pool: https://lkml.org/lkml/2013/9/5/212 https://lkml.org/lkml/2013/9/5/212
- Create 13y ago
  "It's unlikely that Intel (for example) was paid off by the US Government to do this, but it's impossible for them to prove otherwise --- especially since Bull Mountain is documented to use AES as a whitener. Hence, the output of an evil, trojan-horse version of RDRAND is statistically indistinguishable from an RDRAND implemented to the specifications claimed by Intel. Short of using a tunnelling electronic microscope to reverse engineer an Ivy Bridge chip and disassembling and analyzing the CPU microcode, there's no way for us to tell for sure." --- "The NSA's codeword for its decryption program, Bullrun, is taken from a major battle of the American civil war. Its British counterpart, Edgehill" "N.S.A. spends more than $250 million a year on its Sigint Enabling Project, which “actively engages the U.S. and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs” to make them “exploitable.”" -- http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryp... -- Bull Mountain, is Intel's code name for both the RdRand instruction and the underlying random number generator (RNG) hardware implementation. -- bull [mountain|hill] [intel|processor] http://www.googlewhack.com/ http://www.googlewhack.com/ https://xkcd.com/936/ https://xkcd.com/936/ http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-in-that-password/ http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-i...
- rauar 13y ago
  kudos. did Linus ever comment on the roll-back ?

lambda 13y ago

Thank you for that, and I hope that the people who keep arguing "if you can't trust your hardware, you can't trust anything, so we may as well just blindly trust the hardware" keep this in mind. A bug deliberately introduced in an AES instruction, or in general purpose instructions that detects crypto operations and leaks information somehow, is much, much harder to implement and hide than a pseudo-random number generator that passes all tests that you apply to it, but produces predictable output for someone who knows some secret key.