The more I think about it, the more I think that bootstrapping the build isn't actually the huge problem it first seemed to be. There are practical problems to solve, but they CAN be solved.

In contrast, how can you make sure that the actual payload code hasn't been tampered with? It is written in a high-level language, but it gets stored and viewed on devices that have backdoors in their CPU microcode and huge OSes that can hide god knows what. The author can sign the code, but that doesn't tell anything other than it was really the author who signed it and the code hasn't been modified afterwards -- if the author's system was compromised, the code can contain backdoors before being signed. So you need to validate the (signed or not) code to be correct, but you're doing so on an untrusted system. It goes on and on.

You'd probably need the code to be verified, then signed, by a trusted party on a trusted system. THAT signature then means the payload hasn't been tampered with, and can be trusted after it gets built on your trusted system (and this is where the bootstrap problem happens, and gets solved).

All this is obviously still glossing over the problem how to obtain hardware you can trust.

...edit: But if you have all that, then you don't need a complex bootstrapping anymore. A trusted actor can verify, or even build, a trusted system by hand on trusted hardware, sign it, and then you can use that (binary!) as long as you run it on your own trusted hardware and verify the signature first.

The bootstrapping then becomes a tool to ensure reproducibility, but is no longer needed for trust.

▲

tux3 20 hours ago | parent [-]

>as long as you run it on your own trusted hardware and verify the signature first.

I think that depends how far you want to take the paranoia. In principle if you want that to be a secure signature that can't be forged, you're back to needing both hardware and software you trust to verify the signature. Hashing a large binary and verifying a signature on paper is wildly impractical.

If someone prints the code and claims they verified it, you could trust them. But if they give you a signed archive that you download and verify on your computer, you're back to square one. You would have to know your software and hardware isn't already backdoored, just to verify that the software you received isn't backdoored.

>A trusted actor can verify, or even build, a trusted system by hand on trusted hardware, sign it, and then you can use that (binary!) as long as you run it on your own trusted hardware and verify the signature first.

Your own trusted hardware AND software, because you're not going to be verifying that signature by hand, and you're not going to load the binary file in memory by hand, so either a kernel or system software (like UEFI) will be handling your trusted binary first.

But then you're back to needing a clean bootstrap again. Which is why the chain starts with a hex0 that you can type manually, not with a large signed binary that would require either an already trusted system, or cryptography that's realistically not possible to do by hand.

▲

moring 17 hours ago | parent [-]

> because you're not going to be verifying that signature by hand

At least verifying a signature is something that does not need complex hardware, so chances are that your trusted hardware can do that.

> Your own trusted hardware AND software, because you're not going to be verifying that signature by hand, and you're not going to load the binary file in memory by hand, so either a kernel or system software (like UEFI) will be handling your trusted binary first. > > But then you're back to needing a clean bootstrap again. (...)

But having solved that bootstrapping problem, you are likewise back to square one with trusting "the payload", only this time the payload isn't the actual payload but the OS kernel, UEFI or whatever that obtains and verifies the actual payload.

You have that OS kernel or UEFI as source code, but you don't know if the source code contains a backdoor unless you either verify it manually, or have it verified and signed in some way by a third party you trust, and there the whole signature thing comes back.

(BTW thanks for the discussion. I'm really enjoying this!)

	▲	tux3 9 hours ago \| parent [-]
		I was thinking an FPGA with an open toolchain might make a pretty solid hardware seed that can fairly easily be replicated, without needing your own fab or anything completely impractical. In theory the FPGA could still try to recognize and backdoor a bitstream right when you load it, but practically there's a whole bunch of different open-source cores that you could load on the FPGA, and it would be very hard to try to recognize and backdoor all those potential designs at the netlist level, or at least it would take a suspiciously large area, potentially visible as clearly more complicated than what should be needed on a microscope. You could maybe distribute these verified boards that are just the FPGA and the verified CPU core + kernel + software seeds all stored on a basic NAND flash. But then instead of writing a lisp interpreter in machine code as your seed.. the seed would have to be an entire basic CPU that runs something like hex0, or like a basic lisp machine. You'd plug a keyboard into it and bootstrap the rest from there. But good luck with that, I'm not volunteering to try to make all of that work! Plus there's still a small chance of a hardware backdoor somehow powerful enough to recognize any possible core you can load on it, or that the tools you use to even load a NAND flash or the NAND flash itself could be backdoored, so really we're just displacing the problem a bit further every time. But if you want to bootstrap everything from nothing, then you basically have to jumpstart all of computing electronics back up from nothing. (And yeah, this is fun to think about!)