5 ms·

I haven't figured out the exact wording or requirements - feedback welcome. My goal is not to discourage "Fully Finished" sort of products - if you have some w

by Syonyk 4y ago

I haven't figured out the exact wording or requirements - feedback welcome. My goal is not to discourage "Fully Finished" sort of products - if you have some widget that does X, and you've optimized the firmware to do X, and it won't need to do anything else beyond X, then... OK, good job, please make more things. The target here is "consumer electronics" sort of devices - phones, speakers, fridges, washers, etc. And I don't think it has to be a "default unlocked" process, so much as "Some process to allow you to boot what you want." And if that's "I submit a blob upstream and they sign it so it can shim my kernel," well... not great, but OK. However, the reality for something like your scenario, nuclear control systems, is that anyone who can get close enough (physically or digitally) to one for it to matter isn't going to be hindered by some pesky firmware lock.

derefr 4y ago
> anyone who can get close enough (physically or digitally) to one for it to matter isn't going to be hindered by some pesky firmware lock. I mean, being unable to modify secure embedded systems by getting close to them "digitally" is the whole positive point of the much-reviled-in-personal-computing Trusted Computing Base paradigm. If Intel CPUs can cryptographically verify that microcode updates come only from Intel, and that the bootloader ROM is signed by the manufacturer key stored in the CPU's own TPM, then the microcontrollers in critical systems like these should be doing no less. "Unlocking" such a system to free modification by the installation IT administrator really does lose you some quite-powerful security advantages vs. having an end-to-end-secure logistical pipeline for updates direct from the manufacturer to your microcontroller, that not even the site admin can tamper with. Also, on a tangent — with really-critical embedded systems, there are ways to prevent physical proximity from giving someone the keys to the kingdom as well. For example: making the system a distributed-majority-consensus system run across several secure installations, where you'd need to physically penetrate several installations at once — hopefully all with independently-designed security policies — in order to get the system as a whole to do something else. Where any timing slip-ups would reveal one of the systems as faulty, and prompt an immediate [probably armed] investigation response.
- Syonyk 4y ago
  > ...then the microcontrollers in critical systems like these should be doing no less. Should be, I agree. Though I would doubt that they are. We've seen plenty of malware packages related to industrial control systems over the past decade or so, which mostly rely on "compromising the workstation that programs PLCs and fixes their behavior over the network to meet the attacker's desires." My goal here certainly isn't to impact industrial control systems, but to generate less ewaste of "Well, we're bored with it, good luck!" end of life devices.
  - derefr 4y ago
    > Should be, I agree. Though I would doubt that they are. I think that's mostly to do with the fact that many industrial control systems still in use predate TCB or anything like it. "Why change what works", etc. Contracts for new designs, meanwhile, tend to specify all the security they can think of.
Thorrez 4y ago
Sounds sort of like Richard Stallman's boundary on what software is required to be free: >The case of the toaster is very clear: we can't tell, except by taking it apart, whether it has a processor and software or a special-purpose chip. Since that we can't tell the difference, it makes no difference: therefore, a program that will never be changed is equivalent to a circuit. I don't care whether a toaster or microwave oven contains software. https://interviews.slashdot.org/story/14/05/05/2012218/richard-stallman-answers-your-questions https://interviews.slashdot.org/story/14/05/05/2012218/richa...
- Syonyk 4y ago
  Thanks - I'd not seen that before, and I think it generally covers the principle well. I don't care if a fixed function device that does its job well can be updated, but I do care if something like a fridge that talks to Google Calendar ends up obsolete with nothing but a warning message on screen because it's out of date. Though why a fridge needs a screen anyway is beyond me...
- derefr 4y ago
  My point wasn't so much about "fixed function" devices like toasters, but rather about higher-level industrial IoT devices like commercial security-monitoring control systems, or electricity meters (the kinds of things that have embedded 5G radios); and also about complex, flexible-purpose, networked "embedded" systems like SAN hardware appliances or network switches. These types of devices do receive regular firmware updates. And (certain models of them) are required to operate in high-security environments, where the end-to-end logistical security of update delivery is part of what the customers of those systems are paying for by buying them. Also, in general, these systems have "no user-modifiable parts"; all the useful configuration for them is exposed on the outside, where nothing you'd want to do with them would require hacking them — because much of the point of these devices is to be a hermetic environment isolating the data they evaluate or carry from interference by third parties. Maybe the best example in this category would be an Intrusion Detection System. It's definitely a full computer! But if you're the sort of company that needs one of those, then you certainly don't want the IDS itself to have any exploit surface whatsoever — including at the firmware level. And you'd rather lose out on ability to install custom firmware on your own IDS, if that means that an APT loses the ability to rootkit your IDS.

by Syonyk 4y ago

derefr 4y ago

> anyone who can get close enough (physically or digitally) to one for it to matter isn't going to be hindered by some pesky firmware lock. I mean, being unable to modify secure embedded systems by getting close to them "digitally" is the whole positive point of the much-reviled-in-personal-computing Trusted Computing Base paradigm. If Intel CPUs can cryptographically verify that microcode updates come only from Intel, and that the bootloader ROM is signed by the manufacturer key stored in the CPU's own TPM, then the microcontrollers in critical systems like these should be doing no less. "Unlocking" such a system to free modification by the installation IT administrator really does lose you some quite-powerful security advantages vs. having an end-to-end-secure logistical pipeline for updates direct from the manufacturer to your microcontroller, that not even the site admin can tamper with. Also, on a tangent — with really-critical embedded systems, there are ways to prevent physical proximity from giving someone the keys to the kingdom as well. For example: making the system a distributed-majority-consensus system run across several secure installations, where you'd need to physically penetrate several installations at once — hopefully all with independently-designed security policies — in order to get the system as a whole to do something else. Where any timing slip-ups would reveal one of the systems as faulty, and prompt an immediate [probably armed] investigation response.

Syonyk 4y ago
> ...then the microcontrollers in critical systems like these should be doing no less. Should be, I agree. Though I would doubt that they are. We've seen plenty of malware packages related to industrial control systems over the past decade or so, which mostly rely on "compromising the workstation that programs PLCs and fixes their behavior over the network to meet the attacker's desires." My goal here certainly isn't to impact industrial control systems, but to generate less ewaste of "Well, we're bored with it, good luck!" end of life devices.
- derefr 4y ago
  > Should be, I agree. Though I would doubt that they are. I think that's mostly to do with the fact that many industrial control systems still in use predate TCB or anything like it. "Why change what works", etc. Contracts for new designs, meanwhile, tend to specify all the security they can think of.

Thorrez 4y ago

Sounds sort of like Richard Stallman's boundary on what software is required to be free: >The case of the toaster is very clear: we can't tell, except by taking it apart, whether it has a processor and software or a special-purpose chip. Since that we can't tell the difference, it makes no difference: therefore, a program that will never be changed is equivalent to a circuit. I don't care whether a toaster or microwave oven contains software. https://interviews.slashdot.org/story/14/05/05/2012218/richard-stallman-answers-your-questions https://interviews.slashdot.org/story/14/05/05/2012218/richa...

Syonyk 4y ago
Thanks - I'd not seen that before, and I think it generally covers the principle well. I don't care if a fixed function device that does its job well can be updated, but I do care if something like a fridge that talks to Google Calendar ends up obsolete with nothing but a warning message on screen because it's out of date. Though why a fridge needs a screen anyway is beyond me...
derefr 4y ago
My point wasn't so much about "fixed function" devices like toasters, but rather about higher-level industrial IoT devices like commercial security-monitoring control systems, or electricity meters (the kinds of things that have embedded 5G radios); and also about complex, flexible-purpose, networked "embedded" systems like SAN hardware appliances or network switches. These types of devices do receive regular firmware updates. And (certain models of them) are required to operate in high-security environments, where the end-to-end logistical security of update delivery is part of what the customers of those systems are paying for by buying them. Also, in general, these systems have "no user-modifiable parts"; all the useful configuration for them is exposed on the outside, where nothing you'd want to do with them would require hacking them — because much of the point of these devices is to be a hermetic environment isolating the data they evaluate or carry from interference by third parties. Maybe the best example in this category would be an Intrusion Detection System. It's definitely a full computer! But if you're the sort of company that needs one of those, then you certainly don't want the IDS itself to have any exploit surface whatsoever — including at the firmware level. And you'd rather lose out on ability to install custom firmware on your own IDS, if that means that an APT loses the ability to rootkit your IDS.