Brick or Bot? Solving OTA update issues

Auto updates have been hailed as one of the best ways to secure IoT devices, solving the issue of ‘fit and forget’ devices or user tardiness. The Ring doorbell we investigated is good example, as thanks to the auto update feature, a patch was issued that automatically fixed the issue across the entire installed base overnight. But the auto update process itself can be fallible, and there’s plenty of instances where patches have gone awry.

Take the LockState 6i door lock which the vendor updated last week. Except the update pushed out was for the newer 7i model and proved to be incompatible. The result? Remote access to 500 door locks was disabled, effectively bricking an entire product line. The only fix users were offered by the vendor was to detach and return the back of the lock for a firmware update (5-7 days) or request a full replacement (14-18 days).

The vendor appeared to attempt to keep this quiet whilst resolving the problem, though it was quickly flagged:

Both ‘solutions’ posed a real problem for users who had purchased the lock through Airbnb partnership, Host Assist. Suddenly they couldn’t let in their Airbnb renters or cleaning or maintenance staff and to make matters worse their property could be in lock down for nearly three weeks.

The story saw some question the legitimacy of auto updates which don’t request the user’s permission with one reader commenting: “You don’t know how I’m using my product (well you damn well better not), you don’t update my hardware that I bought until I say you will”. And they have  a point.

But if you leave it to users to update, most won’t

The downside is that any delay to patching could see these devices commandeered by a botnet or infected with malware. It’s easy to push an update to users, but a significant proportion simply won’t bother applying the update

Even Apple users, who arguably have one of the most mature update processes, including OTA updates since iOS 5.0 back in 2011, still fail to update. Four years later, one survey found that nearly half of devices on corporate networks were not using the latest OS, while Apple itself reports 10 percent of devices are running iOS9 and 3 percent even older iOS, as opposed to the current version iOS 10.3.3. Some of this will be to do with old unsupported hardware, but that doesn’t resolve the issue.

Unpatched devices have been a headache for the PC industry for decades – witness the recent spate of ransomware which was able to take advantage of unpatched systems – so it hasn’t yet found the solution, and withdrawal of support has always been an issue in the PC market.

So if many users fail to apply updates and we don’t want to auto-push updates, what do we do?

Keep me in the loop

I quite like the approach that Tesla have, allowing the user to set a convenient time to update, not dissimilar to the Apple update options. Others make the update alerts ‘nag’ the users more and more, making it harder (but still possible) to dismiss them.

There’s some logic in a user delaying an update by a few days. That way, a ‘bricking’ incident will affect fewer users: initial issues can be flagged and the vendor can pull the update before it becomes a systemic problem.

The percentage affected is less and that buys the vendor time to respond (hopefully with quicker turnarounds than in the LockState scenario) and to resolve the issue with a fixed update rather than an expensive hardware replacement.

The downside of delaying any update is of course that once an update is issued, the security flaw is known

Unpatched = unprotected

Unless IoT updates involve the user in the process, vendors risk bricking their product AND alienating their user base.