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

[ianG]

On 18/12/13 04:47 AM, Theodore Ts'o wrote:
> On Tue, Dec 17, 2013 at 10:52:41AM +0300, ianG wrote:
>> 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!
>
> The problem is that I've actually taken a graduate class in CPU
> architecture and design at MIT, so I understand the difference between
> a gimmicked RDRAND functional unit, and something which requires
> making changes to the instruction decode logic, the register renaming
> logic, and all of the other bits of complexity that make a modern CPU
> go really, really fast by doing out-of-order instruction execution.


Yep.  I think mine was grad level but I did it as undergrad.  And, yes, 
we built a computer, and wrote a microcoded instruction set.  A lot of 
fun.  I'll admit my knowledge is way out of date tho, this was back in 
'83, the sophistication of what is now done in microcode has way 
eclipsed my understanding.


> Yes --- it could be done.  But it would require having at least an
> order of mangitude or two more people inside Intel that would have to
> know about it.  It's not something you could just hide away inside the
> RDRAND unit, which among other things, is documented as having AES as
> its final "whitening" step.  So if you can control what key it uses
> and what input it's fed, it's much easier to gimmick RDRAND in a way
> where it would be very hard for someone to notice without doing
> extensive electron microscope and circuit analysis.


I think it is clearly necessary to gimmick RDRAND, and probably this 
would be a first step along the journey.  As PHB recently posted, each 
subversion is likely a process of small steps, starting out with one or 
two very reasonable requests.

Like,

      "we want to put your RDRAND mode into a deterministic mode so we 
can test it.  As you know, FIPS requires deterministic RNG testing, and 
we (the NSA) consider that to be an article of faith.  What can we do 
here?  By the way, one of our engineers knocked up this idea..."



As to whether the secret can be held, consider the story of DUAL_EC. 
That was a secret that Snowden knew, a contractor.  I draw from that, 
that a lot of people knew about the project.  I also think that a 
certain amount of hubris affected the secrets sharing of the NSA over 
the last decade, they have done things that they promised would never 
come to light, and have been found out.  E.g., somewhere it was reported 
that they got authorisation from Obama for Stuxnet on the promise that 
the secret would never come out.

Consider also Olympic Games.  That secret must have been shared by many 
hundreds, perhaps thousands, across multiple agencies & countries.  Yet, 
the only way we found out was when the darn furriners found the samples 
and decided to ask around what they were.


> However, if you are going to posit that the CPU is so badly subverted
> that the instructure decode and execution units can analyze the
> machine instructions to figure which register is being used as the
> pointer to the entropy pool or being used for the output,


I'm positing that this is normal:  pipelining does more or less the same 
thing for a different goal.


> then you
> could just as easily imagine the CPU going into System Management Mode
> to scan for AES keys and then ship them off the system either using
> the network card, either by modulating the timing of packets or by
> sneaking bits into unexamined portions of the network packets.


Yep.  This would be the fast version of the infamous lunch time attack 
posited by Adi and Nicko.

Yes they could do that.  I don't like that attack because it leaks 
information by means of packets.  That's something that would be 
reserved for very hard and rare targets, and it would need to be 
precisely tailored.  How many 128 bit random strings are there to scan?


> Hacking SMM would be much easier, and allow a much larger and wider
> range of attacks.  Or you could hack the keyboard controller to
> capture packets: https://www.usenix.org/legacy/event/sec06/tech/shah/shah.pdf
>
> Ultimately, if you need to live at that level of paranoia, you'll need
> to build your own CPU out of TTL logic chips --- something which I
> learned how to do when I was a freshman at MIT.  It won't be a
> terribly fast computer, though....


No such is necessary.  Just don't elevate RDRAND to a superior position 
as a post-RNG XOR phase.  Be happy with it as a collector.

Just get rid of these lines:


         for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
                 unsigned long v;
         // arch_get_random is RDRAND.
                 if (!arch_get_random_long(&v))
                         break;
                 hash.l[i] ^= v;
         }


(I'm just reading this guy:  http://pastebin.com/A07q3nL3 and I could be 
misunderstanding...)

iang