3 ms·
If you assume the CPU is compromised, then mixing in RdRand among other entropy sources is still not safe. For instance, the RdRand instruction could set a flag
by tlb 13y ago
If you assume the CPU is compromised, then mixing in RdRand among other entropy sources is still not safe. For instance, the RdRand instruction could set a flag that, with some small probability, zeros out anything XORed with it so you occasionally get zeros in the entropy pool. Or some other known-to-the-bad-guys value.
- cliveowen 13y agoThat's not something that you can address with software, by definition.
- plorkyeran 13y agoIf the CPU is compromised then you've already lost.
- deleted 13y ago[deleted]
- tlb 13y agoSure, but the CPU has to perform correctly on general-purpose computations so it's not too likely that, for example, the multiplication instructions occasionally give wrong results. Detecting cryptographic code executing in the CPU and subverting it is hard in general, but quite easy if you have a special instruction used only for the purpose.
- jerf 13y agoYou've overshot, though. The solution to what you're describing isn't to remove RdRand from the Linux kernel, it's to entirely give up. This is not a defense of the change.org request.
- tptacek 13y agoThere are multiple special-purpose security instructions; AESENC, for instance, or even PCLMULQDQ, which was added to speed up GCM. Which ones should we keep and which ones should we jettison?
- makomk 13y agoSince AESENC and PCLMULQDQ are meant to be deterministic - including their timing - it's rather harder for Intel to subvert them in a way that's not detectable than something like RDRAND.
- devx 13y agoIf the CPU is compromised then we should try to find out about it. We might not all be cryptography experts like Linus is implying he is, but he saying there's no way the CPU could be compromised and use the backdoor against Linux? If not, then he should invite more scrutiny, not less. From what I understand it would be very hard to even know if the CPU is compromised, so why is he so absolutist about it then, if it's impossible for him to prove with absolute 100 percent certainty that it's false? As the post at the top says: trust no one.
- conductor 13y ago> If the CPU is compromised then we should try to find out about it. This is a copy-paste of my comment from an older thread [0]: http://www.xakep.ru/post/58104/ http://www.xakep.ru/post/58104/ (use Google Translate) TL;DR The author has found an undeclared software module (backdoor?) working as a hyper-visor in the System Management Block chip on the South Bridge working with Intel CPU with VT virtualization technology. [0] - https://news.ycombinator.com/item?id=4462782 https://news.ycombinator.com/item?id=4462782
- bcoates 13y agoBuy CPUs from two (or n) different vendors and run a user space lockstep execution virtual machine between them. Unless all vendors are compromised in exactly the same way, the output will fail to verify. Of course, this would prevent you from using RdRand as your VM implementation will only be able to call on deterministic instructions...
- raverbashing 13y ago"with some small probability, zeros out anything XORed with it" You really don't know what you're talking about. Really Write the code for this then, go ahead, and show how it would work (hint: it doesn't) And as others said, if your CPU is compromised you already lost.
- reitzensteinm 13y agoYour dismissive tone is rude and uncalled for. There's nothing fundamentally impossible about the method tlb is suggesting. It would actually be quite a clever hack.
- raverbashing 13y agoIt can't be done. Between the RdRand instruction and the next XOR nothing guarantees that: 1 - The task won't be preempted 2 - That XOR will be used for entropy calculation And even if n. 1 doesn't happen, n. 2 is very hard to guarantee (and easy to avoid) Of course I'm dismissive because it's obvious to me it can't work like that. But please let's continue discussing impossible theories and barking at wrong trees. There are easier and more effective attacks than that.
- tlb 13y agoIt doesn't have to work every time, just occasionally (1 in 1,000,000) is enough to introduce an exploitable weakness. So task preemption isn't a problem. XOR is used for entropy calculation in the Linux kernel, as Dale Emmons points out in the article.
- raverbashing 13y ago> So task preemption isn't a problem Yeah, you're just crashing a different task > XOR is used for entropy calculation in the Linux kernel You sound like you don't know C, less alone have any knowledge of assembly language. That phrase is correct but absolutely useless. Do you know how that code snipped is translated to assembly? On x86? On x64? With optimisations? Without? How different OSs would use RdRand?
- m_ram 13y agoMaybe there are less obvious things they can do (I'm not an expert), but isn't this what testing software like dieharder is designed to detect? I assume people are testing /dev/(u)random often.
- hannibal5 13y agoI believe you are extrapolating the threat model past anything reasonable. The original concern around RdRand is that the tiny on-chip random number generator might be compromised. You are arguing that there might be implementation that uses code analysis to detect data flow from RdRand and mess with it. It sounds very far fetched.