6 ms·

I'm gonna go and take issue with the claim that you were the first to come up with microarchitectural attacks, and that their story begins in 2004: - Dan Page

by pbsd 9y ago

I'm gonna go and take issue with the claim that you were the first to come up with microarchitectural attacks, and that their story begins in 2004: - Dan Page published [1] in 2002, describing an attack on DES exploiting cache timings. In 2003, he published [2] describing countermeasures to this class of attacks. - Concurrently, a Japanese team also attacked DES (and MISTY1) with cache timing [3, 4]. - Dan Bernstein published the first version of his AES cache timing attack in late 2004 [5]. [1] https://eprint.iacr.org/2002/169 https://eprint.iacr.org/2002/169 [2] https://doi.org/10.1016/S1363-4127(03)00104-3 https://doi.org/10.1016/S1363-4127(03)00104-3 [3] https://link.springer.com/chapter/10.1007/978-3-540-45238-6_6 https://link.springer.com/chapter/10.1007/978-3-540-45238-6_... [4] https://web.archive.org/web/20060906064630/http://web.engr.oregonstate.edu/~aciicmez/osutass/data/Tsunoo02.pdf https://web.archive.org/web/20060906064630/http://web.engr.o... [5] https://cr.yp.to/antiforgery/cachetiming-20041121.pdf https://cr.yp.to/antiforgery/cachetiming-20041121.pdf

dsacco 9y ago
Thanks for writing this. I didn't like the opening paragraph either, and your comment is a better rebuttal than I could have written. Colin, I think this is a good perspective on Spectre and Meltdown, but it feels like the entire opening paragraph was an unnecessary attempt at a "me too" that implies you're the modern father of these sorts of attacks when that isn't really the case. I understand you're establishing credibility and expertise (and you have both), but it's disingenuous to begin with, The story of these attacks starts in late 2004, and then go on to describe your own work. I think the rest of your post has its own utility without writing a narrative of these attacks that inserts you at the beginning of them.
- cperciva 9y ago
  I spent a long time wondering about this. Honestly, I think I am (along with Osvik and Tromer) modern father of these sorts of attacks. (See my reply to pbsd for why.) I think people in the field recognize my credibility and expertise here, and for them that paragraph is superfluous; but I was aiming this blog post at a wider audience (hence the effort spent on non-technical analogies to help them understand the issues) so I thought it was important to explain my background to people who had never heard of side channel attacks before.
  - idlewords 9y ago
    If you're writing for a broader audience, then all the more reason to omit this history. It's like hearing about Darth Vader's childhood; people just want you to get to the good part. I like to think of it this way: readers from a general audience have a certain mental budget for understanding that they bring to an article like this. Once they exhaust that budget, you've lost them. So it helps to take special care to spend it on your key points. It also, if I can be frank, makes you look hungry for credit, which you'll get more of if you play it cool.
    - tanderson92 9y ago
      I have no background in computer architecture security or security at all, and appreciated the background of how he saw his work fit into the current day. Especially so because cperciva's original paper was being widely shared on HN in the ensuing Spectre/Meltdown threads.
    - cperciva 9y ago
      Fair enough. My personal writing style tends towards the narrative "start at the beginning and tell the story in chronological order" but I certainly understand the desire to "get to the good part". If I ever write a blog post about scrypt and all the work which has come after it, maybe I'll skip the lengthy analysis of how Tarsnap customers inspired me to investigate the topic of password-based key derivation. :-)
  - tptacek 9y ago
    Another straightforward way to handle this is to bury the lede a little bit, and begin by briefly describing the previous cache work. That saves you from having to make an elaborate explanation of your specific claim on the history here. "Show, don't tell".
carterehsmith 9y ago
Are we restricted to Intel here? Here is something for VAX, from 1992: http://ieeexplore.ieee.org/document/213271/ http://ieeexplore.ieee.org/document/213271/ But to be honest, whether something was published 14 or 17 or 36 years ago... is kind of interesting, but only mildly so. How about this question: was Intel aware of these publications? If they were, then... what happened? Or maybe they were not aware, or maybe someone was, but failed to communicate it to the right people, or maybe it was assigned JIRA x2399827348 and forgotten. Wish we knew what happened.
- tptacek 9y ago
  Intel was absolutely aware of microarchitectural side-channel attacks before Spectre and Meltdown; an Intel employee (Onur Aciicmez) published the first branch predictor side channel paper (at least that I'm aware of).
  - carterehsmith 9y ago
    Uh-huh, ok. Thanks. BTW This is one of the papers, from 2005: http://cryptocode.net/docs/c36.pdf http://cryptocode.net/docs/c36.pdf So... interesting. Do they just leave this kind of stuff open so that NSA can use it for a while. Maybe so, but then, why are those things published in journals? Weird.
    - tptacek 9y ago
      Here's the one I'm thinking of: https://eprint.iacr.org/2006/288.pdf https://eprint.iacr.org/2006/288.pdf
- fulafel 9y ago
  What would it mean for a corporation of this size to be aware of a highly specialized finding in the research literature? Intel has 100k+ employees, so it's quite likely that an Intel employee has read this paper, but what kind of effort and incentive does it take to successfully escalate this kind of thing to high enough that the ship turns? edit: apparently I just restated the latter part of your post, nevermind :)
cperciva 9y ago
first to come up with microarchitectural attacks I'm not saying that. There are definitely earlier attacks which exploit microarchitectural features (including caches). What I am saying is that as far as I'm aware I'm the first person to demonstrate an attack consisting of 1. Information being leaked from a process into the microarchitectural state of the CPU, followed by 2. That information being retrieved by another process. This is the model which the vast majority of attacks over the past decade have followed, and it's the model which Spectre/Meltdown make use of.
- caf 9y ago
  I think Meltdown can be best characterised as being the same process that leaks and retrieves the information. The bug being that a process is able to leak data into the micro-architectural state that it isn't allowed to read directly.
  - cperciva 9y ago
    Fair enough. The point remains, information is leaking into the microarchitectural state and then being extracted from there -- quite different from earlier attacks which simply exploited the fact that the microarchitecture resulted in certain operations during a cryptographic computation being faster or slower depending on the data being handled.
- pbsd 9y ago
  That's a much more defensible claim---one I have no issue with---but it was easy to misread the post and believe it was claiming something more general.
  - cperciva 9y ago
    Thanks! It's getting late here (3 AM) so this might not be the best wording, but would it help if I added a note after the third paragraph along the lines of "Note that there have been previous side channel attacks which depended on how microarchitectural features (usually caches) affected code execution; but my work was the first to demonstrate information leaking from a program into the microarchitectural state and then being extracted from there." ? (Feel free to suggest other wording too -- as I said, it's getting late here and my word-putting-together skills are currently subpar.)
mfukar 9y ago
Wray, 1991: https://www.cs.cornell.edu/people/vickyw/iflow/papers/wra91.pdf https://www.cs.cornell.edu/people/vickyw/iflow/papers/wra91.... Sibert, Porras, Lindell, 1995: https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653...
nickpsecurity 9y ago
I already countered him on microarchitectural covert channels. Goes back further to VAX Security Kernel (1992) being designed to certify to A1-class which mandated covert-channel analysis that regular, "secure coders" didn't do. INFOSEC pioneers had already found them in software and hardware like disks. A person on that project reported them for cache timing as well. Aside from the Trojan model, they also described them back then as inherent design flaws where shared resources leak details about one computation to another. In other words, cpercival's model. They talked about Trojan model mostly because solving the threat of superset model, subversion, solved other one as side effect. Knocking out all backdoors and leaks was what culture of the time highlighted the most. I pointed it out plus some follow up commentary here: https://lobste.rs/s/tj55ox/counterpoint_intel_weaknesses_known https://lobste.rs/s/tj55ox/counterpoint_intel_weaknesses_kno... I didn't respond to the later nonsense dismissals on HN and elsewhere about the Intel CPU Security submission since I had surgery shortly after that on an impacted tooth. Didn't want to be online all drugged up talking about these things. ;) Suffice it to say, high-assurance security had already found piles of risk areas for both penetration and side channels in Intel CPU's with some attempts at mitigation (including avoid Intel CPU's) by the mid-1990's. They encouraged Intel, purchasers, and security community to deal with it as part of routine work in improving security. As usual, the mainstream security community just ignored everything they said when they bumped into each other. It's not like high-security folks stopped trying to tell them about prior successes and problems: http://www.cse.psu.edu/~trj1/papers/ieee-sp-vaxvmm.pdf http://www.cse.psu.edu/~trj1/papers/ieee-sp-vaxvmm.pdf Then, a bright researcher independently discovered the side channels in caches later. They started reacting to that claim. They found some similar issues in other stuff looking narrowly. Now, we have another clever attack that started with a shared resource as would've been identified in the 1992 methodology that got stretched in really creative ways. It was still same root cause they ignored or justified for things like lowest price/performance versus alternatives doing it securely. Or just physical separation of different security domains which highest-security setups stuck with grudgingly. My prediction in one of the Lobsters comments was that piles of comments would happen about this that didn't involve actually solving it (social gratification), more people would similarly write articles boasting their understanding to generate extra rep since talking problems in is rewarded in mainstream INFOSEC more than preventing/solving them, a few mitigations would show up that were narrowly-focused on just this new kind of problem (like happened with caches), they'd still ignore prior work in high-assurance like Kemmerer or Wray's analyses that found similar problems 20+ years before analyzing whole system, they'd mostly ignore the new work on information-flow analysis (some in link below), and we'd at best get some time until the next problem that could've been prevented by 1990's or recent methods since that's how mainstream security industry and culture works. They're right on track since that's about all I saw while in recovery for a week. Endless articles using the buzzwords to their advantage plus people who don't know we could've beaten this in the 1990's because security professionals in industry suppress that knowledge for some reason. That needs to stop. At least they're rediscovering 60's-90's knowledge at an accelerated rate now. Work on Information Flow Security in Hardware https://pastebin.com/ajqxDJ3J https://pastebin.com/ajqxDJ3J

by pbsd 9y ago

dsacco 9y ago

Thanks for writing this. I didn't like the opening paragraph either, and your comment is a better rebuttal than I could have written. Colin, I think this is a good perspective on Spectre and Meltdown, but it feels like the entire opening paragraph was an unnecessary attempt at a "me too" that implies you're the modern father of these sorts of attacks when that isn't really the case. I understand you're establishing credibility and expertise (and you have both), but it's disingenuous to begin with, The story of these attacks starts in late 2004, and then go on to describe your own work. I think the rest of your post has its own utility without writing a narrative of these attacks that inserts you at the beginning of them.

cperciva 9y ago
I spent a long time wondering about this. Honestly, I think I am (along with Osvik and Tromer) modern father of these sorts of attacks. (See my reply to pbsd for why.) I think people in the field recognize my credibility and expertise here, and for them that paragraph is superfluous; but I was aiming this blog post at a wider audience (hence the effort spent on non-technical analogies to help them understand the issues) so I thought it was important to explain my background to people who had never heard of side channel attacks before.
- idlewords 9y ago
  If you're writing for a broader audience, then all the more reason to omit this history. It's like hearing about Darth Vader's childhood; people just want you to get to the good part. I like to think of it this way: readers from a general audience have a certain mental budget for understanding that they bring to an article like this. Once they exhaust that budget, you've lost them. So it helps to take special care to spend it on your key points. It also, if I can be frank, makes you look hungry for credit, which you'll get more of if you play it cool.
  - tanderson92 9y ago
    I have no background in computer architecture security or security at all, and appreciated the background of how he saw his work fit into the current day. Especially so because cperciva's original paper was being widely shared on HN in the ensuing Spectre/Meltdown threads.
  - cperciva 9y ago
    Fair enough. My personal writing style tends towards the narrative "start at the beginning and tell the story in chronological order" but I certainly understand the desire to "get to the good part". If I ever write a blog post about scrypt and all the work which has come after it, maybe I'll skip the lengthy analysis of how Tarsnap customers inspired me to investigate the topic of password-based key derivation. :-)
- tptacek 9y ago
  Another straightforward way to handle this is to bury the lede a little bit, and begin by briefly describing the previous cache work. That saves you from having to make an elaborate explanation of your specific claim on the history here. "Show, don't tell".

carterehsmith 9y ago

Are we restricted to Intel here? Here is something for VAX, from 1992: http://ieeexplore.ieee.org/document/213271/ http://ieeexplore.ieee.org/document/213271/ But to be honest, whether something was published 14 or 17 or 36 years ago... is kind of interesting, but only mildly so. How about this question: was Intel aware of these publications? If they were, then... what happened? Or maybe they were not aware, or maybe someone was, but failed to communicate it to the right people, or maybe it was assigned JIRA x2399827348 and forgotten. Wish we knew what happened.

tptacek 9y ago
Intel was absolutely aware of microarchitectural side-channel attacks before Spectre and Meltdown; an Intel employee (Onur Aciicmez) published the first branch predictor side channel paper (at least that I'm aware of).
- carterehsmith 9y ago
  Uh-huh, ok. Thanks. BTW This is one of the papers, from 2005: http://cryptocode.net/docs/c36.pdf http://cryptocode.net/docs/c36.pdf So... interesting. Do they just leave this kind of stuff open so that NSA can use it for a while. Maybe so, but then, why are those things published in journals? Weird.
  - tptacek 9y ago
    Here's the one I'm thinking of: https://eprint.iacr.org/2006/288.pdf https://eprint.iacr.org/2006/288.pdf
fulafel 9y ago
What would it mean for a corporation of this size to be aware of a highly specialized finding in the research literature? Intel has 100k+ employees, so it's quite likely that an Intel employee has read this paper, but what kind of effort and incentive does it take to successfully escalate this kind of thing to high enough that the ship turns? edit: apparently I just restated the latter part of your post, nevermind :)

cperciva 9y ago

first to come up with microarchitectural attacks I'm not saying that. There are definitely earlier attacks which exploit microarchitectural features (including caches). What I am saying is that as far as I'm aware I'm the first person to demonstrate an attack consisting of 1. Information being leaked from a process into the microarchitectural state of the CPU, followed by 2. That information being retrieved by another process. This is the model which the vast majority of attacks over the past decade have followed, and it's the model which Spectre/Meltdown make use of.

caf 9y ago
I think Meltdown can be best characterised as being the same process that leaks and retrieves the information. The bug being that a process is able to leak data into the micro-architectural state that it isn't allowed to read directly.
- cperciva 9y ago
  Fair enough. The point remains, information is leaking into the microarchitectural state and then being extracted from there -- quite different from earlier attacks which simply exploited the fact that the microarchitecture resulted in certain operations during a cryptographic computation being faster or slower depending on the data being handled.
pbsd 9y ago
That's a much more defensible claim---one I have no issue with---but it was easy to misread the post and believe it was claiming something more general.
- cperciva 9y ago
  Thanks! It's getting late here (3 AM) so this might not be the best wording, but would it help if I added a note after the third paragraph along the lines of "Note that there have been previous side channel attacks which depended on how microarchitectural features (usually caches) affected code execution; but my work was the first to demonstrate information leaking from a program into the microarchitectural state and then being extracted from there." ? (Feel free to suggest other wording too -- as I said, it's getting late here and my word-putting-together skills are currently subpar.)

mfukar 9y ago

Wray, 1991: https://www.cs.cornell.edu/people/vickyw/iflow/papers/wra91.pdf https://www.cs.cornell.edu/people/vickyw/iflow/papers/wra91.... Sibert, Porras, Lindell, 1995: https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653...

nickpsecurity 9y ago

I already countered him on microarchitectural covert channels. Goes back further to VAX Security Kernel (1992) being designed to certify to A1-class which mandated covert-channel analysis that regular, "secure coders" didn't do. INFOSEC pioneers had already found them in software and hardware like disks. A person on that project reported them for cache timing as well. Aside from the Trojan model, they also described them back then as inherent design flaws where shared resources leak details about one computation to another. In other words, cpercival's model. They talked about Trojan model mostly because solving the threat of superset model, subversion, solved other one as side effect. Knocking out all backdoors and leaks was what culture of the time highlighted the most. I pointed it out plus some follow up commentary here: https://lobste.rs/s/tj55ox/counterpoint_intel_weaknesses_known https://lobste.rs/s/tj55ox/counterpoint_intel_weaknesses_kno... I didn't respond to the later nonsense dismissals on HN and elsewhere about the Intel CPU Security submission since I had surgery shortly after that on an impacted tooth. Didn't want to be online all drugged up talking about these things. ;) Suffice it to say, high-assurance security had already found piles of risk areas for both penetration and side channels in Intel CPU's with some attempts at mitigation (including avoid Intel CPU's) by the mid-1990's. They encouraged Intel, purchasers, and security community to deal with it as part of routine work in improving security. As usual, the mainstream security community just ignored everything they said when they bumped into each other. It's not like high-security folks stopped trying to tell them about prior successes and problems: http://www.cse.psu.edu/~trj1/papers/ieee-sp-vaxvmm.pdf http://www.cse.psu.edu/~trj1/papers/ieee-sp-vaxvmm.pdf Then, a bright researcher independently discovered the side channels in caches later. They started reacting to that claim. They found some similar issues in other stuff looking narrowly. Now, we have another clever attack that started with a shared resource as would've been identified in the 1992 methodology that got stretched in really creative ways. It was still same root cause they ignored or justified for things like lowest price/performance versus alternatives doing it securely. Or just physical separation of different security domains which highest-security setups stuck with grudgingly. My prediction in one of the Lobsters comments was that piles of comments would happen about this that didn't involve actually solving it (social gratification), more people would similarly write articles boasting their understanding to generate extra rep since talking problems in is rewarded in mainstream INFOSEC more than preventing/solving them, a few mitigations would show up that were narrowly-focused on just this new kind of problem (like happened with caches), they'd still ignore prior work in high-assurance like Kemmerer or Wray's analyses that found similar problems 20+ years before analyzing whole system, they'd mostly ignore the new work on information-flow analysis (some in link below), and we'd at best get some time until the next problem that could've been prevented by 1990's or recent methods since that's how mainstream security industry and culture works. They're right on track since that's about all I saw while in recovery for a week. Endless articles using the buzzwords to their advantage plus people who don't know we could've beaten this in the 1990's because security professionals in industry suppress that knowledge for some reason. That needs to stop. At least they're rediscovering 60's-90's knowledge at an accelerated rate now. Work on Information Flow Security in Hardware https://pastebin.com/ajqxDJ3J https://pastebin.com/ajqxDJ3J