3 ms·

Wouldn't this necessarily include "devices" like nuclear-reactor control systems? Because AFAICT there's no clear line where a "computer" stops and something li

by derefr 4y ago

Wouldn't this necessarily include "devices" like nuclear-reactor control systems? Because AFAICT there's no clear line where a "computer" stops and something like that starts. I imagine there would need to be a special protections in the clause for "secure embedded industrial" devices like that — something like: "if opening your company's devices to free modification would create a national security risk, then your company is not allowed to go out of business in the first place; instead, bankruptcy of your company will lead to immediate nationalization of such assets as are required to keep your devices up-to-date with secure firmware in perpetuity." (It's actually kind of weird that there isn't already anything like this on the books in America; so it was possible for the private sector to e.g. shut down all the 5.25"-floppy-disk factories, despite military missile control systems still actively depending on them. You'd think governments would wield at least contract law — if not legislation — more eagerly, to protect "critical logisticla dependencies" like these.)

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.
karottenreibe 4y ago
Sold to consumers vs sold to a company would suffice as a distinction IMO.
Dylan16807 4y ago
> Wouldn't this necessarily include "devices" like nuclear-reactor control systems? I don't really understand the example. Shouldn't a power plant get access to their own systems?
- aerostable_slug 4y ago
  What if firmware or other updates have to be signed to be accepted? Who manages the private key(s) when a vendor goes under? How are they distributed and to whom? I'd worry less with nuclear plant owner/operators as they are used to safeguarding certain types of information, but let's imagine something like firmware for large transformers or other critical infrastructure where security postures vary across owner/operators.
  - Dylan16807 4y ago
    Then you need to add a way for users to alter the trusted keys. Make it require physical access. If someone has physical access they could always throw a wrench into it. The whole idea of allowing alternate firmware is that it shouldn't need the original keys.
    - aerostable_slug 4y ago
      I'd support that as long as there are exemptions for those devices that aren't quite like a consumer iPad. For example, there are a range of devices where your primary threat actors already have physical access to the device in question and it's important to prevent tampering. These can include electric, gas, and water meters on homes and businesses; computing devices in correctional settings; certain military systems; gaming (gambling) systems like slot machines; etc. They aren't the usual use case but they are real and they are out there in significant numbers.
      - Dylan16807 4y ago
        Don't make an exception for almost any of those, add in functionality so the administrator can set a password and lock it. You still don't want the manufacturer to have ultimate power. Maybe for a gambling machine you'd do it differently, but those are already very specially handled.
vineyardmike 4y ago
> (It's actually kind of weird that there isn't already anything like this on the books in America; so it was possible for the private sector to e.g. shut down all the 5.25"-floppy-disk factories, despite military missile control systems still actively depending on them. You'd think governments would wield at least contract law — if not legislation — more eagerly, to protect "critical logisticla dependencies" like these.) 1. The government can just say "we'll spend $10,000 per flop-disk reader" and some one will probably find a way to produce that profitably. 2. https://en.wikipedia.org/wiki/Defense_Production_Act_of_1950 https://en.wikipedia.org/wiki/Defense_Production_Act_of_1950

by derefr 4y ago

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.

karottenreibe 4y ago

Sold to consumers vs sold to a company would suffice as a distinction IMO.

Dylan16807 4y ago

> Wouldn't this necessarily include "devices" like nuclear-reactor control systems? I don't really understand the example. Shouldn't a power plant get access to their own systems?

aerostable_slug 4y ago
What if firmware or other updates have to be signed to be accepted? Who manages the private key(s) when a vendor goes under? How are they distributed and to whom? I'd worry less with nuclear plant owner/operators as they are used to safeguarding certain types of information, but let's imagine something like firmware for large transformers or other critical infrastructure where security postures vary across owner/operators.
- Dylan16807 4y ago
  Then you need to add a way for users to alter the trusted keys. Make it require physical access. If someone has physical access they could always throw a wrench into it. The whole idea of allowing alternate firmware is that it shouldn't need the original keys.
  - aerostable_slug 4y ago
    I'd support that as long as there are exemptions for those devices that aren't quite like a consumer iPad. For example, there are a range of devices where your primary threat actors already have physical access to the device in question and it's important to prevent tampering. These can include electric, gas, and water meters on homes and businesses; computing devices in correctional settings; certain military systems; gaming (gambling) systems like slot machines; etc. They aren't the usual use case but they are real and they are out there in significant numbers.
    - Dylan16807 4y ago
      Don't make an exception for almost any of those, add in functionality so the administrator can set a password and lock it. You still don't want the manufacturer to have ultimate power. Maybe for a gambling machine you'd do it differently, but those are already very specially handled.

vineyardmike 4y ago

> (It's actually kind of weird that there isn't already anything like this on the books in America; so it was possible for the private sector to e.g. shut down all the 5.25"-floppy-disk factories, despite military missile control systems still actively depending on them. You'd think governments would wield at least contract law — if not legislation — more eagerly, to protect "critical logisticla dependencies" like these.) 1. The government can just say "we'll spend $10,000 per flop-disk reader" and some one will probably find a way to produce that profitably. 2. https://en.wikipedia.org/wiki/Defense_Production_Act_of_1950 https://en.wikipedia.org/wiki/Defense_Production_Act_of_1950