3 ms·

I'm the author. Ask me anything about it.

adekok 10y ago
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?
- dwheeler 10y ago
  Awesome question, and there's a sneaky answer. 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/wheeler-trusting-trust-ddc.html#4.3.Informal%20assumptions 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/wheeler-trusting-trust-ddc.html#6.Methods%20to%20increase%20diversity 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.
  - nickpsecurity 10y ago
    "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. I made a list for people here: https://www.schneier.com/blog/archives/2013/09/surreptitiously.html#c1762647 https://www.schneier.com/blog/archives/2013/09/surreptitious... 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. :)
nfoz 10y ago
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 10y ago
  > 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/wheeler-trusting-trust-ddc.html#8.12.Hardware 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 10y ago
What do you say to my rebuttal of the trend to focus on this stuff as stated below? https://news.ycombinator.com/item?id=12667632 https://news.ycombinator.com/item?id=12667632 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.
- dwheeler 10y ago
  > 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.
  - nickpsecurity 10y ago
    "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?

dwheeler 10y ago
Awesome question, and there's a sneaky answer. 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/wheeler-trusting-trust-ddc.html#4.3.Informal%20assumptions 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/wheeler-trusting-trust-ddc.html#6.Methods%20to%20increase%20diversity 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.
- nickpsecurity 10y ago
  "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. I made a list for people here: https://www.schneier.com/blog/archives/2013/09/surreptitiously.html#c1762647 https://www.schneier.com/blog/archives/2013/09/surreptitious... 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. :)

nfoz 10y ago

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 10y ago
> 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/wheeler-trusting-trust-ddc.html#8.12.Hardware 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 10y ago

What do you say to my rebuttal of the trend to focus on this stuff as stated below? https://news.ycombinator.com/item?id=12667632 https://news.ycombinator.com/item?id=12667632 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.

dwheeler 10y ago
> 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.
- nickpsecurity 10y ago
  "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.