+1 for this at the consumer level. My oven may have a critical update, but - for right now - *nothing* is more critical than finishing dinner. I'll let the update apply the day after thanksgiving when I'm doing the dishes.
There are a few connected appliances brands that do this well: updates are broken down into two classes - "critical/security" updates and "all the other updates" - and I get to pick from "do nothing, notify, notify and download, notify, schedule/auto-apply" for both channels. Unfortunately this is not common because it takes planning and more than the bare minimum to pull off.
Is finishing the dinner more important than applying a patch that fixes actively exploited bug that locks your oven into cleaning mode and burns everything inside into ash over the next three hours? Or something that disables the safety checks and lets the oven overheat and burn your house down?
(Granted, the latter shouldn't physically be possible because it should have physical temperature killswitches etc.)
People always (understandably so!) consider software updates to be annoyances; but especially when you give an example like _an oven_, the potential for _catastrophic_ failures is too great.
I wonder how the impulse to connect everything to the internet will be remembered.
Hopefully, that's how the impulse will be remembered.
I agree that these scenarios are (relatively) far fetched _now_; but if we expect the future to include connecting appliances like that to the internet, then solving problems like those is table-stakes stuff.
I understand that enforced software updates are annoying; but for high-stakes environments like this they strike me as a lesser of the two evils.
Great, so we now agree that it's important to keep the system patched and up to date.
Besides that, the safe mode oven should still be able to cook food manually.
Though I guess making the experience frustrating could keep more people from needlessly connecting everything to the network because it sound futuristic...
You could have a second SoC on the device running off ROM, whose only purpose is handling this safe mode and controlling internet access of the main device. Keep it simple and make it essentially just a fuse that can be blown (turning off internet access) by a signed message from the manufacturer. Keep the hardware capability of this SoC to just that, so even if you have a vulnerability on that thing itself, an attacker can't really do anything with it. Keep the code running on that SoC simple and preferably make it a FSM that is proven to be free of vulnerabilities. Also make sure the main device can't interfere with it in any way.
Once the fuse is blown, the user needs to press a physical button on the device to re-enable internet access. Preferably ship the devices with this internet access disabled by default.
Even better yet, don't build an internet connected oven... but that ship has sailed in many areas.
This was exactly my thought. Download the update then take the device offline until it's applied if the update contains a security vulnerability.
Rushing to get out the door, "Honey, did we turn off the stove?" Presumably you can then check with your phone.
I'd expect the network connection to go down and the oven not to turn on at least as often as 10 minute makes an operable difference.
Anyway, last time I had this anxiety, I checked my Ring camera in the kitchen that's posted there for reasons like this. Works for the stove and faucet too.
These devices are designed to work for hours with minimal supervision. Given the size of the user base, IMO ovens are extremely reliable. And electricity prices are too low to be anxious about the costs.
I wish. A while back, I put some (food) stuff to dry in the oven on a very low heat, knowing it would take all night to dry fully. After six hours, the oven decided that I must have accidentally left it on by mistake, and switched off automatically, and that stuff was wrecked when I got up in the morning and checked on it.
And adding any remote update mechanism at all would more then likely decrease overall security.
So there actually should be a counter mandate too, for devices that are impractical to design to be physically serviceable, while meeting certain size/weight/etc. requirements.
To make sure remote update mechanisms, of any kind, are never implemented, unless the manufacturer can guarantee that the update mechanism itself doesn't introduce new flaws.
You can conformal coat a ESP32 with a sensor and battery and a wireless charger, and get remote updating. If hobbyists are doing that without commercial backing, what industry experts like you have access to must be even better.
And in any case, the default ideal is to have an option to update or reprogram devices in-person.
It's never an ideal, that I've ever seen expressed on HN, to have a remote actor capable of doing so, unless in a totally air gapped environment.
Not all devices have easy or cost-effective physical access -- that's why IOT is particularly effective at bridging the digital-physical divide.
Not really if done right to be fair. It's just a matter of implementing a signature verification of the firmware updates that are installed on the device.
> IoT is making its way into defense and enterprise environments where reliability is a matter of national security.
If it's a matter of national security surely you don't use IoT devices connected to the public internet. At least the devices are in some private network, where the traffic is under your control. So if you don't do security updates it may be acceptable under that circumstances.
In principle: yes. In practice: signing keys seem to get leaked all the time.
It's not a mechanism I would blindly trust in security sensitive domains.
Security is not an update, security is a cultural trait of an entity or an individual
Of course they do. That's the flip side of PaaS and reverse-NIH syndrome, the "opex > capex" thinking: "Industry 4.0" is built on web tech, with all the practices and assumptions baked in. Your critical infrastructure is, or is about to, be running JavaScript on a docker-compose cluster, and expecting to be piecemal-updated daily.
And then, there's also "shadow IT" - going behind the back of IT and using COTS SaaS to work around red tape is still... going around IT and giving untracked third-party vendors access to organizational information and operations. "Making its way" doesn't only mean "introduced by design" - those vulnerabilities just creep in.
correctly
With rollback protection, a chain of signing keys to allow revocation, time stamping, correct parsing, enough scratch space to hold an entire separate image in A/B, enough processing power to verify image signatures, etc etc.
Doing this well is very hard. Given most IoT vendors don’t yet know how to prevent XSS, there’s near zero chance they’ll get updates correct in the next decade without solid open source frameworks to leverage.
It needs to be really well protected so that the owner, and only the owner can disable the chain of security, but that they can do it without unreasonable overhead and without actually involving the manufacturer (in my opinion. To handle examples like manufacturer trying to lock-in or charge fees or simply going out of business)
Perhaps the owner mints a public key pair, and the device only unlocks with proof of the private key. But in a way in which is easy for your every day person.
Signature verification without human users controlling the updates means protecting an attack vector.
> The FCC recently issued a Notice of Proposed Rulemaking [2] for a cybersecurity labeling program for connected devices.
This sounds like it is intended for consumer products, and it also sounds optional. I would hope that users with a legitimate reason to do so (defense, enterprise) would have the capacity to not participate and forego the label.
A lot of IoT companies (especially the startups) focus on the customers with the deepest pockets (enterprise and defense). If big-ticket customers demand this label, it generates a great deal of incentive for IoT companies to just say "to hell with it, we want that label on everything we make."
In any case, the words "national security" are usually a good way to get the attention of a three letter ;)
I've proposed many times that the device have a physical write-enable switch on it, not a software switch. That way, a malware infestation won't survive a reboot, and your backup hard drives won't get compromised.
I'm amazed that nobody does this. (Hard drives used to have a write-enable switch on them.)
However, these pins mostly aren't used for any kind of switch in basically every PCB design I've seen. Either it's "always enabled" so the storage can always be written, or it's a chip that's programmed from the factory and always disabled to prevent any kind of user update.
I also have, on occasion, flipped the from and to parts of the command to restore from a backup. I'd really like to have a hardware switch to make the drive read-only.
Indeed, for a 2 cent switch.
I don't do much embedded work these days, but I remember a lot of shoddy, ersatz designs based on random OSS components. I remember a small mfg of hardware devices used widely in payment processing tell me they were secure because "they used SSL" despite not taking care of physical or system security in a coherent, effective way.
Honestly, companies need to have some liability or other incentives to even care about security a lot of the time.
IMO: one of the most important incentives towards secure IoT is: don't make it IoT unless it benefits the user greatly (instead of benefitting the manufacturer).
Don't let companies connect everything they want to the internet irresponsibly and if they must: force them to make it really really secure and long lasting (10+ years). Especially when there's high risk of causing physical damage to things and / or identity theft and / or privacy issues. Which en masse translate to national security issues.
Force them to sell devices that keep functioning even if the manufacturer (servers) cease to exist. Example: introduce a mandatory manufacturer IoT insurance that pays out in case the device ceases to function (securely) within x years (even in case of manufacturer bankruptcy).
Random chaotic brainfarts.
How does the FCC define a security flaw? Would updates only be distributed when there is a flaw that needs fixing?
Remote update mechanisms can themselves present security problems in some domains. Thus, some devices should only be updatable if the owner has physical access to the device. Will the manufacturer be liable for damages caused by attacks on vulnerable devices that were not sufficiently updated by their owners?
IoT is making its way into defense and enterprise environments where reliability is a matter of national security. An update nearly always results in some downtime for the device, even if it's just a couple seconds. Sometimes, it may be in the best interest of a device's owner to defer an update indefinitely, until that device's continuous operation is no longer mission-critical. Even if the owner can't control exactly what is in an update, they absolutely MUST be able to control when an update occurs.