Huge fan of your work; thanks so much for what you've done on this topic, and maintaining a clear website that I can refer back to easily :)
I've been wondering if perhaps there's a "trusting trust" problem where we have 3d-printers that can print circuit-boards (eg CPUs)... and also print 3d-printers. The printer is sort of like a compiler in this case. How do you know it won't produce printers that will produce malicious CPUs? It might not be easy to do "bit-for-bit" comparisons between CPUs to make sure one is safe.
Since trusted compilers on untrusted hardware aren't trustworthy, I had hoped that 3d-printing might eventually allow us to trust our own printed hardware... but it might be turtles all the way down!
> I've been wondering if perhaps there's a "trusting trust" problem where we have 3d-printers that can print circuit-boards (eg CPUs)... and also print 3d-printers.
I can answer that question easily: "Yes, there's a problem :-)". DDC can be used to help, but there are caveats.
This quote is probably especially apt: "Countering this attack may be especially relevant for 3-D printers that can reproduce many of their own parts. An example of such a 3-D printer is the Replicating Rapid-prototyper (RepRap), a machine that can “print” many hardware items including many of the parts required to build a copy of the RepRap [Gaudin2008]. The primary goal of the RepRap project, according to its project website, is to “create and to give away a makes-useful-stuff machine that, among other things, allows its owner [to] cheaply and easily… make another such machine for someone else” [RepRap2009]."
I also note that, "... DDC can be applied to ICs to detect a hardware-based trusting trust attack. However, note that there are some important challenges when applying DDC to ICs..." and there's the additional problem that when you're done, you'll only have verified that specific printer - not a different one. Determining if software is bit-for-bit identical is easy; determining if two pieces of hardware are logically identical is not (in the general case) easy. No two hardware items are perfectly identical, and it's tricky to determine if something is an irrelevant difference or not.
If someone wants to write a follow-on paper focusing on hardware, I'd be delighted to read it :-).
It's worse for trusted hardware than most people think. The framework I came up with predicted a number of attacks including analog and material swapping at fabs. So, that's an initial test. Here the basic risk analysis:
I predicted the A2 paper on analog compromise happening, at a high-level rather than specific attack, largely due to our hardware guru on Schneier's blog bragging about mixed-signal attacks years ago. He taught us they resisted attempts to counterfeit or patent sue them by disguising key functions in analog or RF components the digital tools couldn't even see. He said competitors did, too, with him regularly having to carefully inspect lowest-level representation of 3rd-party components. I have a feeling they were cloning them, too. ;) Anyway, the actual products were already subverted years ago just for competitive advantage, counterfeiting, etc. He said some counterfeiters were so good they cloned his company's products down to the transistors. I said, "Holy shit!"
One more thing for you while I'm still on this: cost reduction via merged designs. The mask and fab runs for prototyping cost tons of money. A well-known way to reduce that is many companies sharing one run (eg shuttle run or MPW) to get their test chips cheaper. A less-known trick, at least outside embedded, is them putting multiple products on one ASIC to do same thing for production runs with a factory-setting telling it what chip to look like. My hardware guy gave example of 3G or WiFi circuitry embedded in microcontroller used in your input devices... perfect for keylogging... that was only incidentally there since supplier offered both feature-phone SoC's and peripheral chips. And simply didn't want to manufacture two lines. Such extras might be re-enabled, even remotely, depending on how they control access to them. So, gotta watch out for them.
I try to be clear in there that I'm not rebutting your work, which I respect, so much as the extreme amount of focus by all the IT forums on just a few problems that cause almost no failures in real-world vs the ones that cause all sorts of compiler & app issues (including security). I also present an alternative that addresses root causes, leveraging two of your own articles, that knocks out the interception risk as a side effect of just doing the computation and distribution securely.
> I try to be clear in there that I'm not rebutting your work, which I respect, so much as the extreme amount of focus by all the IT forums on just a few problems that cause almost no failures in real-world vs the ones that cause all sorts of compiler & app issues (including security). I also present an alternative that addresses root causes, leveraging two of your own articles, that knocks out the interception risk as a side effect of just doing the computation and distribution securely.
You can see some of my comments below. This discussion is a little subtle, because I agree with you that many other activities need to be done, and you respect my work (thanks!). I don't think there's an "extreme" focus; to my knowledge nearly no money has been spent on DDC, and the amount of funding spent on reproducible builds is dwarfed by the funding spent on formal methods and related work (by orders of magnitude). I think the "focus" that you see is more the excitement about things that can be done now, without radical retooling.
"to my knowledge nearly no money has been spent on DDC, and the amount of funding spent on reproducible builds is dwarfed by the funding spent on formal methods and related work (by orders of magnitude)"
By focus, I mean the IT people out there using, building, discussing, or securing FOSS. They talk a ton about these things but not that other stuff. As you note, there is a lot of work and money going into it by CompSci, proprietary companies (surprise!), and militaries.
What are the implications if we don't start from a trusted compiler?
e.g. we have compilers A and B. Either of which may, or may not, have back doors. Is it possible to detect back doors via compilation?
A complex backdoor can detect compilation of A or B, and insert different backdoor code into each. But will those back doors be identical?
i.e. is there a a compilation path (A -> B' -> B'', etc.) such that we can either detect that the backdoors are either bit for bit identical, or that there are no back doors?
DDC works if the trusted compiler has back doors and other nastiness - as long as the back doors won't affect the DDC results. This is noted in section 4.3: "... something is “trusted” if we have justified confidence that it does not have triggers and payloads that would affect the results of DDC. A trusted program or process may have triggers and payloads, as long as they do not affect the result. A trusted program or process may have defects, though as shown later, any defects that affect its result in DDC are likely to be detected. Methods to increase the level of confidence are discussed in chapter 6." http://www.dwheeler.com/trusting-trust/dissertation/html/whe...
Chapter 6 discusses various ways to make this likely: http://www.dwheeler.com/trusting-trust/dissertation/html/whe... While you're doing tests, it's probably best to do them on an isolated system or network. One interesting appraoch is to use old computers to compile newer compilers (possibly through emulation). It's not likely that the older computers will have malicious attacks or backdoors that will work against newer compilers.
You can also apply it multiple times using multiple different trusted compilers. In that case, an attack would have had to subvert all of those compilers (and/or their environment). This quickly becomes vanishingly unlikely.
"One interesting appraoch is to use old computers to compile newer compilers (possibly through emulation"
I strongly second this. It's what I came up with to deal with hardware, subversion risk post-Patriot Act. The older it is, the better as the oldest stuff predated wireless hardware and had hardware so scarce they didn't waste transistors.
One can also use embedded boards made with MCU's from the old, process nodes. The 8- and 16-bitters will be slow, painful, and maybe not subverted. Alternative, Leon3 GPL CPU on diverse FPGA's. Or my brute-force approach: same compiler on one machine and ISA from each subversive, non-cooperative country comparing output. Lot cheaper to do that now with excellent FOSS support. :)
I've been wondering if perhaps there's a "trusting trust" problem where we have 3d-printers that can print circuit-boards (eg CPUs)... and also print 3d-printers. The printer is sort of like a compiler in this case. How do you know it won't produce printers that will produce malicious CPUs? It might not be easy to do "bit-for-bit" comparisons between CPUs to make sure one is safe.
Since trusted compilers on untrusted hardware aren't trustworthy, I had hoped that 3d-printing might eventually allow us to trust our own printed hardware... but it might be turtles all the way down!