7 ms·

The processor could recognize that it is in common key generation code, and generate 'entropy' that precisely reverses most of the existing entropy. The existin

by gefh 13y ago

The processor could recognize that it is in common key generation code, and generate 'entropy' that precisely reverses most of the existing entropy. The existing 'good' entropy could be known by the hardware PRNG.

ars_technician 13y ago
>The processor could recognize that it is in common key generation code This is very unrealistic. It would mean that processors have to be shipped with every crypto library implementation baked into the hardware. Any update would immediately break it.
tedunangst 13y ago
The processor can also just write whatever it wants into the memory containing the entropy pool even if you never call the RDRAND instruction.
- dpe82 13y ago
  Sure, but that's detectable. gefh's attack is not.
  - tedunangst 13y ago
    How so? Has anyone ever pulled the RAM sticks out of their computer to check that the entropy pool looks like they expect it to? Did they then verify that the L3 cache on the CPU had the same contents? Or did they simply ask the suspected backdoor CPU if the very memory it was just suspected of tampering with was clean? If you're going to open Pandora's box, I don't think you get to pick and choose what hypothetical backdoors to take out. It's particularly odd to only select the subset of backdoors that you can easily defend against.
    - htns 13y ago
      Except that if the CPU completely masked its changes it would be no threat. The trick is getting the system to use the bad randomness. I find it unlikely none of the people debugging or running slightly different kernels or drivers or rootkits would not notice something. To exploit RDRAND you would not have to worry about what all the code in the system is doing (highly volatile over different configurations and versions) but you would just need to monitor a few select kernel symbols.
- dragontamer 13y ago
  Checkmate. Good call on this. If you can't trust the CPU you're running on, you can't trust anything at all. The proper solution is to find a supplier you trust and go with them. Pulling useful entropy away from the OS's RNG functions is the best example of an ignorant knee-jerk reaction to this security problem.
  - ars_technician 13y ago
    It's not checkmate. It's a completely unreasonable threat model. How would the processor know where the entropy pool used by the operating system is? How would the processor even know it's performing crypto operations that it should swap numbers for?
    - tedunangst 13y ago
      Presumably using the same skynet tech it uses to look ahead and see where the rdrand is going to be xored into. I'm less familiar with precisely how linux does it, but it's not as simple as "newsecret = oldsecret ^ rdrand". The bits are scattered all to hell. Building a "where will this rdrand go?" backdoor is harder than building a backdoor that just trawls through load addresses for various common kernels looking for the symbol table so it can poison the entropy directly.
      - ars_technician 13y ago
        Do you realize how much of a performance hit modern desktops would take if a processor that had to freeze the operating system while it wandered through memory first identifying the operating system and then finding the entropy pool and modifying it? >Presumably using the same skynet tech it uses to look ahead and see where the rdrand is going to be xored into. There is no such tech. That's why this is not 'checkmate'. A poisoned random number that generates numbers in a predictable manner is orders of magnitude easier to implement and less possible to detect than a magical processor that changes memory it thinks might be entropy for some operating systems it has been pre-programmed to look for under the assumption that kernel will never change ever. Get real.
ars_technician 13y ago
>The existing 'good' entropy could be known by the hardware PRNG. That's a different threat model that doesn't exist here. These devices don't have free access to wander around main memory.

by gefh 13y ago

ars_technician 13y ago

>The processor could recognize that it is in common key generation code This is very unrealistic. It would mean that processors have to be shipped with every crypto library implementation baked into the hardware. Any update would immediately break it.

tedunangst 13y ago

The processor can also just write whatever it wants into the memory containing the entropy pool even if you never call the RDRAND instruction.

dpe82 13y ago
Sure, but that's detectable. gefh's attack is not.
- tedunangst 13y ago
  How so? Has anyone ever pulled the RAM sticks out of their computer to check that the entropy pool looks like they expect it to? Did they then verify that the L3 cache on the CPU had the same contents? Or did they simply ask the suspected backdoor CPU if the very memory it was just suspected of tampering with was clean? If you're going to open Pandora's box, I don't think you get to pick and choose what hypothetical backdoors to take out. It's particularly odd to only select the subset of backdoors that you can easily defend against.
  - htns 13y ago
    Except that if the CPU completely masked its changes it would be no threat. The trick is getting the system to use the bad randomness. I find it unlikely none of the people debugging or running slightly different kernels or drivers or rootkits would not notice something. To exploit RDRAND you would not have to worry about what all the code in the system is doing (highly volatile over different configurations and versions) but you would just need to monitor a few select kernel symbols.
dragontamer 13y ago
Checkmate. Good call on this. If you can't trust the CPU you're running on, you can't trust anything at all. The proper solution is to find a supplier you trust and go with them. Pulling useful entropy away from the OS's RNG functions is the best example of an ignorant knee-jerk reaction to this security problem.
- ars_technician 13y ago
  It's not checkmate. It's a completely unreasonable threat model. How would the processor know where the entropy pool used by the operating system is? How would the processor even know it's performing crypto operations that it should swap numbers for?
  - tedunangst 13y ago
    Presumably using the same skynet tech it uses to look ahead and see where the rdrand is going to be xored into. I'm less familiar with precisely how linux does it, but it's not as simple as "newsecret = oldsecret ^ rdrand". The bits are scattered all to hell. Building a "where will this rdrand go?" backdoor is harder than building a backdoor that just trawls through load addresses for various common kernels looking for the symbol table so it can poison the entropy directly.
    - ars_technician 13y ago
      Do you realize how much of a performance hit modern desktops would take if a processor that had to freeze the operating system while it wandered through memory first identifying the operating system and then finding the entropy pool and modifying it? >Presumably using the same skynet tech it uses to look ahead and see where the rdrand is going to be xored into. There is no such tech. That's why this is not 'checkmate'. A poisoned random number that generates numbers in a predictable manner is orders of magnitude easier to implement and less possible to detect than a magical processor that changes memory it thinks might be entropy for some operating systems it has been pre-programmed to look for under the assumption that kernel will never change ever. Get real.

ars_technician 13y ago

>The existing 'good' entropy could be known by the hardware PRNG. That's a different threat model that doesn't exist here. These devices don't have free access to wander around main memory.