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

ianG iang at iang.org
Tue Dec 17 02:52:41 EST 2013


On 16/12/13 20:35 PM, John Kelsey wrote:
> On Dec 14, 2013, at 1:49 AM, ianG <iang at iang.org> wrote:
> ...
>> 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...
>
> You are assuming a way, way more complicated and specialized bit of malevolent engineering in the RNG chip, at that point--

Sure.

Means?  The NSA has the means (& budget) to do opcodes, microcode, Intel 
hacking, make no mistake.

Opportunity?  Only very few persons have the opportunity to manipulate 
the microcode, which is almost certainly what would be needed to mount 
this attack.  So it would seem to be out of reach, a pipe dream, a 
fantasy, at first blush.

But: on knowledge or belief (to use the legal term) the NSA is one of 
those very few persons who can manipulate the microcode of Intel's CPUs 
(and this has been true for at least 2 decades, to my belief or knowledge).

Motive?  On the question of malevolence, I think Snowden revelations 
have taken us there.  They want this, if it can be made to work, and 
they'll try it if they don't know.  That's what they said in the goals 
revelations, and I believe them.

> one that only works on one OS RNG,

If it works on Linux, that's an unimaginably rich prize.

That's probably half the server space out there!  Probably 90% of their 
SSH and SSL keys could be attacked if there was a secret stream embedded 
into their 'safe' /dev/random feeds.

If it works on Cisco/Juniper routers, ditto.  Microsoft, same.

Think about how to make it work on more platforms -- it's already out 
there, staring us in the face :)

> and one that probably breaks every time there's an OS upgrade that touches the RNG.

What I am assuming is that Linux devs are a trusting bunch, and don't 
believe that this could be done.  As Nemo posted earlier:

http://blog.lvh.io/blog/2013/10/19/thoughts-on-rdrand-in-linux/

http://pastebin.com/A07q3nL3

Lays out the story better than I can.  They didn't believe it could be 
done.  And they've created the incentive to try.  Bad Linux!


> Also, I have to guess that the CPU designer could find hundreds of easier ways to screw over my security.  What OS-based RNG could withstand having the CPU it's running on designed to defeat its security?


Which is the problem we are facing in unravelling what they can do.

Intel is not audited or otherwise publically verifiable as being clean, 
and has a very strong, long standing relationship with the NSA.  As a 
matter of historical fact, they added a population count opcode (others 
will know more).  The only one who needs that is the NSA.  This isn't 
the end of their involvement, just the bits we know about.

A question is indeed, assuming attacks are happening at the CPU level, 
what is the easiest way security could be perverted?

It has to be a really simple thing -- something that can be spotted in 
very few instructions, as anything else would be non-robust in the face 
of compiler optimisations, updates, etc, and very hard to analyse in the 
limited space within.  As you say.

As we're talking about the RNG, then the current yarrow-post-XOR is that 
very simple thing.  If the CPU can do pipelining, then it can spot the 
XOR after the RDRAND.  And find the other value... and pre-process it 
for the perfect RDRAND output.

This is a beautiful attack!  Impossible to verify, secret, and 
unbelievable.  There are no time implications, RDRAND is already a 
complicated instruction.

The solution is simple -- RDRAND should be as trusted and untrusted as 
every other source.  It should be collected before the mixer, like the 
others.  There should be no post-RNG special XOR phase.  Never ever.

Linux should not only dump that bad idea for its own security, but also 
so as to not encourage anyone to try that attack.  Bad Linux!

iang


More information about the cryptography mailing list