[nfoz]

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!

[dwheeler]

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

I talk about applying DDC to hardware in section 8.12: http://www.dwheeler.com/trusting-trust/dissertation/html/whe...

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

[nickpsecurity]

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:

https://news.ycombinator.com/item?id=10468624

The smartphone analysis I did also has general stuff in it:

https://news.ycombinator.com/item?id=10906999

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.