3 ms·

I don't understand why people stop their trust analysis at flashable firmware. Somehow people can't trust their hardware's firmware, but they can blindly trust

I don't understand why people stop their trust analysis at flashable firmware. Somehow people can't trust their hardware's firmware, but they can blindly trust the hardware itself? Why? Would you even be able to tell if the hardware had firmware in it you didn't know about, let alone the fact that the hardware itself could be malicious? This is why the whole thing seems like an exercise in futility to me. Just trust a reasonable base (e.g., including the OS) and call it a day. If you can't even trust your vendor to give you trustworthy firmware then find some way to invest $N Billion into your own fabrication labs to make your own chips in front of your face.

dave_universetf 5y ago
I did go that far down, and there is a purpose. Reducing the scope of attack to "you must own a fab" is pretty great, honestly. Sure, it won't stop a perfectly placed nation-state from mounting a bespoke attack just for you by twiddling silicon doping on a wafer... But that's quite a bit harder and more expensive than "install an SMM rootkit". And, if you do care about trustable hardware... There are bootstrapping and verification paths available there as well, depending on your threat model. Or you can of course give up and declare all of computing fundamentally untrustable but still useful for some purposes. Like I said in the post, I'm glad for the existence of both the purists and the pragmatists in this space.
- dataflow 5y ago
  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.
        5y ago
- mannykannot 5y ago
  I think it is something of an exaggeration to say that the scope of attack has been reduced to "you must own a fab". At best, it is the scope of the bootstrap problem that has been reduced, but there is still the problem of securing and verifying all the source code for the software you are going to need to do something useful (including, but by no means limited to, the toolchain and the operating system which hosts it.) Solving the hardest problem (or what appears to be it) does not mean that everything else is tractable. In this case, the sheer size of the problem means that it is beyond the scope of one person [1], so the problem becomes one of who you trust, not what you trust. I think we all knew it was going to come down to this; how does bootstrap.org deal with it? [1] I'm putting aside the problem of verifying the design of what the fab makes, of the fab itself, and the trustworthiness of the people building and operating it, which is, as you suggest, 'just' another heap of turtles.

dave_universetf 5y ago

I did go that far down, and there is a purpose. Reducing the scope of attack to "you must own a fab" is pretty great, honestly. Sure, it won't stop a perfectly placed nation-state from mounting a bespoke attack just for you by twiddling silicon doping on a wafer... But that's quite a bit harder and more expensive than "install an SMM rootkit". And, if you do care about trustable hardware... There are bootstrapping and verification paths available there as well, depending on your threat model. Or you can of course give up and declare all of computing fundamentally untrustable but still useful for some purposes. Like I said in the post, I'm glad for the existence of both the purists and the pragmatists in this space.

dataflow 5y ago
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.
        5y ago
mannykannot 5y ago
I think it is something of an exaggeration to say that the scope of attack has been reduced to "you must own a fab". At best, it is the scope of the bootstrap problem that has been reduced, but there is still the problem of securing and verifying all the source code for the software you are going to need to do something useful (including, but by no means limited to, the toolchain and the operating system which hosts it.) Solving the hardest problem (or what appears to be it) does not mean that everything else is tractable. In this case, the sheer size of the problem means that it is beyond the scope of one person [1], so the problem becomes one of who you trust, not what you trust. I think we all knew it was going to come down to this; how does bootstrap.org deal with it? [1] I'm putting aside the problem of verifying the design of what the fab makes, of the fab itself, and the trustworthiness of the people building and operating it, which is, as you suggest, 'just' another heap of turtles.