Top three requirements for OTA software updates for IoT | Hacker News Reader

Top three requirements for OTA software updates for IoT

mender.io

19 pointschaknam10 comments

I think these goals are necessary, but not sufficient, solutions to the IoT security nightmare. In particular, they miss the biggest problem that leads to these problems -- manufacturers simply do not care.

Many (most?) companies making IoT systems not only don't care about making sure their OTA update systems comply with these constraints, they probably don't even care about implementing any update system at all.

Then, even in cases where (rudimentary) update systems exist, such as consumer-grade routers for example, the time frame for when updates are actually available is laughably small -- perhaps 12-18 months after the device's launch?

Approaches which focus on the technical challenges of OTA updates (a key area of my doctoral thesis, and one I care deeply about!) miss the mark, in my opinion, because the primary reasons why we've ended up in this mess in the first place is due to business challenges, not technical ones.

Until consumers actually care about their devices being updated, or legislation arrives to force businesses to care even when consumers don't, improving technical solutions to the problem is putting the cart before the horse.

While this article does do a good job of illuminating the potential challenges, it's a bit frustrating that there's such scant discussion of solutions.

IMO, this problem has been solved pretty comprehensively by the TUF framework[1], which has a number of solid implementations[2][3]. Many of these implementations even have reliable third-party reviews, so should be pretty trustworthy.

[1]: https://theupdateframework.github.io/ [2]: https://github.com/flynn/go-tuf [3]: https://github.com/theupdateframework/notary

For a solution geared more towards the automotive use-case involving multiple vendors, see Uptane[1], a customization of TUF. The IETF is also working towards a standard for IoT updates[2] which I've found helpful.

[1]: https://uptane.github.io [2]: https://datatracker.ietf.org/wg/suit/documents/

The solution that the article authors want is for you to buy their service.

Not sure if I agree with the 'Scalable' section of the article.

As an embedded Linux developer, I appreciate why a company might want to push updates autonomously to their product. But as a customer, I want to choose when/if my device gets updated. I don't want some company to break my device without me knowing about it.

Maybe the right answer is to give customers the opt-in ability to get automatic updates.

When buying smart devices for your home, just remember folks- the 's' in IoT stands for security.

My reflexive answer before reading the article: "security, security, security." After all: https://news.ycombinator.com/item?id=22119439

I don't disagree with the list though I'm not sure I would have used "robust" to describe "don't brick the device!" And is scaleability really that big of an issue for updates when these can be delivered via CDN? Just sign the update with the right cert, no?

Nearly all iot stuff we make at work are air gapped, used on ski places or in industry with strict firewalls etc. CDNs are basically impossible there since even if we could allow a single ip to be routed through from Wan to the iot device, since CDNs don't have a fixed IP

It is more nuanced than that. In a simple system this may be better than nothing, but consider what happens when the key that was used to sign that update has been compromised.

Or, consider how an update with multiple payloads could be delivered, if each payload comes from a different vendor.

Or, consider how a device can trust that an update has been signed by both someone authorized to make a release, and by someone who actually wrote the code in the release.

I've found the elephant(s) in the room are key management, certificate revocation, and establishing a chain-of-trust from end to end.

These are all problems that cannot easily be solved through one library or service because they fundamentally involve the humans at your company taking responsibility.

Additionally, the article hints at Secure Boot, but a device must also be able to reject old patches, invalid combinations of patches, and untrusted patches - failing to boot _after_ an unsigned update is not a good user experience.

Reply on news.ycombinator.com