Comment by moring | Hacker News Reader

Comment by moring | Hacker News Reader

Parent Full thread

> 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!)

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!)

Isn't a sectorlisp running on a microcontroller a more straightforward solution? Detecting and modifying a sectorlisp on the fly would require something like a frontier LLM with latency on the order of fractions of a second.

Reply on news.ycombinator.com