Re: use of RDRAND in $random_library
On 6/13/14, Theodore Ts'o <tytso@mit.edu> wrote:
> On Fri, Jun 13, 2014 at 10:09:02AM +0200, Martijn van Oosterhout wrote:
>> > Excuse me if I'm blunt here, but I understand that, on the point of
>> > using entropy to seed a PRNG, if you have several shitty entropy
>> > sources and one _really_ good one, and you xor them all together, the
>> > resulting output is as random as the best of them. If your hardware
>> > entropy source is faulted and produces just an endless stream of
>> > '001001001001001001', xoring it with a valid Golomb sequence will give
>> > you something even more random than a Golomb sequence.
>> >
>> The proof that XORing streams can't reduce the entropy relies on the
>> sources being independant. I think the issue here is we don't know if
>> RDRAND is independent or not. That said, doing a SHA256 over the output
>> should be sufficient (assuming the CPU doesn't see you're doing a hash
>> and
>> short circuits it).
>
> Basically, the question is how blatently do you think the NSA could
> bugger the CPU. If you believe they can completely bugger the CPU, so
> they can detect that you are implementing some explicit crypto
> instruction, and change its behaviour, or they can peek ahead in the
> instruction pipeline, notice an XOR, determine that one of its inputs
> is an RDRAND instruction, and the other inputs come from a read of
> /dev/urandom, and then modify the behaviour of the XOR, all in such a
> way that the hundreds or thousands of Intel employees that need to
> improve, test, debug, etc. the CPU instruction execution engine
> wouldn't notice, then you might as well give up now and start
> implementing your own CPU from transitors, capictors, resistors, and
> wires.
>
> While I am willing to believe they might be able to secretly subvert
> or bribe Intel to subvert the RDRAND engine, in some way which no
> other or very few other employees at Intel would detect, to believe
> they could then do so with the entire CPU is MUCH harder to believe.
>
I would expect that if the NSA wanted to take control of the RDRAND or
the rest of the CPU, they'd dynamically update the microcode in the
CPU to change how it behaves. To do this, it appears that they'd need
to sign a microcode and then apply an update. According to some great
research by Ben Hawkes, it may be that there is a 2048bit RSA key that
is used for signing:
http://inertiawar.com/microcode/
In the case of Lavabit, we have learned that the US Government will
assert that they can request cryptographic keys in a Grand Jury. Is it
that case that they might try the same with Intel? Is 2048 a large
enough key size to stop the NSA? There are quite a few open questions.
If the NSA can update the microcode, I believe we could fairly state
that they have subverted the security of the entire CPU.
> There are probably much easier things to do, such as subverting
> someone in Red Hat's release engineering department, for example. A
> buggered kernel is easier to accomplish, and much harder to detect.
> This is one of the reasons why implementing reproducible binary builds
> is a realy good idea from a security perspective. This allows you to
> spot check that various binaries correspond to the sources that they
> claim to be form.
>
I agree and I'd add that they're likely taking many angles all at
once. And it isn't just the NSA. The NSA just has a great head start
and a home field advantage.
"Intel Inside" could have a few different meanings! :-)
All the best,
Jacob
Reply to: