Hacker News Reader

Comment by Cyph0n | Hacker News Reader

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/

[2]: I got a funded offer at GA Tech, so it's all good :D

View on HN

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-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.

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

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.

> 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.

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-thomp...

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.

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. :)

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.

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

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/

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!

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

> 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

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.

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.

This isn't (just) a CPU backdoor though, it's a possible backdoor on any integrated circuit.

I am trying to understand the parsing of CPU/integrated circuit you are doing but I am not following. How are you conceptualizing the CPU as different than an integrated circuit?

It's a pars pro toto: a CPU is an example of an integrated circuit, but there are integrated circuits that are not CPUs.

To make this distinction more relevant: this kind of attack would be very useful in the context of EEPROMs or cryptographic chips (like TPMs): you could, for example, induce a cryptographic chip to dump its internal state (private keys), or you could overwrite a flash region that would under normal operation be non-writable.

thank you for the clarification.

To be precise, what was implemented was a CPU backdoor, but the attack applies to all integrated circuits.

Ah, I get the confusion. I've added "just" to my earlier comment.

Yes. We've changed it from "Ken Thompson was right, proven definitively 32 years later".

Submitters: it's against HN's rules to rewrite titles like that. It's only ok to do so if they're misleading or linkbait to begin with (and definitely not to make them more so).

https://news.ycombinator.com/newsguidelines.html

Can you add a (pdf) too, please?

Ah yes, missed that earlier. Added now.

Reply on news.ycombinator.com