3 ms·

How could it be addressed given this, "the manner of data entry and the manner of "easily checking" can be compromised"? That is the reflection upon trusting t

by IncRnd 5y ago

How could it be addressed given this, "the manner of data entry and the manner of "easily checking" can be compromised"? That is the reflection upon trusting trust.

marcodiego 5y ago
I can't see where It fails... let's check... 1 - Somebody writes a very simple assembler that can be easily checked. 2 - I type-in that assembler from hex using specialized hardware for that purpose. What is typed is exactly what is turned into data unless hardware is compromised. 3 - From that assembler, I type-in a more advanced assembler that was checked by hand from more people and whose hash was hand-calculated. After that, I check its hash. Software on my machine can only be compromised if the people who wrote this more advanced assembler are compromised, I also check the hash to guarantee it was typed exactly. 5 - From this more advanced assembler I type-in the source code of a compiler or interpreter which was checked by more people and its hash was hand calculated. Same as before with regard to chances of being compromised. 6 - I can then bootstrap more advanced software whose source code I trust and I can check the source code was not tampered with with hashes. What step fails?
- IncRnd 5y ago
  > What step fails? I already wrote it out twice, and manquer provided a link to the paper (which is also linked from your page, https://bootstrappable.org/ https://bootstrappable.org/) called Reflections on Trusting Trust. This is not a supply chain issue but a trust issue. This is the very reason Thompson's paper was called, Reflections on Trusting Trust. If you still cannot see this, look at PKI and ask where trust can be broken.
  - marcodiego 5y ago
    AFAIK, Reflections on trust supposes a compromised compiler. I do not see how a compiler whose source code is compromised can be compiled with the described steps. At least its hash would not match.
    - IncRnd 5y ago
      That's not the case. From Reflections: MORAL 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.
      - marcodiego 5y ago
        That is the point: trust can be reduced to hardware (considering microcode as hardware). Which is much better than hardware and packagers and tools used by packagers.
- haberman 5y ago
  From step 2 to 3 you need some combination of hardware and software that you trust to take the bytes you typed in, run them exactly as you typed them, passing input and output between your program and a data store without modifying them. This involves the basic parts of an OS: filesystem, program loader, whatever you're using to calculate the hash, etc; you have to trust those too. You also have to trust the CPU to run your program exactly as it appears in memory.
  - marcodiego 5y ago
    > This involves the basic parts of an OS: filesystem, program loader, whatever you're using to calculate the hash, etc; you have to trust those too. No. This can be done with a ROM programmer. Trust is now reduced to hardware and people who checked the software. Assuming many people can check it, it can be considered safe. As I said, trust now depends on hardware and many people being compromised. Trusting software is no longer needed. Type-in a bootloader is how it was done on old PDPs [0] and on the altair. I can't see how those bootloaders could be compromised except if the hardware was compromised too. [0] https://www.youtube.com/watch?v=M94p5EIC9vQ https://www.youtube.com/watch?v=M94p5EIC9vQ
    - haberman 5y ago
      I don't think I'm understanding your threat model. It feels like you are waving away the trust chain required to obtain and execute trusted ROM programmer software. How can you verify that the software you are running is the same as the software that others checked? But suppose I grant that the ROM programmer software is trusted. I still don't see how that sidesteps the problem of needing to trust the OS environment. Once your assembler is running, how will it get its input and write its output? How will you obtain the output of the the assembler and run it in a subsequent step? How will that subsequent program get its input and write its output?
      - marcodiego 5y ago
        > It feels like you are waving away the trust chain required to obtain and execute trusted ROM programmer software. Take a look on the video I posted. There, the memory is programmed bit-by-bit. Fully through hardware, directly on the memory, the processor is not used when the ROM is programmed. In other words: the ROM programmer is 100% hardware. There is no ROM programmer software. > How can you verify that the software you are running is the same as the software that others checked? The ROM programmer can read any cell of the memory and display it. It can be checked visually if wanted or required. Other hardware features can be implemented for this specific feature, but I don't think that is required. The hardware still can be compromised, but such a simple hardware would need a very complicated way to be compromised and hide it from the user. For chips that don't need fast clocks, I think, it can even be built using only resistors and capacitors. I once built a programmer (for RAM chips) myself using an arduino and resistors. It is reasonably safe to assume that the arduino was not carefully compromised to circumvent this very specific use case. > But suppose I grant that the ROM programmer software is trusted. There is no ROM programmer software! > I still don't see how that sidesteps the problem of needing to trust the OS environment. There is no OS until that point! Everything to that point will run on bare metal. See the link to stage0 I posted: "The stage0 is the ultimate lowest level of bootstrap that is useful for systems without firmware, operating systems nor any other provided software functionality" > Once your assembler is running, how will it get its input and write its output? Directly from hardware. > How will you obtain the output of the the assembler and run it in a subsequent step? Directly from hardware. The output of the assembler can go directly to RAM. Running it is just a matter of jumping to its entry point. > How will that subsequent program get its input and write its output? These can come from trusted libs or a trusted kernel which I compiled with a trusted compiler on my trusted system. AFAICS, until that point every software running on such system can be said to be trusted if at least one person who checked such software is trusted. If the software is checked by many people it is a reasonable assumption. Vulnerabilities can still exist, but those are another kind of problem, they are bugs which may be discovered and fixed later but not built into the system by the tools. Cases like intentional vulnerabilities can still exist but would have to pass all the checkers, human or automated. Look, the system now can only be compromised if people who checked the software are compromised or the hardware is compromised. Before mes and stage0, I had to trust the people who checked the software and the system (hardware and software) were software I run was built. If the compiler was compromised, all software generated from it could be compromised. To illustrate it, suppose I trust GCC code as published by FSF. This is an entirely reasonable assumption. Now, if I use GCC compiled from my distro repositories, I'm trusting not only the packagers, but I'm also trusting the tools these packagers used. With stage0 and mes I don't need to trust any pre-existing binary tool that I can't check myself or be checked by other people or static analyzers. An entire huge chain would have to be compromised for my software to be compromised. Reasonably, the system can only be compromised if hardware is compromised or all the people and tools which checked the code are compromised. Considering many people can check the code and vulnerabilities are hard to hide in the source code of a compiler, assuming not all of the people who checked the code are compromised is reasonable. Trust is now reduced to hardware only. Without boostrapable, I had to trust the software tools that were used to build the software I use.

by IncRnd 5y ago

How could it be addressed given this, "the manner of data entry and the manner of "easily checking" can be compromised"? That is the reflection upon trusting trust.

marcodiego 5y ago

I can't see where It fails... let's check... 1 - Somebody writes a very simple assembler that can be easily checked. 2 - I type-in that assembler from hex using specialized hardware for that purpose. What is typed is exactly what is turned into data unless hardware is compromised. 3 - From that assembler, I type-in a more advanced assembler that was checked by hand from more people and whose hash was hand-calculated. After that, I check its hash. Software on my machine can only be compromised if the people who wrote this more advanced assembler are compromised, I also check the hash to guarantee it was typed exactly. 5 - From this more advanced assembler I type-in the source code of a compiler or interpreter which was checked by more people and its hash was hand calculated. Same as before with regard to chances of being compromised. 6 - I can then bootstrap more advanced software whose source code I trust and I can check the source code was not tampered with with hashes. What step fails?

IncRnd 5y ago
> What step fails? I already wrote it out twice, and manquer provided a link to the paper (which is also linked from your page, https://bootstrappable.org/ https://bootstrappable.org/) called Reflections on Trusting Trust. This is not a supply chain issue but a trust issue. This is the very reason Thompson's paper was called, Reflections on Trusting Trust. If you still cannot see this, look at PKI and ask where trust can be broken.
- marcodiego 5y ago
  AFAIK, Reflections on trust supposes a compromised compiler. I do not see how a compiler whose source code is compromised can be compiled with the described steps. At least its hash would not match.
  - IncRnd 5y ago
    That's not the case. From Reflections: MORAL 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.
    - marcodiego 5y ago
      That is the point: trust can be reduced to hardware (considering microcode as hardware). Which is much better than hardware and packagers and tools used by packagers.
haberman 5y ago
From step 2 to 3 you need some combination of hardware and software that you trust to take the bytes you typed in, run them exactly as you typed them, passing input and output between your program and a data store without modifying them. This involves the basic parts of an OS: filesystem, program loader, whatever you're using to calculate the hash, etc; you have to trust those too. You also have to trust the CPU to run your program exactly as it appears in memory.
- marcodiego 5y ago
  > This involves the basic parts of an OS: filesystem, program loader, whatever you're using to calculate the hash, etc; you have to trust those too. No. This can be done with a ROM programmer. Trust is now reduced to hardware and people who checked the software. Assuming many people can check it, it can be considered safe. As I said, trust now depends on hardware and many people being compromised. Trusting software is no longer needed. Type-in a bootloader is how it was done on old PDPs [0] and on the altair. I can't see how those bootloaders could be compromised except if the hardware was compromised too. [0] https://www.youtube.com/watch?v=M94p5EIC9vQ https://www.youtube.com/watch?v=M94p5EIC9vQ
  - haberman 5y ago
    I don't think I'm understanding your threat model. It feels like you are waving away the trust chain required to obtain and execute trusted ROM programmer software. How can you verify that the software you are running is the same as the software that others checked? But suppose I grant that the ROM programmer software is trusted. I still don't see how that sidesteps the problem of needing to trust the OS environment. Once your assembler is running, how will it get its input and write its output? How will you obtain the output of the the assembler and run it in a subsequent step? How will that subsequent program get its input and write its output?
    - marcodiego 5y ago
      > It feels like you are waving away the trust chain required to obtain and execute trusted ROM programmer software. Take a look on the video I posted. There, the memory is programmed bit-by-bit. Fully through hardware, directly on the memory, the processor is not used when the ROM is programmed. In other words: the ROM programmer is 100% hardware. There is no ROM programmer software. > How can you verify that the software you are running is the same as the software that others checked? The ROM programmer can read any cell of the memory and display it. It can be checked visually if wanted or required. Other hardware features can be implemented for this specific feature, but I don't think that is required. The hardware still can be compromised, but such a simple hardware would need a very complicated way to be compromised and hide it from the user. For chips that don't need fast clocks, I think, it can even be built using only resistors and capacitors. I once built a programmer (for RAM chips) myself using an arduino and resistors. It is reasonably safe to assume that the arduino was not carefully compromised to circumvent this very specific use case. > But suppose I grant that the ROM programmer software is trusted. There is no ROM programmer software! > I still don't see how that sidesteps the problem of needing to trust the OS environment. There is no OS until that point! Everything to that point will run on bare metal. See the link to stage0 I posted: "The stage0 is the ultimate lowest level of bootstrap that is useful for systems without firmware, operating systems nor any other provided software functionality" > Once your assembler is running, how will it get its input and write its output? Directly from hardware. > How will you obtain the output of the the assembler and run it in a subsequent step? Directly from hardware. The output of the assembler can go directly to RAM. Running it is just a matter of jumping to its entry point. > How will that subsequent program get its input and write its output? These can come from trusted libs or a trusted kernel which I compiled with a trusted compiler on my trusted system. AFAICS, until that point every software running on such system can be said to be trusted if at least one person who checked such software is trusted. If the software is checked by many people it is a reasonable assumption. Vulnerabilities can still exist, but those are another kind of problem, they are bugs which may be discovered and fixed later but not built into the system by the tools. Cases like intentional vulnerabilities can still exist but would have to pass all the checkers, human or automated. Look, the system now can only be compromised if people who checked the software are compromised or the hardware is compromised. Before mes and stage0, I had to trust the people who checked the software and the system (hardware and software) were software I run was built. If the compiler was compromised, all software generated from it could be compromised. To illustrate it, suppose I trust GCC code as published by FSF. This is an entirely reasonable assumption. Now, if I use GCC compiled from my distro repositories, I'm trusting not only the packagers, but I'm also trusting the tools these packagers used. With stage0 and mes I don't need to trust any pre-existing binary tool that I can't check myself or be checked by other people or static analyzers. An entire huge chain would have to be compromised for my software to be compromised. Reasonably, the system can only be compromised if hardware is compromised or all the people and tools which checked the code are compromised. Considering many people can check the code and vulnerabilities are hard to hide in the source code of a compiler, assuming not all of the people who checked the code are compromised is reasonable. Trust is now reduced to hardware only. Without boostrapable, I had to trust the software tools that were used to build the software I use.