3 ms·

I still don't understand in what scenario someone could trust their vendor's hardware but not firmware. Somehow the firmware is malicious but the hardware is tr

I still don't understand in what scenario someone could trust their vendor's hardware but not firmware. Somehow the firmware is malicious but the hardware is trusted? Why/how? Either you're getting the product directly from a vendor you trust, or you're not. If you are, then the firmware and the hardware are one thing together. If you're not, you need your own fab. And mind you, whoever is supposedly intercepting your shipments (or whatever) doesn't need a fab to pull off any attack, so I'm not sure what the scope reduction is here...

solarengineer 5y ago
https://www.extremetech.com/computing/173721-the-nsa-regularly-intercepts-laptop-shipments-to-implant-malware-report-says https://www.extremetech.com/computing/173721-the-nsa-regular... https://puri.sm/products/librem-key/ https://puri.sm/products/librem-key/ Interception and firmware replacement is a thing. It happens. One could thus trust the hardware but not the firmware.
- dataflow 5y ago
  Yes I remember it from the Snowden days, that's why I mentioned it myself. But I don't get the threat model. So supposedly the NSA planted something in your device's firmware. How exactly would it help you if you could "see" the manufacturer's firmware (say it was open-source)? You still wouldn't know what's running on the chip. Even if you flash it, the chip could just be lying in some part of the process. Conversely, the entire firmware could be encrypted and you could still verify it (without knowing what it's doing) if the chip had an un-tamperable-with "dump out a hash of my firmware" instruction to let you match against the manufacturer's provided hash. Or an instruction to verify that its hash is what you expect in a manner that can't be tampered with. Either way, I don't see how your knowledge of the firmware that's supposed to be on it is necessary or sufficient.
  - solarengineer 5y ago
    At the minimum, I'd want to be aware that the firmware is not what the manufacturer had intended to provide me. Perhaps it's not the NSA after me, but some other actor or competitor or ransomware agency.
    - dataflow 5y ago
      Yeah and to do that you need some mechanism to check what's on the device. It wouldn't help you to have 'open' firmware since it still wouldn't tell you what's on the device.
      - solarengineer 5y ago
        I hadn’t presumed that the firmware needed to be Open, though. Just a mechanism to verify. Being open and having the ability to compile from source and installing it myself would be even better.
eru 5y ago
Keep in mind that in the 'Trusting Trust' example, the compiler has to be smart enough to realize that you are building another compiler (and only then insert the backdoor). I can imagine that a back-doored GCC would recognize when you are building another GCC, but it would be hard for an old version of GCC to recognize eg a modern LLVM or even GHC, I'd say. Similar, the lower down you go, the harder it is to put that kinds of smarts in. That might be one reason to stop at this point? (Not sure.)
rkagerer 5y ago
I've found software (ie. firmware) tends to be more sloppily constructed, probably because it can be fixed later in the field.

solarengineer 5y ago

https://www.extremetech.com/computing/173721-the-nsa-regularly-intercepts-laptop-shipments-to-implant-malware-report-says https://www.extremetech.com/computing/173721-the-nsa-regular... https://puri.sm/products/librem-key/ https://puri.sm/products/librem-key/ Interception and firmware replacement is a thing. It happens. One could thus trust the hardware but not the firmware.

dataflow 5y ago
Yes I remember it from the Snowden days, that's why I mentioned it myself. But I don't get the threat model. So supposedly the NSA planted something in your device's firmware. How exactly would it help you if you could "see" the manufacturer's firmware (say it was open-source)? You still wouldn't know what's running on the chip. Even if you flash it, the chip could just be lying in some part of the process. Conversely, the entire firmware could be encrypted and you could still verify it (without knowing what it's doing) if the chip had an un-tamperable-with "dump out a hash of my firmware" instruction to let you match against the manufacturer's provided hash. Or an instruction to verify that its hash is what you expect in a manner that can't be tampered with. Either way, I don't see how your knowledge of the firmware that's supposed to be on it is necessary or sufficient.
- solarengineer 5y ago
  At the minimum, I'd want to be aware that the firmware is not what the manufacturer had intended to provide me. Perhaps it's not the NSA after me, but some other actor or competitor or ransomware agency.
  - dataflow 5y ago
    Yeah and to do that you need some mechanism to check what's on the device. It wouldn't help you to have 'open' firmware since it still wouldn't tell you what's on the device.
    - solarengineer 5y ago
      I hadn’t presumed that the firmware needed to be Open, though. Just a mechanism to verify. Being open and having the ability to compile from source and installing it myself would be even better.

eru 5y ago

Keep in mind that in the 'Trusting Trust' example, the compiler has to be smart enough to realize that you are building another compiler (and only then insert the backdoor). I can imagine that a back-doored GCC would recognize when you are building another GCC, but it would be hard for an old version of GCC to recognize eg a modern LLVM or even GHC, I'd say. Similar, the lower down you go, the harder it is to put that kinds of smarts in. That might be one reason to stop at this point? (Not sure.)

rkagerer 5y ago

I've found software (ie. firmware) tends to be more sloppily constructed, probably because it can be fixed later in the field.