3 ms·
That is not doable, given the threat discussed in the mentioned paper, since the manner of data entry and the manner of "easily checking" can be compromised. I
by IncRnd 5y ago
That is not doable, given the threat discussed in the mentioned paper, since the manner of data entry and the manner of "easily checking" can be compromised.
If you are hand typing an assembler in order to bootstrap a more complicated assembler, which creates a compiler or interpreter to check a single hash value, you are engaging in the wrong mitigation. You should instead use an airgapped computer with different software.
- marcodiego 5y agoAFAIK, the bootstrapable project specifically addresses the reflections on trusting trust problem.
- IncRnd 5y agoHow 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 agoI 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 agoAFAIK, 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 agoThat'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 agoThat 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 agoFrom 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.