
Top three requirements for OTA software updates for IoT - chaknam
https://mender.io/blog/top-three-requirements-for-over-the-air-ota-software-updates-for-iot
======
hwbehrens
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.

------
mahemm
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/](https://theupdateframework.github.io/)
[2]: [https://github.com/flynn/go-tuf](https://github.com/flynn/go-tuf) [3]:
[https://github.com/theupdateframework/notary](https://github.com/theupdateframework/notary)

~~~
_caw
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](https://uptane.github.io) [2]:
[https://datatracker.ietf.org/wg/suit/documents/](https://datatracker.ietf.org/wg/suit/documents/)

------
nrclark
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.

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

------
mikece
My reflexive answer before reading the article: "security, security,
security." After all:
[https://news.ycombinator.com/item?id=22119439](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?

~~~
gallexme
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

------
_caw
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.

