Colin’s Very Important Response

Thomas Ptacek | April 27th, 2006 | Filed Under: Defenses, Uncategorized

That was fast. Colin takes me to task, and I’ll summarize and respond.

First, two places I was wrong. I said Colin cribbed his work from DJB’s cache timing paper, which is a remote attack against AES based on S-box table lookup. Colin also posted his paper months after Osvik and Tromer published what is now “Cache Attacks and Countermeasures: the Case of AES”. Colin didn’t cite. But it’s wrong of me to suggest that work that Colin did concurrently and independently of DJB and Osvik et al was purely derivative.

Colin also calls me out on refering to data-independence, rather than data-obliviousness. A data-oblivious implementation of AES is designed so that memory access occurs “completely oblivious” to the data passing through the cipher. From Osvik et al: You can read the whole table and select out the result you need, or you can randomize memory accesses, or shuffle the S-box tables on each access. You can also decrease signal by generating spurious memory accesses. This was my mistake, and it happened because Colin knows much, much more about crypto than I do.

The rest of Colin’s critique, eh, not so much:

Colin seems apalled that I suggested he had worked to promote himself. Here are some things that set me off:

• Cajoling OS developers into disabling an extremely useful feature in the interest of partially mitigating an attack that, for almost all users, will never occur.

• Monopolizing attention on timing attacks for a localhost attack despite the existence of a plausible remote timing attack for which Colin’s suggested OS changes do nothing to address.

• Insinuating that, as a result of writing the third paper in as many months on Intel cache timing attacks, Intel was now trying to get him, and then accusing anyone who criticized him of secretly working for Intel.

• Picking a fight with Linus Torvalds, the “dictator” who declined to mainline Colin’s suggestion despite the fact that the overwhelming majority of kernel traffic posters agreed that disabling HT was crazy talk.

• Publicizing an “advisory” for a general crypto practical finding, unlike any of the other researchers in this field, and then berating OS developers who questioned him.

Maybe I’m wrong, and Colin really did foresake gainful employment in order to save the world from Hyperthreading Timing Attacks. But Colin hasn’t yet supported that claim with evidence.

Colin is irritated that I suggest that there are other serious localhost timing channels. “But none of those attacks are MINE!”, he seems to be asserting. Colin repeatedly asserts that the bandwidth of his timing attack makes it qualitatively different from other attacks. But Osvik et al, which is clearly the more authoritative work, disagrees:

We have demonstrated the attack […] with HyperThreading, but it can also be performed on other platforms without relying on [SMT]. The key is for the attacker to find a way to execute its own code midway through an encryption […] For example, the attacker can predict RTC or timer interrupts and yield the CPU to the encrypting process a few cycles before an interrupt [thus allowing the attacker to regain the CPU immediately after an encryption operation, enabling them to probe the cache].

Likewise, Colin is annoyed that I suggested he believed the L2 cache was a viable attack vector. That’s because Colin was forced to give up on having the OS guard the L2 cache, after a change he made to FreeBSD halved the peformance of the Core Duo. But again, Colin’s the only member of this consensus; from Osvik et al:

On multi-core processors, the lowest-level caches (L1 and sometimes L2) are usually private to each core, but if the cryptographic code occasionally exceeds these private caches and reaches caches that are shared among the cores (L2 or L3), the asynchronous attack becomes applicable.

Freely conceded that both DJB and the Osvik, Tromer, Shamir team think HyperThreading should be disabled. Pace Colin himself, they clearly don’t understand the problem, but in their defence, they’re not OS guys. Maybe some developers who do understand real-world deployment scenarios will talk some sense into them. The overwhelming majority of computers, both servers and clients, are not impacted by this attack. That will change as virtualized shared servers become the norm, but by then, OpenSSL will have changed too.

My real issue here is not that I think Colin hasn’t accomplished anything. As I think I’ve demonstrated, I’m not qualified to challenge his crypto results, and while Osvik and Tromer’s “Prime and Probe” technique seems to presage 80% of Colin’s own paper, he has clearly done important work extending it to RSA.

My problem is that Colin is the “Security Officer” for FreeBSD, and he’s wasting his time disabling useful architecture features on a platform that probably allows unprivileged localhost attackers to read the memory out of any process anyways. Any localhost kernel or privilege escalation finding Colin published would be more impactful than his Hyperthreading Windmill Tilting.

Your thoughts, Colin?