4 ms·

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 bui

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 10y ago
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 10y ago
The read-only copy could be different from the running copy.
- rcthompson 10y ago
  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 10y ago
    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 10y ago
      > 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 10y ago
        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 10y ago
  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.

qrmn 10y ago

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 10y ago

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

rcthompson 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      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 10y ago
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.