Disaster awaits if we don't secure IoT now | Hacker News Reader

Disaster awaits if we don't secure IoT now

spectrum.ieee.org

71 pointsmdp202174 comments

Please read the article before commenting, because I find the proposed solution a bit worrisome.

Of course we should secure IoT, but the article is about one very particular kind of security: roots of trust. The idea is that devices shouldn't run unsigned software, so forget about custom firmwares, and generally owning the hardware.

There is a workaround, sometimes called "user override", where the owners can set their own root-of-trust so that they can install custom software. It may involves some physical action, like pushing a switch, so that it cannot be done remotely by a hacker. But the article doesn't mention that, in fact, it especially mentions that the manufacturer (not the user) is to be trusted and an appropriate response is to reset the device, making it completely unusable for the user. Note that such behavior is considered unacceptable by GPLv3.

There are some cases where it is appropriate, GPLv3 makes a distinction between hardware sold to businesses and "User Products", and I think that's fair. You probably don't want people to tinker with things like credit card terminals. But the article makes no such distinction, even implying that consumer goods are to be included.

Not only that, "roots of trust" and locking users out of their devices is the thing that causes the IoS omnishambles. The foundational problem is that some company makes millions of devices and then goes out of business or otherwise stops supporting them, but because the users are locked out of the device, nobody else can do it either. Meanwhile people continue to use them because the device is still functional modulo the unpatched security vulnerabilities.

If anyone could straightforwardly install the latest DD-WRT or similar then it's solved, because then you don't have to replace the hardware to replace the software, and the manufacturer could even push a community firmware to the thing as their last act before discontinuing support.

> and the manufacturer could even push a community firmware to the thing as their last act before discontinuing support.

This should be held in escrow before the device can be sold. And the entity doing the escrow service should periodically build the software and install it onto newly-purchased test devices to make sure it's still valid.

If the company drops support, either by going out of business or by simply allowing issues to go unaddressed for too long, then the escrowed BSP/firmware is released and the people now own their own hardware.

That seems like a lot of complicated when the better solution is to have the people own their hardware from day one.

You also need the community around the device to already exist on the day support is discontinued instead of needing to build one then around a device which is by that point years old and unavailable for new purchase.

I really thought escrow for software would've been SOP by now.

We made EMRs in the 2000s. Our customers required everything to be placed in escrow. It seemed abundantly prudent to me.

Maybe even prescient; our startup was bought, then murdered in its crib, leaving our customers SOoL. But at least they got the source.

The issue is as much companies going out of business as consumers buying devices from shit companies.

We need schemes which enforce security and which make long term economic sense. I would require software escrow for all companies to ensure a bankruptcy doesn't mean all software is lost.

A solid 90% of the problem is that hardware companies think that somebody actually wants their software. Hardware vendors are bad at software. They should not attempt to make software. They should make hardware with the expectation that customers will install whatever software they want on it, and then throw some open source code straight from github on it for the customers who expect it to do something right out of the box.

Their code is bad. It should not be used. They should not even write it to begin with. Just ship the device with existing open source code with the minimum -- and published -- modifications to make it run on your device, and focus on being a hardware company.

This is exactly the approach of Pine64.

Isn’t this what happened with the Ender 3 pro and people griped about it?

People gripe about everything. Don't care about it unless their complaints have merit, or if they do then fix the problem.

I completely agree, and it disappoints me greatly to see articles like this because it advocates doing what the manufacturers already want to do so they can increase their control. It's the exact type of article that people who want to lock things down will use to discredit or disagree with someone advocating a more ethical approach.

I would add that root of trust secures against rare, advanced attacks like the "evil maid" or supply chain attacks. You should worry about that after you've already secured against basic vulnerabilities which 90% of IoT devices have not done.

How user antagonistic changing code on IoT devices should be is highly dependent on the threat model for the devices. I'm happy to trust home users to flash their lightbulbs and door locks (though the company might not see that as acceptable to their brand reputation if their lock is compromised nonetheless), but I would prefer not to trust the hundreds of IT departments and engineering teams to properly vet the code they are flashing onto industrial control systems when lives are at stake - centralized authority and accountability with high visibility on the code base that is flashed to the devices is what is needed there.

> Guy Fedorkow is a Connection Science Fellow at MIT, a Distinguished Engineer at Juniper Networks, and a contributor to the Trusted Computing Group.

Talk about the worst corporate doublespeak - 'trusted computing'.

It also goes by DRM, or rental hardware, or you never actually own it cause someone else retains permanent digital control.

There is NO trust here, only control and power in never actually selling anything.

And since we're talking of IoT, this goes hand in hand with proprietary corporate clouds, anti-FLOSS like Home Assistant, rental in the form of sales, forced firmware upgrades that remove previous features to gatekeep and resell what you promised.

I don't even need to read further. Anybody, and I do mean anybody, who uses the moniker 'Trusted Computing', should be ignored, blackballed, and relegated to the bin of computing.

> anti-FLOSS like Home Assistant

Could you expand on this?

Not hard to. Go look at the wide variety of hardware that does NOT work with Home Assistant, or works tenuously through some heavily rate limited public web api.

There is a reason why for my IoT setup so far, its been primarily OpenGarage, IKEA IoT (ZigBee), and existing compute services I locally host.

Remote servers come and go. Companies come and go. If I am at the forced behest of some company to 'bless' my hardware, its not mine. And I think its fraud to even claim it a sale. Its a 'rental as long as the company wishes'.

Ah ok, what I thought you meant was pretty much the opposite of that, e.g. that they were doing some kind of "openwashing" I hadn't heard of yet. Thanks for clearing that up

Are you familiar with the academic field of security and the notion of trust in trusted computing? The IoT devices that is being discussed in the article are for industrial control systems, not necessarily your home lightbulb. The threat model is different. Do you want every municipal power company to be trusted to properly vet the code they are putting on these devices, or do you want to trust the device manufacturer to be the one who can put code on the devices?

Owner is still owner, be it someone who lives in a single family residence, or that of a municipality.

In my area, tornado sirens are unencrypted aand a simple recordable and replayable frequency. The cost to add an encrypted radio connection is $100k for the base station, and $25k per siren. There are 80+ sirens.

If this were open source, then a simple computer could he retrofitted to do this. But because they are highly proprietary, the county would be on the hook for $2.1M just to defend against an asshole with a HackRF.

FLOSS and open principles should matter to governments as well as individuals. Trading temporary easiness for no long term usability is utterly ridiculous. And you end up with a doorstop in the end either way.

And who can push new code after the manufacturer's bankruptcy? I've worked in IoT and I'd say the biggest security problems are in this order:

- Devices requiring Internet access for functionality that could have been done locally

- Hardware SDKs which are basically abandoned forks by manufacturers so IoT companies ship stone-age kernels and device drivers

- The usual stuff: too much complexity, lack of tests, bad documentation, meaning old parts of the software get forgotten (but remain exploitable)

Theoretical waxing about trusted computing and remote attestation does seem disingenuous when problems with non-certified firmware is probably not even in the top 10 in the real world. Notice how the article author mentions some scary attacks but conveniently omits how the attackers actually gained access?

This is pure academic theory-crafting. Who is going to pay for this and how will it be financed?

Even in the industrial space, it's simply not going to happen given the costs of securing wrt the business value and relative risk aside from projects that have some sort of community/municipal/national "critical infrastructure" domain (think power generation) where a legitimate business case (think in terms of MARR https://en.wikipedia.org/wiki/Minimum_acceptable_rate_of_ret... ) can be made for safety and/or regulatory compliance future-proofing and a source of cheap 3rd party (usually government) capital is made available.

There are also huge legacy IoT investments in capital inefficient low-margin businesses (think mining and ship-building) where this sort of "maintenance" and retroactively applying "defense in depth" makes little sense compared to wholesale generational migration.

Nobody is going to do it until there's some sort of abrupt forced exigent existential externality applied to the entire industry (e.g. ozone layer depletion and refrigerants) and then they'll be a single mass-migration.

> Who is going to pay for this and how will it be financed?

As with climate change, "we all will" and "with great difficulty, far too late".

If the right incentives and remediation plans are put in place, we can.

There's two very established routes for setting cyber security standards.

* Government regulation.

* Insurance requirements. Mostly applies to businesses.

This would be out of the frying pan and into the fire.

The only long term viable approach for IoT security is to not allow these devices on the Internet in the first place. Have the WiFi Access Point, or some other gateway, act as the broker for all information, and the default is each device sees nothing until given permission. *

Whenever this comes up people raise the point that this won't work because it disincentivizes making devices to slurp data, but it's not like that ecosystem actually exists at all, with the exception of smart TV which hardly counts as IoT. Consumer IoT hasn't taken off because consumers are rightly paranoid about bait-and-switch and being left with useless devices in the walls of their homes.

* This is roughly what https://github.com/atomirex/umbrella is trying to head towards, hence seeing if a $50 AP can act as a media SFU, and learning it totally can.

Apple had a decent start on this. An always-on Apple TV can connect to a Zigbee hub and provide remote access to devices through HomeKit. But it seems like Zigbee isn't winning out as the dominant standard. Most of the recent HomeKit improvements have been related to the wifi-based Matter.

Industrially there is a decent amount of LoRa (and relatedly lorawan) about too, and that fills a similar role to Zigbee in the comparison.

It's definitely an issue - I was at a heat pump company working on data, and as much as the work was interesting (and I liked doing something related to sustainability), there was a core question of "wait, _why_ do we need to gather data from everyone's thermostats again?"

Though as we move towards things like virtual power plants and more integrated systems with home batteries, etc. the use case is clearer.

> The only long term viable approach for IoT security is to not allow these devices on the Internet in the first place.

Ye it is about that simple. IoT don't need the I. Given how low my trust is for vendors I wouldn't even be happy with a separate no internet wifi since the devices can hook up to some other wifi.

Exactly. The wifi these devices should be on should have no access to anything except the broker in the gateway device.

Certainly no multicast or anything like that.

>Have the WiFi Access Point, or some other gateway, act as the broker for all information, and the default is each device sees nothing until given permission. *

Not everywhere is going to have WiFi. A SIM can use a private APN that selects the PGW/IP/Network range and from the ISP usually has a VPN to your network. Does not go "over the internet" at all.

This is (usually) how industrial IoT, connected cars etc work. Shipping containers cant rely on WiFi.

For industrial devices, absolutely. For consumer devices, I think it can be a double edged sword. The more "secure" IoT devices are, the more locked down and difficult to jailbreak they are, which is bad for consumers and just leads to e-waste when a product gets abandoned by its manufacturer.

Sometimes I wonder what would happen, as a beginning step, if we mandated the ability to purchase unlocked bare hardware. The law doesn’t need to require (in the first phase) that iOS or something be compatible with it, but you could at least walk into an Apple Store or Nintendo Store and buy the bare hardware, for your own purposes. Then we could claim it as being only about choice, and allowing software competition, without any plausible security risk.

In this case, you would be liable by any damage your compromised devices might cause. Let's say you find updates in your house battery/inverter are annoying and, then, someone takes over it and cause a power surge in the neighborhood. That'd not be on the hardware manufacturer, who did their best to avoid such incidents, but on you, who clearly didn't.

If you knowingly use obsolete and insecure devices, you might end up being liable for their actions.

Are there such examples of this happening? Or are there only examples of corporations doing this and suffering no repercussions?

There are two types of security: one where a user is secure against hackers and the other one where manufacturer has "secured" its devices against users. The second type is strictly stronger, and it seems companies will not be interested in giving any real freedom to users, apart from running a predefined and restricted set of functions. In other words, you won't own a device, only the services it produces.

A challenge with IIoT is that the standards processes are consistently driven to the lowest common denominator. It is partly driven by cost sensitivity but also by the reality that many of these hardware companies are unsophisticated at software development and have no realistic way of becoming sophisticated.

Adding to this that the scale requirements for implementing these standards varies by about 10 orders of magnitude between the smallest and largest companies, which is such a large scale difference that it becomes qualitative with respect to standards.

This creates divergent incentives. Many companies want to optimize standards for the cheapest thing that will check a box, even if the implementation is ineffective in practice. The minority of companies that actually care about robust and efficient implementation often find this isn’t feasible (and in some cases impossible) within the constraints of what ends up in many of these standards, so they ignore the standards since they are strictly worse than whatever non-standard thing they end up doing.

Wash, rinse, repeat. I have participated in IIoT standardization efforts for almost two decades and it is the same vicious cycle irreconcilable requirements every time.

Secure from whom? I can envision a future where the real IoT security risk is insider threat. Buried in your smart lightbulb EULA there could be consent to be used as a residential proxy.

> Secure from whom?

From the person who thought the sale was ownership. More often, "sale" is 'trade green paper for a license of this physical good, that they retain to do whatever with later at their leisure'.

Look at the scam Nintendo is doing with the Switch 2:

Games no longer have any data other than a serial number to download a game.

Hi tendon claims they can remotely destroy consoles they deem 'modified'. Not 'removed from online play', actually full digital destruction of device.

I support ownership, not this 'we may revoke at any time' licensure.

> Hi tendon claims they can remotely destroy consoles they deem 'modified'. Not 'removed from online play', actually full digital destruction of device.

This is illegal in many jurisdictions.

I would believe you, but we've seen PlayStation 3 OtherOS play out. In that case, Sony sold it with 'install Linux' as a feature. Later on, they poison-pilled an update and killed that.

There was a lawsuit, in which class action plaintiffs got between 9$, or $55 if you said you used OtherOS.

But if this was any of us, hacking Sony, we would be rotting in prison. But Sony can hack millions of peoples supposed property, and "here's your latte money, too bad, so sad!"

This should have been a criminal trial, in which the executives would go to prison, firmware should be rolled out to reenable it, and make people actually whole.

So yeah, I fully expect Nintendo to remotely destroy hardware, and get away with it. The concept of "you don't own, but you license" is the toxic shit that allows this, alongside DMCA 1201.

> This should have been a criminal trial

The laws should support such a charge, but they don't. At least not everywhere.

It doesn't need to be mentioned in the EULA.

Industrial IOT is mostly secured through network segmentation. There is a lot to hate about this fact.

However, by career I deal with a lot of embedded devices. Embedded is where the hell begins. Embedded plus standards is pretty bad. SCADA and others. Embedded plus standards plus vendors .. now you are doomed. The half-assedness of embedded systems security is worse than any normal coder can imagine.

Basically the IIOT domain is the one place that remains where network segmentation and encirclement and so on are the only things we have that work. The worst best option.

You'll know full-on no-engineer-required AI is here when you can point an AI at an IoT device and say "hack it", walk away for 30 minutes, and come back to a hacked device.

I'm not even being sarcastic. Most of them aren't that hard to hack now as it is; I know a guy who broke at least two devices in under an hour each because that's how bad they are. A piece of junk that goes out today that maybe still flies under the radar and nobody bothers to hack it isn't going to fly under the radar in a world where there's 10, 20, 50 times more "software engineering" power in the world, in the hands of a lot more people. In 5 years those things are going to be a nightmare for their owners, for their manufacturers, for all kinds of people.

Finding a novel exploit against a device is kind of a reach right now, but if you give it a device with public unpatched vulnerabilities that were present in the AI's training data, emitting code to exploit them given arbitrarily many attempts is the sort of thing it can already do.

I can't take any article about IoT security seriously if it doesn't mention the inability to secure the internet connection with SSL. We're practically forced to use HTTP on some devices instead of HTTPS, because you can't issue an SSL cert to a local IP address.

The correct answer here is an attestation server and an 802.1AR device certificate; this should be used to attest to a remote server returned via DHCP or at a well known address (this sounds evil but a well known address and specific VLAN is the most widely deployed untrusted environment solution that actually works) which uses a long lived certificate for which the fingerprint is TOFU’d by the device. The device can use this attestation and mutual challenge to obtain a certificate (if it needs one) from an authority that other entities trust (which is necessarily not the 802.1AR CA).

"In order to protect users from the scourge of secure LAN traffic, end users should instead blindly add root ca's to their machine. It's also very important every IoT device has constant internet access to keep refreshing its certs, then the end user can finally feel secure." -google/mozilla/apple

This is a technical “solution” which ignores a market and legal problem: There’s no incentive to keep things secure, because the accountability falls on the rank-and-file, but rarely if ever on the actual leaders that all but require insecure incentives.

We have Boeing-level incidents daily, except that it can be swept under.

Not going to happen any time soon because there is no concern about this from the consumer side, no financial incentive from the manufacturing side, and no regulatory pressure from the government (and I have low hopes that any regulatory solutions would actually fix the problem).

>no regulatory pressure from the government

No much, but there is some. Getting rid of default admin/1234 passwords was 100% a regulatory push

Small but important win

What about EU's CRA?

Doesn't really do anything to ensure the end-user truly has ownership over the device and the ability to control what software runs on it. 10 years of security updates is nice (assuming the company making the device doesn't go out of business in that time) but doesn't stop those devices becoming vulnerable after that (and a truly useful device will likely have more than 10 years of useful life). I don't know the specifics of the CRA, but most proposed regulatory solutions I've seen intentionally take control away from the end-user.

The manufacturer is encouraged to open source the product at the end of the life plus the government agencies now have a saying in what is EOL.

If you still sell EOL Products, you have to make sure it is still save, even as distributor.

Take control away from the end-user is a good point, I will keep this in mind.

You are the only one mentioning it.

I think the CRA is the right step in the right direction. Companies can finally be fined when they sell a product that has known vulnerabilities.

This is something that is discussed for years - now we have a definite Law.

And we already see changes: if you install Windows, the first thing it does is to get patches and the start over.

> ... does anyone really want their refrigerator to automatically place orders for groceries?

Yes, actually. I also want the groceries delivered to my door using the services and stores of my choice depending on the items and prices, and for it to integrate seamlessly with my Home Assistant instance without any funny business regarding the API or needing to install yet another bullshit app I didn't ask for.

This is the real reason we don't have nice things. The implementation is always botched by businesses who don't do a thorough job and finish their product. There's clearly a huge chasm between what the customer and the IoT business would consider an MVP. Do it right or don't do it at all.

Any post about IoT security that doesn't mention or link to Shodan (https://www.shodan.io) is missing a lot of context. It's way worse than you think.

Also, with tools like Chip Whisperer (https://www.newae.com/chipwhisperer) the physical security of the hardware root of trust needs to be reevaluated.

I was positive this should have had a (2012) but sure enough it’s a new article.

“Security is the ‘s’ in IoT” was an old joke back then. Still a problem but hardly a new one.

I used to be more concerned with this but the longer ive thought about it the more convinced I get that none of this matters.

Most tech gadgets are a distraction and are about as useful off as on.

Industrial stuff sure, but if someone's internet fridge or smart TV goes haywire, so what.

I think the risk isn't that your fridge is unable to suddenly to phone home about your butter consumption but that it gets turned into a giant botnet or joins some crypto mining pool. Sensors don't have much horsepower but some of those smart appliances have decent application processors.

The issue is that one’s fridge or light bulb becomes a lodgment from which an adversary can launch LAN attacks (e.g. via Ethernet) on one’s more-sensitive devices, such as one’s personal computer (which contains more-or-less one’s entire life: banking details, correspondence and so forth).

I don’t really care if the IoT device is compromised; I do care if it is used to compromise my trusted devices.

This article is specifically discussing industrial Internet of things. And I think it’s a good and instructive article actually.

Please read before commenting.

I did read the article. It was not very good about separating the two cases (for example by saying the total # of IoT devices to sound dramatic while also only listing examples of industrial ones to sound more worrying).

I love and care pretty deeply about security, I run Graphene OS & am trying to switch to Genode / Sculpt sometime this year. I care. But I'm coming to realize that for the 'personal computing' use-case it doesn't matter much for people who aren't nerds.

In any case, the sort of "hardware root of trust" reccomended is an insidious way of going about it.

> Industrial stuff sure, but if someone's internet fridge or smart TV goes haywire, so what

If large numbers of fridges or cars fail to work properly or go haywire at the same time, it matters.

The article also mentions enabling DDOS.

The same with things like routers, any type of infrastructure.

We have increasing amounts of electricity generation and storage moving to consumer devices. Its a good idea and could make the system more resilient if done right, but if it relies on insecure devices it would be a huge systemic vulnerability.

Encryption and non-repudiation to-from any deployed field device back home is analogous to putting a lock and your ID on your front door. It would deter the average "front door unlocked" criminal of opportunity.

When does a device not authenticating itself and all it's comms matter?

Mossad was able to (at great cost, and with an inept enemy) hijack a telecom supply chain to embedd explosives in internet radios.

Were there any operational oversight to simply have these devices call home with signed key challenge, the literal virus OS/code execution/explosive would have at least been caught.

I only bring up THAT example to show that supply chains are as exposed as a bad actor wants them to be.

Fridge could have interesting attack vectors. Say allow temperature peak during evening and night and then lower it before morning. Keep repeating this. You get lot of spoiled food and worst case even dead people.

How about home thermostats? Turn off the heating during a snowmageddon, freeze some people to death. Opposite thing during a heatwave.

Or a distributed attack, turn on all ACs of a city, and overload the power grid...

It is impossible to secure IoT due to the awful state of lan security (thanks to google and apple's browser ssl policy). If an IoT device wants to host a web app, or .local page, all https/ssl content is off limits. This is because browsers won't allow a webpage to send encrypted content to a client unless the client has a valid SSL cert. The issue is you cannot issue a valid ssl cert to a lan ip address. It must target a dns address. This means that ALL DATA ON THE LAN MUST BE SENT VIA PLAINTEXT!

It's complete nonsense, and the only workaround is to install your own certificate authority on your network and add it as a trusted root cert. Imagine buying a device from amazon and being told to add their root ca to your machine. No non-tech person should ever be touching root ca's, and is 10x more dangerous than whatever this insane policy is trying to protect us from.

I believe all IoT devices should exist beyond a virtual airgap, and the router should by default, prevent the device from communicating with the internet. In order to send data to-and-from the cloud, it should pass through some kind of intelligent/auditable gateway. One that the router maintains, and can be updated independent of the devices.

>How to secure IoT devices

Do not buy them and avoid built in ones at all costs.

Maybe at some point newer ones can be secured, but I doubt it.

Nevermind thousands have already be installed. People cannot be bothered to update their phones or computers, those updates are rather easy. Who will be bothered to update their IOTs ? Plus 2038 is coming quickly, good luck to people who have 32bit IOTs. Do 64bit IOTs even exist ?

>it’s up to system integrators, who are responsible for the security of an overall service interconnecting IoT devices, to require the features from their suppliers, and to coordinate features inside the device with external resilience and monitoring mechanisms

So we give integrators access to our devices ? How is that security ? Also what if these integrator's company is purchased or goes out of business ?

Yea, it's not security and it's not how this shit works in practice either.

"You by device that does a, b, and c"

Device updates.

"You now have device that does a, b, and d"

You ask what happened to c?

"You need to buy a new device to get feature c"

Imagine if electrical devices were locked down in this manner. You'd only be able to use appliances that the outlet manufacturers approved. If they went out of business, you'd have to have your house wiring stripped and replaced. The local utility would also get a vote.

It's obvious to me that this model is unacceptable.

A better choice is to ensure that internet stacks are secure in hardware, not software. This is how power is distributed. Internet connectivity could be secured the same way.

Then you could use anything you want without worrying about confused software or hackers, in the same way you can plug in anything to any outlet without worrying about burning the house down.

It's so disappointing from IEEE to be arguing against user's freedom to own their devices.

Supply chain attacks concerns are infinitesimally smaller than manufacturers writing buggy, unmaintained software / firmware.

We should instead argue for open software / firmware, or at least local control only (if desired). Also solves the problem of billions of e-waste devices whenever manufacturers go under or shutdown their servers, or moves them behind new paywalls / adwalls.

They aren't arguing that, they're promoting defense in depth.

Reply on news.ycombinator.com