Tuesday, August 22, 2017 [Tweets] [Favorites]

What You Can Learn From LockState

Mark Bessey:

The root cause of this incident was apparently that LockState had produced an update intended for one model of their smart locks, and somehow managed to send that to a bunch of locks that were a different model. […] It’s trivially-easy to avoid this issue, using a variety of different techniques. Something as simple as using a different file name for firmware for different devices would suffice. If not that, you can have a “magic number” at a known offset in the file, or a digital signature that uses a key unique to the device model.

[…]

Every remote firmware update process should have the ability to be tested internally via the same process end-users would use, but from a staging environment.

[…]

Tying into the previous point, wouldn’t it be great if you could measure the percentage of systems that were successfully updating, and automatically throttle the update process based on that feedback?

Comments

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment