Reflections on Trusting Trust (1984) [pdf]
ece.cmu.edu
ece.cmu.edu
If you read that, you should also take a look at my PhD dissertation which discusses how to counter it. It's "Fully Countering Trusting Trust Through Diverse Double-Compiling" (2009), available at: https://www.dwheeler.com/trusting-trust . It was discussed on Hacker News in 2016; here's the link: https://news.ycombinator.com/item?id=12666923
Another related work is the reproducible builds work; a good link is here: https://reproducible-builds.org/
https://www.acsac.org/2002/papers/classic-multics.pdf
Paul helped invent much of INFOSEC from scratch with lots of his lessons rediscovered over time by mainstream INFOSEC that largely ignores predecessors' work. Here's Paul's other stuff for any interested:
https://www.semanticscholar.org/author/Paul-A-Karger/2467751
Back to this topic, the definitive solution is high-assurance compiler combined with SCM techniques presented best by David Wheeler:
Oh, and thanks for the citation about my paper on SCM security!
"Oh, and thanks for the citation about my paper on SCM security!"
You earned it. :) One thing I am still curious about was who originated the high-security techniques for SCM. Back in Karger's day, they just put it in safes on paper. Im wondering who did fundamental stuff on making it electronic and secure, though. Figure it's in your collection but asking in case you know off hand.
I've had trouble finding some of the earlier work on high-security SCM; I do reference what I found. If you find something important I'm missing, send me an email: https://www.dwheeler.com/contactme.html
http://www.dtic.mil/dtic/tr/fulltext/u2/650214.pdf
https://www.computer.org/csdl/proceedings/afips/1967/5069/00...
First is a retrospect on original document. It referenced accounting procedures for the artifacts. Makes sense they'd look at it from accounting standpoint as that's what they did with other things. Ware Report did that, too, for early INFOSEC. Lacking details from manual, I found a follow-up in 1967 that describes key details on p4 under procedural data esp concerning changes. Sounds like an early form of SCM security. I'll have to try to find the computerized one later on as I have a feeling it independently happened in mainframes or minicomputers outside INFOSEC field.
Btw, your link to Zeigenhagen was dead when I tried it. DTIC to the rescue:
Here's the quote from "Thirty Years Later: Lessons from the Multics Security Evaluation": "This suggestion proved an inspiration to Ken Thompson who actually implemented the self-inserting compiler trap door into an early version of UNIX. Thompson described his trap door in his 1984 Turing Award paper [40], and attributed the idea to an “unknown Air Force document,” and he asked for a better citation. The document in question is in fact the Multics Security Evaluation report, and we gave a new copy of the report to Thompson after his paper was published. Thompson has corrected his citation in a reprint of the paper [39]."
One more on Thompson. What got me suspicious about him was he had a famous work before that was also done by someone else. The other was much of the C language: its bare-metal nature, few keywords, and so-called "C philosophy" of programmer is in control. The original publications that got acclaim didn't cite the BCPL author, Martin Richards, at all despite him inventing and implementing all those concepts. They were in fact the BCPL philosophy originally with same semantics. Instead, just cited the B language like they did it all on their own in isolation with history crediting the victor that way. Publications that came a while after that started referencing BCPL.
Got that from the talk below which is great for tracing history of C from CPL project to BCPL to C to C++ influence.
Really gives the big picture why Martin and others would do such languages with the constraints they were operating in. For this discussion, Martin Richards lays foundation for C-like languages with all key features and philosophy of C at 19:40 mark. Illustration of potential plagarism of C from Richards' work at 23:17-27:30. Looks a lot like cases of plagarism I've seen in academia but curious of your opinion as you're much more experienced in academic field. Would you think it was plagarism if you came across both works simultaneously seeing the one that came later without references was making waves?
Yet, the world still turns, absent some terrible exceptions. It's almost as if no system is truly safe and secure, which I think cultures have known since the ages.
For hardware, you start with simplified CPU like a Forth or ZPU processor. One you can check by hand and eye on an older process node. Reverify it with itself. Then run above step for software on it. Optionally better EDA tools, too.
The diversity method ports the simple interpreter or compiler to a number of CPU architectures or dev tools. Pick whichever you want. If you aim for same binary, you'll need compiler designed to do that or reproducible builds like Wheeler links to up thread.
It's a question of priorities rather than feasibility. Most users or customers dont care enough to invest time or effort needed. End of story. Same one as usual for strong INFOSEC.
I'll also add that there already exists certifying compilers for C and Standard ML that both extract to ML. The ML extracted is simple enough to hand-compile to ASM following one of two guides. So, not only can oma human verify no subversion, there's already a production one with machine-checked proof that's also be checked by humans [again].