5 ms·

Thanks for this, just added it to my Zotero backlog. I don't see what this has to do with Ken Thompson though. Did he believe that undetectable hardware backdoo

by Cyph0n 10y ago

Thanks for this, just added it to my Zotero backlog. I don't see what this has to do with Ken Thompson though. Did he believe that undetectable hardware backdoors would be possible in the future, or what exactly? I applied for a PhD at UMich this year hoping to work at MICL[1] under Prof. Dennis Sylvester, who co-authored this paper, but I was sadly rejected[2]. MICL is one of the best places in the world to do IC design, and Prof. Sylvester is absolutely amazing. [1]: http://www.eecs.umich.edu/micl/ http://www.eecs.umich.edu/micl/ [2]: I got a funded offer at GA Tech, so it's all good :D

deleted 10y ago
[deleted]
v64 10y ago
Ken Thompson gave a lecture called "Reflections on Trusting Trust" [1] in 1984 that outlines a similar attack. [1] https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
- IshKebab 10y ago
  It's not a similar attack. This doesn't modify future chip designs to include itself, which is what Ken's attack did with code.
  - nickpsecurity 10y ago
    It really isn't. People just love that Thompson paper so much they always bring it up. Whereas I predicted this exact problem repeatedly with people dismissing it. Especially for microcontrollers where there's not much else to modify. And here we have the attack vector proven on a microcontroller. :)
  - EdwardCoffin 10y ago
    His talk used the attack he implemented as an example of a broader family of attacks. In his wrapping-up section (morals) he lists other ways one could embed backdoors into systems, and he noted that the further down you go the harder it is to detect. From Ken Thompson's conclusion: The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.
ghusbands 10y ago
Indeed, the article title, per HN rules, should probably be "A2: Analog Malicious Hardware [pdf]". Maybe with " - undetectable CPU backdoor".
- acqq 10y ago
  > the article title, per HN rules, should probably be "A2: Analog Malicious Hardware [pdf]". Absolutely it should, mods, dang, please fix the title. Moreover, matthewmacleod (1) shows that Thompson didn't predict exactly this level of subversion and anything specific to this method, so the title is even thus inappropriate. 1) https://news.ycombinator.com/item?id=11769190 https://news.ycombinator.com/item?id=11769190
  - Bootvis 10y ago
    Lighten up: "And thirdly, the code is more what you'd call "guidelines" than actual rules." HN actually doesn't even call it rules but Guidelines in the footer.
    - acqq 10y ago
      I don't call them as such too, I just don't like when link poster constructs his own inaccurate or factually wrong interpretation of the material behind the link, and I tend to point to the wrongness of the title only in these situations. I like the "A2: Analog Malicious Hardware" work, but I'm quite sure even Thompson wouldn't claim that what's in the work is exactly what he presented in his talk. His talk is more nuanced and has one much more interesting consequence: that unless you decompile the compiler binary with some very clever tools, just the simple modification in one generation of the compiler can make the following compilers carrying Trojan payload without the payload being visible in the source of the given compiler. "A2: Analog Malicious Hardware" doesn't have this "payload propagation through the generations" property. Very different from what the person who gave the false title here believes. What I claim is that "ltcode" misunderstood the intention of the Thompson's work and therefore the ersatztitle he gave here is very inadequate. Well, at least he didn't create the title that involves Einstein.
- 10y ago
matthewmacleod 10y ago
The Ken Thompson thing is presumably in reference to his popular piece "Reflections on Trusting Trust" (https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...) As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect. And this is even lower - in the hardware itself. Really fascinating work.
heimatau 10y ago
I research as a leisure activity. Thanks for the Zotero mention. It fills a need of mine. I appreciate it!! :)
- Cyph0n 10y ago
  No problem man, awesome to hear it's useful! Be sure to try out Mendeley[1] too as you may find it better. [1]: https://www.mendeley.com/ https://www.mendeley.com/
  - heimatau 10y ago
    It looks like it has potentially some nice social features but...I like the control and that seems to fit Zotero better. Thanks for the suggestions. Pretty neat that there is software that is specific to this field. As I said, it's a hobby of mine but...I do it very regular. Many of my opinions are due to the research I do and this Zotero might be a great tool to say 'hey...I think this...due to these academic articles...' and being able to nicely point them into a specific direction. Thanks again!
nickpsecurity 10y ago
Thompson's work built on and was mostly predated by MULTICS security evaluation that showed subverted compilers and use of hardware failures to boost trapdoors. See bottom two links on my comment here: https://news.ycombinator.com/item?id=11771243 https://news.ycombinator.com/item?id=11771243 Founders of INFOSEC taught us most of what we needed to know. Mainstream security prefers to ignore it, calling it unnecessary, then reinvent it one technique at a time over several decades. Least the OP paper is doing what high-security recommended which is investigating risks at transistor and analog level. Most data on that is trade secret given it's exploited for competitive advantage and intelligence agencies.
- TeMPOraL 10y ago
  > Mainstream security prefers to ignore it, calling it unnecessary, then reinvent it one technique at a time over several decades. That's not just true for security, that's true for the entire software industry.

by Cyph0n 10y ago

deleted 10y ago

[deleted]

v64 10y ago

Ken Thompson gave a lecture called "Reflections on Trusting Trust" [1] in 1984 that outlines a similar attack. [1] https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

IshKebab 10y ago
It's not a similar attack. This doesn't modify future chip designs to include itself, which is what Ken's attack did with code.
- nickpsecurity 10y ago
  It really isn't. People just love that Thompson paper so much they always bring it up. Whereas I predicted this exact problem repeatedly with people dismissing it. Especially for microcontrollers where there's not much else to modify. And here we have the attack vector proven on a microcontroller. :)
- EdwardCoffin 10y ago
  His talk used the attack he implemented as an example of a broader family of attacks. In his wrapping-up section (morals) he lists other ways one could embed backdoors into systems, and he noted that the further down you go the harder it is to detect. From Ken Thompson's conclusion: The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.

ghusbands 10y ago

Indeed, the article title, per HN rules, should probably be "A2: Analog Malicious Hardware [pdf]". Maybe with " - undetectable CPU backdoor".

acqq 10y ago
> the article title, per HN rules, should probably be "A2: Analog Malicious Hardware [pdf]". Absolutely it should, mods, dang, please fix the title. Moreover, matthewmacleod (1) shows that Thompson didn't predict exactly this level of subversion and anything specific to this method, so the title is even thus inappropriate. 1) https://news.ycombinator.com/item?id=11769190 https://news.ycombinator.com/item?id=11769190
- Bootvis 10y ago
  Lighten up: "And thirdly, the code is more what you'd call "guidelines" than actual rules." HN actually doesn't even call it rules but Guidelines in the footer.
  - acqq 10y ago
    I don't call them as such too, I just don't like when link poster constructs his own inaccurate or factually wrong interpretation of the material behind the link, and I tend to point to the wrongness of the title only in these situations. I like the "A2: Analog Malicious Hardware" work, but I'm quite sure even Thompson wouldn't claim that what's in the work is exactly what he presented in his talk. His talk is more nuanced and has one much more interesting consequence: that unless you decompile the compiler binary with some very clever tools, just the simple modification in one generation of the compiler can make the following compilers carrying Trojan payload without the payload being visible in the source of the given compiler. "A2: Analog Malicious Hardware" doesn't have this "payload propagation through the generations" property. Very different from what the person who gave the false title here believes. What I claim is that "ltcode" misunderstood the intention of the Thompson's work and therefore the ersatztitle he gave here is very inadequate. Well, at least he didn't create the title that involves Einstein.
10y ago

matthewmacleod 10y ago

The Ken Thompson thing is presumably in reference to his popular piece "Reflections on Trusting Trust" (https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...) As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect. And this is even lower - in the hardware itself. Really fascinating work.

heimatau 10y ago

I research as a leisure activity. Thanks for the Zotero mention. It fills a need of mine. I appreciate it!! :)

Cyph0n 10y ago
No problem man, awesome to hear it's useful! Be sure to try out Mendeley[1] too as you may find it better. [1]: https://www.mendeley.com/ https://www.mendeley.com/
- heimatau 10y ago
  It looks like it has potentially some nice social features but...I like the control and that seems to fit Zotero better. Thanks for the suggestions. Pretty neat that there is software that is specific to this field. As I said, it's a hobby of mine but...I do it very regular. Many of my opinions are due to the research I do and this Zotero might be a great tool to say 'hey...I think this...due to these academic articles...' and being able to nicely point them into a specific direction. Thanks again!

nickpsecurity 10y ago

Thompson's work built on and was mostly predated by MULTICS security evaluation that showed subverted compilers and use of hardware failures to boost trapdoors. See bottom two links on my comment here: https://news.ycombinator.com/item?id=11771243 https://news.ycombinator.com/item?id=11771243 Founders of INFOSEC taught us most of what we needed to know. Mainstream security prefers to ignore it, calling it unnecessary, then reinvent it one technique at a time over several decades. Least the OP paper is doing what high-security recommended which is investigating risks at transistor and analog level. Most data on that is trade secret given it's exploited for competitive advantage and intelligence agencies.

TeMPOraL 10y ago
> Mainstream security prefers to ignore it, calling it unnecessary, then reinvent it one technique at a time over several decades. That's not just true for security, that's true for the entire software industry.