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?

Viewing 5 Comments

    • ^
    • v
    • ^
    • v
    I have a straightforward critique of your Hyperthreading jihad: you aren't addressing attacks that normal users face, you aren't even resolving the attacks you're address completely (but rather hacking up the kernel and crippling the architecture), and you're breaking shit while you do it (your "Core Solo").

    You have a bunch of responses to that critique, the majority of which have nothing to do with my argument ("breaking FreeBSD in order to create an incomplete solution to timing attacks is a bad idea"), but rather are about how important YOUR work and YOUR paper is, and how I'm consistently getting the chronology wrong by suggesting you have any predecessors.

    You published your paper in May '05. Osvik presented his work in March '05. The only publically available copy of your paper doesn't cite Osvik et al. Citations predate the web. What's the problem? You can't seem to support your claim about my chronology mistakes with evidence.

    You claim that your work was so important that Intel tried to stop you from publishing it. Speaking as someone who has actually been stopped from publishing a security result: I call bullshit. You published anyways. How serious could the threat have been? Support your claim with evidence.

    I don't know what the "field of comparative open source project management" means. Neither do you. But you did get on kernel traffic and you did pick a fight with Linus and you did do it because he dared suggest that your hack not be mainlined into Linux. How has your verbal dodge mitigated the appearance that your goal was to get attention, and not to save the world?

    I believe you didn't take a job in the period you described. My wording was unclear. You don't need to support the claim that you were unemployed with evidence. What I meant was: you haven't supported the claim that your goal wasn't a publicity attack with evidence.

    Conceding that your word on crypto is more authoritative than mine doesn't imply I'm conceding that I don't know how your cache timing attack works. Side channel attacks aren't constrained to cryptography; I used one in 1997 to detect promiscuous sniffers on general purpose operating systems remotely. Moreover, I'm not sure that quoting Osvik, Tromer, and Shamir contradicting you directly counts as "floundering". Maybe it does, and, once again, maybe you could try backing up your claim with evidence instead of ad-hominem.

    Finally, "demonstrating" an attack that everyone seems to have known about months before your demonstration makes you Alec Muffett, not Paul Kocher. I don't know what writing your own vanity crypto library instead of working to fix OpenSSL makes you. Tom St. Denis maybe? Great paper, Colin. I'm sure they'll teach it in University. Can you go find some integer overflows now, or at least leave the kernel alone?
    • ^
    • v
    Can't we all just get along?
    • ^
    • v
    >Finally, “demonstrating” an attack that everyone seems to have known about months before your demonstration makes you Alec Muffett, not Paul Kocher.

    Blimey, Tom - what on earth did I do to become a byword?

    I can't recall ever making a claim that I had invented something /old/, although not infrequently I've helped to make things more "accessible"...
    • ^
    • v
    ps: Hello. :-)

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus