Security policy is needed that accounts for the behaviors of the vast majority of users.
Apart from printers and smart TVs, less than half of US households have any of those other devices.
https://www.statista.com/statistics/1124290/smart-home-devic...
Anecdotally, most people I know who own those devices are the more technically inclined. Especially the thermostats and light bulbs. Even the doorbell surveillance networks have low penetration.
But if the aim is to stop DDOSes from botnets of poorly secured IOT devices, we need something to help the other 99% of the market.
Most folks can't or won't do lots of things in their lives (e.g. plumbing, electrical, construction, lawn services, Automotive).
The main thing blocking routers and IoT devices is the control every vendor wants to hold over their customers' devices after sale.
I'd argue that the main blocker to IoT security is the lack of culpability on the part of device manufacturers. I don't want to go so far as to suggest that companies should be wholly liable for software bugs, but vulnerabilities that are brought to the attention of the company privately or disclosed publicly absolutely should be their responsibility to address.
For you or me (or most of the folks here I suspect) we feel better if we had the ability to decide what software our fridge runs, but for 99% of people they're better off if their fridge's manufacturer provides them with regular security updates for the life of their product.
That being said, these aren't mutually exclusive. In a perfect world we'd have laws compelling fridge companies to allow 3rd party software if they don't keep their firmware up to date.
Even if I don't buy one, I dread to think of what might happen if enough fridges across the world stopped working all at once (demand for non-perishable food and fridges would skyrocket).
For the sake of consumer safety in our imperfect world, there should be a safe-mode hard switch fallback for any life-critical and/or high wattage device that gets networked.
Allowing people to install software on their hardware isn't a cure for vulnerabilities. It's a step in the right direction for sure, but it's a very small one from the perspective of something as huge as "IoT security".
imagine instead that vendors had to acknowlege the structure of their firmware, and make the (usually obvious) hardware interface documented from sale. that would automatically solve the issue of out-of-support(-by-vendor) hw.
Which is to say, you are buying a multi-year lease up front. And the manufacturer should send you a recycling return box.
This is a more honest way to sell these devices.
Consumers that would not care about length of security updates will suddenly very much care how long their “lease” is… and manufacturers would compete on the length of that lease (which is where the FCC could require security updates for the length of the lease period).
https://wireless.wiki.kernel.org/en/developers/regulatory/st... https://wireless.wiki.kernel.org/en/developers/regulatory
TLDR manufacturers and "serious" companies won't touch anything that could potentially be configured to emit signals that your local government doesn't like. So Linux has to pretend it doesn't allow to do that (even though anyone with 2 braincells can patch it)
https://www.computerworld.com/article/2993112/vint-cerf-and-...
As many modifications would void the FCC certifications of the device, due to changed parameters (more power, disabled anti-interface mitigations, out-of-band channels, etc.). This was avoided by making the radio firmware separate blobs, but there was a real danger of the whole device having to have signed firmware.
These days this seems to be mostly done in wifi chip firmware (that is then signed and under lock and wrap to make it tamper proof), but back in the day it was too easy to circumvent the mechanism.
The requirement was that consumer radio transmitters could be too easily made to use frequencies and power levels that violate FCC regulations.
If a device had a transmitter where firmware could control those things, and the firmware for the device was one blob that contained everything so letting the user replace firmware meant letting the user control those restricted parameters, then the manufacturer might have to lock the firmware.
There were other possible approaches. One would be to split the firmware into two parts. One part for the radio hardware and the other for everything else. Make it so the firmware update process only allows the manufacturer to supply the first part.
The prevention all comes down to enforcement though, the law doesn't physically stop you from making a device it just means you could get in trouble for intentionally ignoring it and selling a lot of those devices.
I'm not claiming it wouldn't be an overall social good, but other areas of law and regulation don't seem to function like this (with notable exceptions like photocopying banknotes).
That is to say, it's infeasible the average someone will make a working Wi-Fi radio which uses the Japanese channel 14 (involves changing what is sent by the radio, not just raising the frequency... unless you want to accurately re-adjust the frequency inside of your smartphone too) but it is reasonable to expect the average someone might just load some open firmware from the internet which allows them to set the channel to 14.
I will say I agree it's different than a lot of regulation. On the other thing I think that has more to do with radio space itself being very different than most things (i.e. a shared public resource) than inconsistency.
I suppose you could call that accidental radio pollution, because most of the people doing it probably didn't realize that they were causing interference, but regardless it was becoming a problem.
Hence regulations to address it.
That's the world we're in now. You have a problem, you do a search online for help, and among the answers you often will find some that really should only be used by people with more experience or expertise than you but do not make that clear.
http://www.taht.net/~d/fcc_saner_software_practices.pdf
Substitute IoT for router in everything we wrote there on page 12-13 and that seems to be a starting point everyone around here has come to think is necessary. I would prefer not to summarize such a large filing here.
Also Dan Geer wrote extensively on these topics at the time.
Of late I have been strongly suggesting that software be at least "built in america": https://blog.cerowrt.org/post/an_upgrade_in_place/
I care most deeply first - that the front doors to our houses, the home gateways, are properly secured, kept up to date, and have ipv6 and bufferbloat fixes on them.
IoT devices belong on their own vlan...
Of course, manufacturers don't want that either because they make money off of planned obsolescence and consumers keeping old hardware running makes them less likely to buy old hardware.
I think (and I'm a security know-nothing, so could very well be off in the weeds), the firmware should accept updates signed with two keys. The manufacturer key, which can allow automatic updates, and a post-service key that cannot be automatic. Either a user has to initiate the firmware update manually, or consent via some other means.
This post-service firmware may very well enable a third key for automatic updates of its own, so there's just a manual step on the transition from manufacturer to some community project you support, not each revision afterwards.
Ideally, the key would also be pre-registered somewhere to ensure they can't skip out on releasing it, but I'm not sure how you do that without it potentially leaking before the device reaches end of support. I guess a code sitting in a lawyer's vault somewhere. Again, nobody is paying the lawyer to refresh his vault's firmware image after each patch, so 2nd key wins over unlock firmware again.
Why a lawyer's vault? I know lots of people would love to take ownership of the device immediately, but from the device creator's perspective, they tend not to like that... especially if a device is a source of subscription revenue. So I'm not sure how you'd get vendor buy in to early release unless it becomes mandatory... which I can't see.
In general even if I like open devices and having the option to use my own software, this is not a solution for most of the consumers.
It is not a solution even for the enthusiast that know how to flash their own firmware. Because even if they may do it a few times initially, eventually they stop doing it.
You need a system that can update automatically even when you are busy in another project.
there are a lot of open and closed firmware projects building upon openwrt
That's more than a reach of a claim. All manufacturer firmware are buggy with poor security? That's very obviously false. With closed manufacturers the history is that it's a mixed bag, not a blanket. Some are excellent, some are very poor.
Openwrt has been mediocre and all the negatives about it do not equally apply to all closed manufacturer firmware.
guess we have a difference of opinion then
If a firmware update on my smart watch bricks it, who cares? But if my entire house/office is without internet connection because of a bug in the router update, then I don't want to waste time determining if its my ISP, my physical connection, my local hardware, or the firmware update that just occurred silently. I want to send the "update" command, note that network response did not resume within 5 minutes, and revert from there.
A lot of folks tend to think of firmware updates as identical in complexity and risk to any other software update. I submit that if it can't go wrong in such a way that it requires an in-system-programmer to fix, its a software update, not a firmware update.
In that sense, I think true firmware updates (e.g. BIOS updates and the like) require a different set of regulations than your standard IoT security updates.
• It happens, especially if the update has been a "quick fix" to a security issue, that the update introduces unexpected behaviours, or incompatibilities. Supposing this was just a "security-only" update that doesn't change any features, I would approve it, and then discover it breaks something in my installation (e.g., compatibility with a specific device or software I'm using). In that case, I need to be able to rollback the update and run the previous firmware version (possibly mitigating the security issue in another way, if it's properly documented) to avoid serious issues that, depending on the device, might prevent important equipment from being operated.
• For firmware updates that include more than security fixed, approval and the possibility of rolling back is even more important. It's quite common that updates remove seldom-used features a minority of users depend on. It even happens that some features get removed and replaced by subscription-only services, which is even worse.
There's this level of management at the google/amazom/apple level, and in some cases google even lets me push firmware updates (sennheiser ambeo is an example), BUT there should be a requirement that security settings in firmware be exposed in a way that they can be manipulated in a rolled up dashboard. I shouldn't have to depend on a first party app to stay maintained to get to the settings for a device.
As others have stated, free software is one way of giving the public ability to keep things up to date but that's almost like the government saying people are allowed to clean up pollution. It doesn't put any pressure on companies to behave better.
Another issue is build-ability of open source code. If an OEM submits firmware source and keys to a third party, even regularly, who really knows whether it is actually functional and complete. Automated tests or sample hardware are possible ideas but have their own failure modes and could be difficult for to implement solely for this purpose.
Another weird idea for the above. If one requirement was deterministic builds, then in addition to source/keys, a suitable toolchain to build could also be required such that the repository stewards would only need to run exactly what the OEM provides, and if the checksums don't match then it means they are not in compliance.
These days, with nationalism and populism rampant across the world, I think we need a solution where no one country (or country's leader) can simply decide to turn off critical infrastructure for the rest of the world and/or hold the rest of the world to ransom. Then you run into questions of "do we really want (insert bad country) to be able to expose IOT source code to their evil hackers?".
This is a really difficult problem to solve, but ultimately I think ownership of the "keys" to unlock escrowed code needs to reside with (winging it here...) a body such as IEEE or ISO. Or possibly something like a global council where e.g. any 5 countries out of 7 can collaborate via a sharing of keys to release source code, but no one country is able to do so.
Could have the code run in a sandbox where people can apply “external” network traffic trying to hack it (or apply vulnerabilities), inspired by how you can run ML models on kaggle.org on Kaggle servers to validate models.
Have end-points as honney-pots, so if you can access these endpoint you prove you have compromised the code.
If there is no new code with patches the keys are released.
This way FCC/gov don’t need to maintain a technical system. Just build this once.
[1] This discussion is about a federal agency providing certification of products essentially in the form of a stamp (on a device, website, etc.). Nothing is stopping a vendor from committing to and offering the same thing but without government involvement. This could easily be a selling point for the paranoid. Something something blockchain and smart contracts...
[2] Even though we're discussing IoT devices, it's not necessary that they be capable of updating over the air 24/7. Creative engineers could probably devise a method to prevent complete remote takeover by anyone holding the keys– physical switches, additional authentication required during the support period, etc.
[3] Personally, I think the federal government getting access to keys for any IoT device made/sold in the US is the only part of this idea that could already be happening. They can knock on doors or mail subpoenas, plant moles, etc. I would be much more comfortable with a technical solution on the physical device than any presumption of privacy in the current state.
Verification that it is, in fact, the actual shipped source might not be trivial either.
Either the escrow would have to apply to all software on the device, regardless of whether owned by the OEM or third parties, or OEMs would be required to vouch for all the included software.
I'd prefer the former myself: multiple software and patent assets can be combined, but on support EOL, all those become public domain.
Build / release / update toolchains must also be included.
However, it's very hard to police: what if the company only provides a header file or so? Or the basic OS but not the UI?
Moreover, what counts as "support"? There have been cases where companies refuse to consider remote code execution a "security issue". What's to prevent token updates that let the company claim a product is supported while it's riddled with holes?
I could also see companies fighting teeth and nails against this if their devices share a common software base. But hey, you have your support incentive right there!
Furthermore, if the concern is national security, then I think some of the onus should be on the corporate consumers of such devices. Holding them responsible for doing due diligence on their vendors seems easier to regulate and enforce than trying to regulate supply side.
Of course, this leaves the general population without a clear solution to updates if the process of updating using alternate channels has any amount of friction whatsoever. I'm clueless as to what to do about that. Regulating it entrenches established companies. Not regulating it maintains the status quo.
Anecdotally, it feels like software has gotten far more secure in the past decade without regulation but security theater and concerns around national security have grown considerably faster. This isn't easy to measure of course, but that's how I see it.
At the very least, it should be possible after some time period of no updates or insecurity, but a blanket requirement is less susceptible to games.
Probably the best thing to happen to wireless routers is OpenWRT and the other descendents of the WRT firmware.