Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates

The irony is that botnets often function as an automatic update: they break in through a vulnerability, often include a patch for said vulnerability, and then stay somewhat updated via their C&C server. Of course, this is all to prevent other botnets from coming in and stealing their devices away.

We had a WiFi camera get compromised. We put it on the internet - so it could get an update - and it got pwned before the update even finished downloading. The malware blocked the admin interface, but kept the camera feed running, presumably to minimize suspicion. As far as we can tell, the actual vuln was patched (some sort of dumb command injection in one of the many exposed endpoints), so there was also no way for us to get back in.

The single biggest problem with IoT devices is the black box, vendor-specific cloud platform nature. This causes privacy issues galore as well as requiring every manufacturer to reinvent the wheel to secure their devices, while also making huge quantities of ewaste when Random Manufacturer #484 goes out of business, taking their cloud with them.

How about instead, mandating that all IoT devices need to comply with an open standard? Customers would be free to connect their device to Siri or Alexa if they wanted, but by default the device just works with an open standard that you can control fully, hosted at home if desired.

It would also remove the cloud security onus from the manufacturer—they would fund the standards org, which would be responsible for the security of the interface.

We already have this concept for electricity, phones, networking. You don’t buy a “MA Bell” phone anymore or an “Edison-compatible” fan.

I strongly suspect that regulation at the IoT product level will have a very small practical impact because I think its largely targeting the wrong issue. The vast majority of the vulnerabilities aren't coming from the manufacturer, many of them are making relatively small changes to a reference design provided by a company like Broadcom (which is notorious for exactly the behavior I'm about to describe).

The reference design problem is an issue where a manufacturer like Broadcom creates a specialized chip. To use this chip they create a "reference driver" for it, package it in a custom firmware, then will never update that reference software. I've worked building internet routers for homes and small business and there are pieces of software we couldn't touch because they had been modified and only the fully compiled version is provided.

Broadcom passes the buck by calling it a reference design and washing their hands of it. Some upstreams do provide the source, but it's the complete source, not just the changes they made and usually without any specific reference to what the specific version they based their changes on was. Trying to tease specific changes from the Linux kernel's raw source code is quite the needle in the haystack problem.

I'm not sure how a lot of device manufacturers _could_ handle this. They tend to have very small development teams that are more electrical engineers than software engineers and usually their only directive is to make it work under an extraordinarily tight deadlines. Maybe part of the answer is they need to hire more to be more responsible... But even with experienced developers _every single hardware manufacturer_ is going to have to repeat the security fixes that companies like Broadcom refuse to fix.

I don't even know where to begin proposing a legal foundation for reference design software. I do think if the penalties and pain were strict enough at this level it would lead to a different shortcut that would be much more beneficial to the world... If Broadcom and other companies doing this kind of malicious apathy were forced to keep their reference designs up to date, my money would be that they stop doing it entirely and instead get those driver merged into the Linux kernel proper where it can be properly maintained and updated by the legion of developers that care.

The act of getting that code into the kernel would force them to improve the code and not take the shortcuts that cause so many headaches because the kernel developers gate the quality of code they produce.

Fully agree. If some company vanishes, consumers are left holding the shit end of a broken stick. It would sure help if there were protections for those that effectively volunteer their time and effort to keep things running for others.

That's the thing though: most IoT devices shouldn't be Internet-connected, and most definitely should not depend on a vendor cloud (or increasingly, a cloud of a different vendor that sold white-label IoT solution to the "vendor" you you bought the device from). It's an unnecessary limitation, a combination of laziness (going over cloud is easier than figuring out local-first and standardizing on some VPN solution) and abusive business (the cloud on the other side of the world is holding your Internet-connected air conditioner hostage, better play nice).

If brakes are not Internet-connected, that's mostly because they were established before Internet - and given the trends in car manufacturing in general, it's only a matter of time.

(In some sense, we're already there - if you have cloud-connected self-driving, and that self-driving can override your command to apply brakes, then your brakes are de-facto Internet-connected, even if connectivity isn't a hard dependency in all cases just yet.)