4 ms·

The Linux kernel is not using the true RNG circuitry included with all modern microprocessors (this is not entirely correct - see /u/matt_wulfeck's comment). As

by Cyph0n 11y ago

The Linux kernel is not using the true RNG circuitry included with all modern microprocessors (this is not entirely correct - see /u/matt_wulfeck's comment). As far as I know, this is because the kernel devs fear that the RNG circuit can be backdoored, allowing an unwanted entity to control the output of the random bitstream. This is an issue I've been thinking about quite a bit. Is there a way to somehow sign a circuit design on silicon and allow devs to check the circuit's integrity? For example, in the case of a TRNG, the developer can add a "verify" instruction to ensure that the TRNG on the user's CPU is not compromised before executing the RAND instruction. Of course, that's what the dev does, but the signing itself is much more complex. I've been looking through the literature and I haven't found much to go on. I know it's likely impossible to do given how many layers there are between silicon and machine code, but I'd like to at least give it a try.

Nrsolis 11y ago
I'd venture there isn't. The problem of verifying the integrity of embedded silicon (at the microcircuitry level) is one that hasn't really been solved yet. This has been a problem for the DoD since forever. THEY solved it partially by using US-sourced parts and working with industry to make sure the designs weren't sabotaged or otherwise backdoored. It's still an active concern though. http://www.dtic.mil/ndia/2014system/16990WedTrack1Shanahan.pdf http://www.dtic.mil/ndia/2014system/16990WedTrack1Shanahan.p...
- Cyph0n 11y ago
  I've never heard about the DoD initiative. Thanks for the link!
  - Nrsolis 11y ago
    Yeah. This has been something they've been looking into for a while now. Read all of the updates. It's turtles all the way down. https://www.schneier.com/blog/archives/2012/05/backdoor_found.html https://www.schneier.com/blog/archives/2012/05/backdoor_foun...
lvs 11y ago
A malicious module would only need to act like VW's defeat device to overcome that check. When it senses some integrity/signing routine, it simply isolates itself from a verifiable circuit.
- Someone 11y ago
  For VW, that was easy because the test setup was known and very rigid. If you randomly check, say, power usage and latency of the on-board RNG (ideally combined with high-resolution IR recordings of the CPU), it will, at least, be harder for the CPU manufacturer to install a backdoored RNG that is active most of the time (but one that only gets activated after receiving some trigger, say a specific instruction sequence would still be virtually undetectable)
  - Nrsolis 11y ago
    The problem you are trying to solve is much closer to the "decidability problem" than you might suppose at first sight.
- readams 11y ago
  There is no procedure you can run that would show that the RNG was compromised. They would still give you a stream that's indistinguishable from random noise, except it would be generated from a seed known to the attacker.
matt_wulfeck 11y ago
AFAIK the linux kernel does use the RDRAND instruction set from example Intel. However, it uses it as a mix-in source of entropy and is not the sole source of the csprng seed. I personally think this is a good approach, as it allows hardware TRNG to increase the quality and quantity of entropy without being able to own the internal generator.
- ryuuchin 11y ago
  You're correct it does. Specifically I believe it uses rdrand to fill the initial SSH values when get_random is called which then proceeds to mix in stuff from the kernel pool. This avoids the problem with using xor for mixing as has been discussed before (even though that attack vector is unlikely). BoringSSL takes a similar approach with rdrand in that it mixes it using the chacha20 stream cipher. The operating system PRNG is used to generate the keys and rdrand is filtered on every call when you need a random number. I don't know what LibreSSL does (it uses chacha20 in some manner) and I'm pretty sure OpenSSL doesn't use rdrand at all unless you ask for it (in which case it will ONLY use rdrand).
cyphar 11y ago
There's a silicon doping attack for CPUs which makes them impossible to verify with current verification techniques (as far as I understand). The idea is that if you dope the silicon in the circuit you can change the circuit and it's not possible to figure out if it's been changed through forensics (x-rays, etc) or just using it (sufficiently clever backdoor). I'm unsure if FPGAs are vulnerable to this attack (though I've heard they might not be). This is the paper: http://sharps.org/wp-content/uploads/BECKER-CHES.pdf http://sharps.org/wp-content/uploads/BECKER-CHES.pdf

by Cyph0n 11y ago

Nrsolis 11y ago

I'd venture there isn't. The problem of verifying the integrity of embedded silicon (at the microcircuitry level) is one that hasn't really been solved yet. This has been a problem for the DoD since forever. THEY solved it partially by using US-sourced parts and working with industry to make sure the designs weren't sabotaged or otherwise backdoored. It's still an active concern though. http://www.dtic.mil/ndia/2014system/16990WedTrack1Shanahan.pdf http://www.dtic.mil/ndia/2014system/16990WedTrack1Shanahan.p...

Cyph0n 11y ago
I've never heard about the DoD initiative. Thanks for the link!
- Nrsolis 11y ago
  Yeah. This has been something they've been looking into for a while now. Read all of the updates. It's turtles all the way down. https://www.schneier.com/blog/archives/2012/05/backdoor_found.html https://www.schneier.com/blog/archives/2012/05/backdoor_foun...

lvs 11y ago

A malicious module would only need to act like VW's defeat device to overcome that check. When it senses some integrity/signing routine, it simply isolates itself from a verifiable circuit.

Someone 11y ago
For VW, that was easy because the test setup was known and very rigid. If you randomly check, say, power usage and latency of the on-board RNG (ideally combined with high-resolution IR recordings of the CPU), it will, at least, be harder for the CPU manufacturer to install a backdoored RNG that is active most of the time (but one that only gets activated after receiving some trigger, say a specific instruction sequence would still be virtually undetectable)
- Nrsolis 11y ago
  The problem you are trying to solve is much closer to the "decidability problem" than you might suppose at first sight.
readams 11y ago
There is no procedure you can run that would show that the RNG was compromised. They would still give you a stream that's indistinguishable from random noise, except it would be generated from a seed known to the attacker.

matt_wulfeck 11y ago

AFAIK the linux kernel does use the RDRAND instruction set from example Intel. However, it uses it as a mix-in source of entropy and is not the sole source of the csprng seed. I personally think this is a good approach, as it allows hardware TRNG to increase the quality and quantity of entropy without being able to own the internal generator.

ryuuchin 11y ago
You're correct it does. Specifically I believe it uses rdrand to fill the initial SSH values when get_random is called which then proceeds to mix in stuff from the kernel pool. This avoids the problem with using xor for mixing as has been discussed before (even though that attack vector is unlikely). BoringSSL takes a similar approach with rdrand in that it mixes it using the chacha20 stream cipher. The operating system PRNG is used to generate the keys and rdrand is filtered on every call when you need a random number. I don't know what LibreSSL does (it uses chacha20 in some manner) and I'm pretty sure OpenSSL doesn't use rdrand at all unless you ask for it (in which case it will ONLY use rdrand).

cyphar 11y ago

There's a silicon doping attack for CPUs which makes them impossible to verify with current verification techniques (as far as I understand). The idea is that if you dope the silicon in the circuit you can change the circuit and it's not possible to figure out if it's been changed through forensics (x-rays, etc) or just using it (sufficiently clever backdoor). I'm unsure if FPGAs are vulnerable to this attack (though I've heard they might not be). This is the paper: http://sharps.org/wp-content/uploads/BECKER-CHES.pdf http://sharps.org/wp-content/uploads/BECKER-CHES.pdf