[rcthompson]

Couldn't a hardware vendor theoretically provide read-only access to the firmware and then have an open-source reproducible build process so that anyone can build their own copy of the firmware and verify that the firmware on the device is bit-for-bit identical? Wouldn't that satisfy people who want to be sure of what code is running on their device while still preventing an attacker from loading custom firmware?

[qrmn]

Absolutely. I built a concept that essentially did that.

Separated program and data memory with only one executable. USB host would get (in hardware) an outright memory dump of the program memory on connection, so it could hash it/compare it to known-good firmware. If you flashed the firmware the data memory should get wiped, and if you flashed it with anything the driver didn't know as a good build, unless you manually whitelisted it, you'd be warned.

That seems like a better approach to me. (It turns out I really suck at designing hardware, let alone secure hardware.)

Doing the same kind of general thing with, say, a RISC-V microcontroller and trying to secure the RAM seems like a generally fruitful possible course of action? Let's see how Lowrisc turns out.

[vbernat]

The read-only copy could be different from the running copy.

[rcthompson]

If you trust the hardware enough to use it for 2-factor authentication, then I think you trust it enough to be honest with you about its contents.

[dfox]

The problem there is that in usual case, the read-only access to software will not be provided directly by the hardware, but by the same software you are trying to verify.

In theory, this could be solved by verifying whole memory of the device, but that still depend on you believing that the device does not have more memory than what it should have.

[leni536]

> the read-only access to software will not be provided directly by the hardware, but by the same software you are trying to verify. Why not?

[dfox]

Because in the usual case you want to do such verification through same interface as normal operation, both for usability reasons and to limit number of interfaces that cross the security boundary.

[makomk]

The usual trick is to ensure that the firmware + user data fills all available storage space on the hardware so there's no room for other code, then add time limits and complexity to the verification code so they can't do any tricks with stuff like compression.