4 ms·

On one hand, this is very cool. On the other hand, why can't Intel/AMD just put this sort of thing on their CPU dyes and be done with it?

daniel-cussen 11y ago
I know Intel has, it's called RDRAND.
JoachimS 11y ago
Intel includes a TRNG in their CPUs (on die) since Ivy Bridge. It used to be called Bull Mountain. Now it is known as RdRand after the instruction. Here is a good article about it: http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator http://spectrum.ieee.org/computing/hardware/behind-intels-ne... The problem is that it is a black box. Intel has added the ability to seed the generator (rdseed), but it does not really reduce the issue of trust.
- jacquesm 11y ago
  If you can seed it then it is not a true random number generator but a pseudo random number generator. Also the rdseed instruction does not allow you to seed the generator but instead allows you to generate seeds for other (pseudo random) generators.
  - mcpherrinm 11y ago
    That's true. There is both a CSPRNG and a TRNG: https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed https://software.intel.com/en-us/blogs/2012/11/17/the-differ...
- stephencanon 11y ago
  RDSEED does not let you seed the RDRAND generator. It provides random data intended for seeding a software PRNG. https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed https://software.intel.com/en-us/blogs/2012/11/17/the-differ...
- caf 11y ago
  RDSEED is not for seeding the generator, it also reads a random number. The difference is that RDSEED reads directly from the hardware random bit generator whereas RDRAND reads from a CSPRNG itself seeded by that random source.
  - paulmd 11y ago
    Quick summary of dopant-mask trojans: small alterations to the chip's masks can "pin" bits of the internal PRNG state high or low. Because the output of the PRNG go through a cryptographically secure hashing algorithm the output appears to have good entropy but assuming you know which bits are pinned the actual keyspace you need to search is catastrophically smaller. Intel includes checksums that run at system startup to verify the functionality of the PRNG but these are aimed at catching manufacturing errors, so they used CRC32. Thus, all you need to do to break this is be sure that the internal state of your pinned PRNG and the fair PRNG produce a CRC32 collision after running the test pattern. http://sharps.org/wp-content/uploads/BECKER-CHES.pdf http://sharps.org/wp-content/uploads/BECKER-CHES.pdf If RDSEED doesn't run through the hash, would that give you enough of a window into the PRNG's internal state to be able to catch that attack? It sounds promising but it looks like RDSEED came out in 2012, so that would predate the paper...
- userbinator 11y ago
  The problem is that it is a black box. So is this one... it's also closed-source hardware.
deleted 11y ago
[deleted]
DanBC 11y ago
They have. https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide https://software.intel.com/en-us/articles/intel-digital-rand... Some people were against it; others not so much. http://en.wikipedia.org/wiki/RdRand http://en.wikipedia.org/wiki/RdRand http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ http://arstechnica.com/security/2013/12/we-cannot-trust-inte...
- throwaway7767 11y ago
  I don't think anyone was really against intel bundling an RNG on-chip. The issue was that they really wanted the OSs to use the entropy gained there directly, rather than just using it as one more source of entropy mixed into the pool. By doing that, all the security of the system is dependent on Intel's RNG. There's not really any downside to mixing this in with other sources of entropy, even if RDRAND were backdoored, rdrand XOR other_entropy should be equally secure as other_entropy.
  - qrmn 11y ago
    It may surprise you that the order matters - in the hands of a potential attacker, combining random sources is not commutative! If your last random source comes from an attacker who can read your state, then they can manipulate your state freely (XOR) or partially (any PRF), which could lead to trouble. Source: http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html Combining with a proper PRF limits the damage a bit compared to plain XOR, which is why Linux's /dev/random was changed to feed in RDSEED/RDRAND like any other entropy source. On the other hand, there's the school of thought which says: if the CPU you're running on has been trojaned in hardware, you're probably buggered no matter what!
spydum 11y ago
it's not something that is easy to generate mathematically, so it's an illogical thing to solve for on a cpu, which wants to follow instructions. randomness shouldnt have a "rule" to follow, that ends up being pseudorandom. See here for a simpler explanation of building a random sequence generator using avalanche effect (sort of the precursor to this device I'd guess): http://holdenc.altervista.org/avalanche/ http://holdenc.altervista.org/avalanche/
pjc50 11y ago
a) Chip designers prefer to keep analog and digital very separate. Analog takes up comparatively much more space. Putting it on the same die may make side-channel attacks easier. b) How do you verify that it's really random and not a CSPRNG with a key known to the NSA?

daniel-cussen 11y ago

I know Intel has, it's called RDRAND.

JoachimS 11y ago

Intel includes a TRNG in their CPUs (on die) since Ivy Bridge. It used to be called Bull Mountain. Now it is known as RdRand after the instruction. Here is a good article about it: http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator http://spectrum.ieee.org/computing/hardware/behind-intels-ne... The problem is that it is a black box. Intel has added the ability to seed the generator (rdseed), but it does not really reduce the issue of trust.

jacquesm 11y ago
If you can seed it then it is not a true random number generator but a pseudo random number generator. Also the rdseed instruction does not allow you to seed the generator but instead allows you to generate seeds for other (pseudo random) generators.
- mcpherrinm 11y ago
  That's true. There is both a CSPRNG and a TRNG: https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed https://software.intel.com/en-us/blogs/2012/11/17/the-differ...
stephencanon 11y ago
RDSEED does not let you seed the RDRAND generator. It provides random data intended for seeding a software PRNG. https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed https://software.intel.com/en-us/blogs/2012/11/17/the-differ...
caf 11y ago
RDSEED is not for seeding the generator, it also reads a random number. The difference is that RDSEED reads directly from the hardware random bit generator whereas RDRAND reads from a CSPRNG itself seeded by that random source.
- paulmd 11y ago
  Quick summary of dopant-mask trojans: small alterations to the chip's masks can "pin" bits of the internal PRNG state high or low. Because the output of the PRNG go through a cryptographically secure hashing algorithm the output appears to have good entropy but assuming you know which bits are pinned the actual keyspace you need to search is catastrophically smaller. Intel includes checksums that run at system startup to verify the functionality of the PRNG but these are aimed at catching manufacturing errors, so they used CRC32. Thus, all you need to do to break this is be sure that the internal state of your pinned PRNG and the fair PRNG produce a CRC32 collision after running the test pattern. http://sharps.org/wp-content/uploads/BECKER-CHES.pdf http://sharps.org/wp-content/uploads/BECKER-CHES.pdf If RDSEED doesn't run through the hash, would that give you enough of a window into the PRNG's internal state to be able to catch that attack? It sounds promising but it looks like RDSEED came out in 2012, so that would predate the paper...
userbinator 11y ago
The problem is that it is a black box. So is this one... it's also closed-source hardware.

deleted 11y ago

[deleted]

DanBC 11y ago

They have. https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide https://software.intel.com/en-us/articles/intel-digital-rand... Some people were against it; others not so much. http://en.wikipedia.org/wiki/RdRand http://en.wikipedia.org/wiki/RdRand http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ http://arstechnica.com/security/2013/12/we-cannot-trust-inte...

throwaway7767 11y ago
I don't think anyone was really against intel bundling an RNG on-chip. The issue was that they really wanted the OSs to use the entropy gained there directly, rather than just using it as one more source of entropy mixed into the pool. By doing that, all the security of the system is dependent on Intel's RNG. There's not really any downside to mixing this in with other sources of entropy, even if RDRAND were backdoored, rdrand XOR other_entropy should be equally secure as other_entropy.
- qrmn 11y ago
  It may surprise you that the order matters - in the hands of a potential attacker, combining random sources is not commutative! If your last random source comes from an attacker who can read your state, then they can manipulate your state freely (XOR) or partially (any PRF), which could lead to trouble. Source: http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html Combining with a proper PRF limits the damage a bit compared to plain XOR, which is why Linux's /dev/random was changed to feed in RDSEED/RDRAND like any other entropy source. On the other hand, there's the school of thought which says: if the CPU you're running on has been trojaned in hardware, you're probably buggered no matter what!

spydum 11y ago

it's not something that is easy to generate mathematically, so it's an illogical thing to solve for on a cpu, which wants to follow instructions. randomness shouldnt have a "rule" to follow, that ends up being pseudorandom. See here for a simpler explanation of building a random sequence generator using avalanche effect (sort of the precursor to this device I'd guess): http://holdenc.altervista.org/avalanche/ http://holdenc.altervista.org/avalanche/

pjc50 11y ago

a) Chip designers prefer to keep analog and digital very separate. Analog takes up comparatively much more space. Putting it on the same die may make side-channel attacks easier. b) How do you verify that it's really random and not a CSPRNG with a key known to the NSA?