4 ms·

"in theory" Linux, at least, was supposed to use rdrand's output as _one_ source of entropy, not _the only_ source. No idea what Windows et al do for this, or

"in theory" Linux, at least, was supposed to use rdrand's output as _one_ source of entropy, not _the only_ source. No idea what Windows et al do for this, or if that's still true, but I believe the above description was how the argument was originally ended. Also, tbh, if you can patch arbitrary instruction behavior, just replacing rdrand seems like far too ham fisted a tool with the level of versatility in your hands...

Tuna-Fish 2y ago
Linux's rdrand use is proof against it returning bad output, but is not proof against malicious microcode. Reason for this is that the malicious microcode can examine register contents and alter the value it's returning so that mixing it into the previous source of randomness produces the desired evil value.
- rincebrain 2y ago
  Sure, but as stated, if you don't trust the CPU at all, rdrand becomes the least of your concerns.
  - Tuna-Fish 2y ago
    The thing is, all the other ways you can compromise the kernel from microcode are at least theoretically detectable. A security researcher could study how the cpu operates and find the exploit. If RDRAND is surreptitiously replacing all your random numbers with AES of the current time, you cannot find that out from observing behavior. I agree that worrying about RDRAND shouldn't probably be on the top of anyone's priorities, but there is some cause to at least use it defensively, for example using it to pre-fill buffers with random values in a different context, so that subversion would in the very least require memory references, instead of running RDRAND in the context of your RNG.
    - Muromec 2y ago
      > If RDRAND is surreptitiously replacing all your random numbers with AES of the current time, you cannot find that out from observing behavior. Should you not see it from timing alone being wrong?
      - usrusr 2y ago
        Had the same thought. But then on the other hand, when nobody is looking at the timing, nobody will see anything. And those who do see a timing artifact, will they really dig deeper or will they just shrug off another oddity? I would not like to bet on another Clifford Stoll in this day and age.
      - Tuna-Fish 2y ago
        RDRAND is very slow and you can fix up the timing with a slowdown loop in the microcode.
    - wtallis 2y ago
      I think you may be overestimating the scale of attack that can be accomplished within the constraints of a microcode update. Given that the CPU has to still seem to be operating normally while using malicious microcode, how much space out of the few kilobytes of a microcode update file is really available for implementing a subtle attack, complete with monitoring the state of the larger system to detect a trigger condition or locate specific information (such as the timestamp you mention)? Sure, malicious microcode theoretically has access to basically everything, but the severely limited payload makes it a lot harder to pull off complicated attacks.
  - mmh0000 2y ago
    And, you shouldn't trust your CPU! * https://www.eff.org/deeplinks/2017/05/intels-management-engine-security-hazard-and-users-need-way-disable-it https://www.eff.org/deeplinks/2017/05/intels-management-engi... * https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine * https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo... * https://en.wikipedia.org/wiki/ARM_architecture_family#Security_extensions https://en.wikipedia.org/wiki/ARM_architecture_family#Securi...
- jstasiak 2y ago
  An article mentioning this kind of attack: https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html
wahern 2y ago
For organizations like the NSA, a simple hack like this is the opposite of ham-fisted, though presumably they'd try to ensure the output would pass common statistical tests. The utility in quietly breaking cryptographic protocols is presumably a major reason why it was chosen for the proof-of-concept.
- rincebrain 2y ago
  Sure, but that was my point, was that just overriding rdrand would be much more ham-fisted than any practical attack I would expect someone to weaponize this into outside of a PoC.
dooglius 2y ago
Intel's theory I believe was that it could become the only source. The argument in favor I think is the same one you are making now: anything that could hack the chip deeply enough to break rdrand is powerful enough to achieve the same goals in another way.
- rincebrain 2y ago
  I'm sure Intel loved that idea, given that I don't think RDRAND showed up on AMD chips for 3 years after Intel launched support for it, and that would let them look much better on a number of benchmarks for that duration...
  - formerly_proven 2y ago
    I think you misunderstand where in the pipeline RDRAND would sit. It's not a high-performance RNG, that instruction takes hundreds of cycles and generates a couple bytes of data. It's used to derive keys for the actual CSPRNG providing e.g. /dev/urandom (which is basically a stream cipher). Having or not having RDRAND would have no performance impact on the CSPRNG.
    - rincebrain 2y ago
      Sure, but as I recall, in those days, the system would happily block for a bit if you managed to drain the estimated entropy pool low enough by doing something like generating an openssh key on first boot, so having another source that the competition takes 3 years to implement could have provided noticable performance benefits for things people notice, like how slow first boot is, in the days before zx2c4 looked at Linux's /dev/random code and hit it with hammers. (I'm not insisting on that workflow or example being an uptick, just that that's a concrete example of how having an additional source back then could have caused noticable performance differences. I'm aware you're not calling rdrand for your /dev/urandom or random accesses, now or then.)
dist-epoch 2y ago
Windows collects hardware device entropy and mixes it into the pool. It also persists the pool across reboots so it doesn't start empty.

Tuna-Fish 2y ago

Linux's rdrand use is proof against it returning bad output, but is not proof against malicious microcode. Reason for this is that the malicious microcode can examine register contents and alter the value it's returning so that mixing it into the previous source of randomness produces the desired evil value.

rincebrain 2y ago
Sure, but as stated, if you don't trust the CPU at all, rdrand becomes the least of your concerns.
- Tuna-Fish 2y ago
  The thing is, all the other ways you can compromise the kernel from microcode are at least theoretically detectable. A security researcher could study how the cpu operates and find the exploit. If RDRAND is surreptitiously replacing all your random numbers with AES of the current time, you cannot find that out from observing behavior. I agree that worrying about RDRAND shouldn't probably be on the top of anyone's priorities, but there is some cause to at least use it defensively, for example using it to pre-fill buffers with random values in a different context, so that subversion would in the very least require memory references, instead of running RDRAND in the context of your RNG.
  - Muromec 2y ago
    > If RDRAND is surreptitiously replacing all your random numbers with AES of the current time, you cannot find that out from observing behavior. Should you not see it from timing alone being wrong?
    - usrusr 2y ago
      Had the same thought. But then on the other hand, when nobody is looking at the timing, nobody will see anything. And those who do see a timing artifact, will they really dig deeper or will they just shrug off another oddity? I would not like to bet on another Clifford Stoll in this day and age.
    - Tuna-Fish 2y ago
      RDRAND is very slow and you can fix up the timing with a slowdown loop in the microcode.
  - wtallis 2y ago
    I think you may be overestimating the scale of attack that can be accomplished within the constraints of a microcode update. Given that the CPU has to still seem to be operating normally while using malicious microcode, how much space out of the few kilobytes of a microcode update file is really available for implementing a subtle attack, complete with monitoring the state of the larger system to detect a trigger condition or locate specific information (such as the timestamp you mention)? Sure, malicious microcode theoretically has access to basically everything, but the severely limited payload makes it a lot harder to pull off complicated attacks.
- mmh0000 2y ago
  And, you shouldn't trust your CPU! * https://www.eff.org/deeplinks/2017/05/intels-management-engine-security-hazard-and-users-need-way-disable-it https://www.eff.org/deeplinks/2017/05/intels-management-engi... * https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine * https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo... * https://en.wikipedia.org/wiki/ARM_architecture_family#Security_extensions https://en.wikipedia.org/wiki/ARM_architecture_family#Securi...
jstasiak 2y ago
An article mentioning this kind of attack: https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html

wahern 2y ago

For organizations like the NSA, a simple hack like this is the opposite of ham-fisted, though presumably they'd try to ensure the output would pass common statistical tests. The utility in quietly breaking cryptographic protocols is presumably a major reason why it was chosen for the proof-of-concept.

rincebrain 2y ago
Sure, but that was my point, was that just overriding rdrand would be much more ham-fisted than any practical attack I would expect someone to weaponize this into outside of a PoC.

dooglius 2y ago

Intel's theory I believe was that it could become the only source. The argument in favor I think is the same one you are making now: anything that could hack the chip deeply enough to break rdrand is powerful enough to achieve the same goals in another way.

rincebrain 2y ago
I'm sure Intel loved that idea, given that I don't think RDRAND showed up on AMD chips for 3 years after Intel launched support for it, and that would let them look much better on a number of benchmarks for that duration...
- formerly_proven 2y ago
  I think you misunderstand where in the pipeline RDRAND would sit. It's not a high-performance RNG, that instruction takes hundreds of cycles and generates a couple bytes of data. It's used to derive keys for the actual CSPRNG providing e.g. /dev/urandom (which is basically a stream cipher). Having or not having RDRAND would have no performance impact on the CSPRNG.
  - rincebrain 2y ago
    Sure, but as I recall, in those days, the system would happily block for a bit if you managed to drain the estimated entropy pool low enough by doing something like generating an openssh key on first boot, so having another source that the competition takes 3 years to implement could have provided noticable performance benefits for things people notice, like how slow first boot is, in the days before zx2c4 looked at Linux's /dev/random code and hit it with hammers. (I'm not insisting on that workflow or example being an uptick, just that that's a concrete example of how having an additional source back then could have caused noticable performance differences. I'm aware you're not calling rdrand for your /dev/urandom or random accesses, now or then.)

dist-epoch 2y ago

Windows collects hardware device entropy and mixes it into the pool. It also persists the pool across reboots so it doesn't start empty.