[Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say

ianG iang at iang.org
Sat Dec 14 08:54:05 EST 2013


On 14/12/13 15:35 PM, Jerry Leichter wrote:
> On Dec 14, 2013, at 1:49 AM, ianG wrote:
>>> Why not just XOR RD_RAND outputs with Yarrow outputs?  That guarantees strong results if either one is good.
>>
>> That would be to reinvent Yarrow?
>>
>> If that were known as Linux's approach, and RDRAND where spiked, it would be a simple matter to spike the RDRAND in microcode again (a known/suspected capability).
>>
>> Perhaps to unXOR the contents of the previous instruction and XOR in the secret stream...
> So now you're talking about a hardware modification that detects that an XOR is being done to the output stream of the software implementation of Yarrow, and take special action in that case?  It's not like you can screw with the semantics of every invocation of XOR - that would be noticed right away.
>
> I can believe in the plausibility of such an attack if it were hyper-targeted:  You know the exact code that the chip whose hardware you're spiking will run, down to a characteristic set of instructions that will be run exactly when a random bit stream is to be produced.  Maybe there are cases - e.g., embedded chips going into high-value targets running a specialized set of code that's almost never changed - where this is plausible.  But for a general purpose chip running an OS version that probably didn't even exist when the chip was designed?  I don't think so.
>
> If, on the other hand, you're talking about actively spiking the microcode of a chip whose software you know all about - the RDRAND call is irrelevant:  Just latch on to the point where the output of the internal random number generator is about to be returned and return whatever you like?


I'm sure there are multiple ways of doing it.  I'm trying to spot the 
simplest, one that could be slipped into microcode without upsetting 
things -- minimal use of space/time/op changes.

The RDRAND instruction I'd say is the low hanging fruit, because it is 
called rarely and for precise purposes.  Inside that instruction, check 
whether there is a XOR coming up, of the output of RDRAND and some other 
X.  Likely, that value X is already calculated, sitting in a register 
somewhere.  Do some pre-XOR magic with that X, and the RDRAND output, 
and the secret sauce.

This of course all depends on some high value target (breadth or depth) 
using a simple RDRAND XOR yaPRNG approach.

Of course, the answer is to go back to the core design:  put RDRAND as 
just another collector feeding into the mixer, so there is little 
sensitivity especially to that one, and no easy way to determine (in 
microcode) how much extra processing comes after the RDRAND point. 
Treat RDRAND like every other entropy source -- borkable.

iang



More information about the cryptography mailing list