Smart Locks Bricked by Bad Update? The Right Approach!

I read some news (ExtremeTech, Techcrunch) about how “smart” wifi-connected locks sold by Lockstate got bricked by an automatic over-the-network update. This sounds bad – but it is bad for a good reason. I think the company should be lauded for actually having the ability – and laughed out for royally botching it.

ExtremeTech in particular made it sounds as if this was the worst idea ever to have a lock get updated. I beg to differ – anything that is:

  • Internet-connected
  • Contains a processor
  • Runs a software stack

…must be possible to update since they will have bugs and they will have security issues. IoT devices must be possible to update, just like a phone or PC or server or any other computing system.  Updates delivered over the network directly to the devices are the only way it can be made to work reliable. You cannot ask users to download separate updates and somehow apply them physically.

Thus, having the locks (and anything else IoT) being updated in this way makes sense. The execution is a bit lacking, though… having an update hit the wrong type of device indicates that the validation of updates at the receiving end is missing or failing to do its job. The update server should also know which devices to target, but you need checks at all points in the update chain to avoid mistakes.

That is an interesting part of the product feature set of IoT device management tools – making sure that updates work is among the trickiest things to get right.  The enormous efforts that big companies have put into this (Apple, Google, Microsoft, …) have gotten us used to updates just working.  So when they do not work, people are up in arms.  For a computer, at least you can usually coax it back to life. Not so much for a limited-interface embedded IoT device.  Thus, IoT updates have to be even more perfect than those that Microsoft ship every month.

Terrible Idea

What is a terrible idea, though, is to have an Internet-connected lock in the first place.  Since we know it will have security issues, we can be sure it will either end up being cracked open or cracked dead (in this case, the company did the dead part themselves).

Update+clarification: As pointed out in the comments, these issues will also hit phones and computers… but it is arguably more dangerous to get physical things in your proximity hacked. It is also way more avoidable since Internet connectivity is not exactly a key feature in a door lock…

A lock is a classic device to keep mechanical, air-gapped, and not on the network in any way.  If you want to be able to hand out temporary access codes to a keypad lock (which sounds like the insane application here), do it by local access to the lock.  Like over a USB cable to the lock directly.

It sounds good to make it easy to configure a lock and manage it on a phone or computer. Citing the Lockstate homepage:

RemoteLock 5i smart locks solve the problem of remotely managing properties. This robust WiFi enabled door lock allows users to lock or unlock doors remotely, know when people unlock your door, and even receive text alerts when codes are used. Issue new codes or delete codes from your computer or phone. Even give temporary codes to guests or office personnel.

Basically, the lock is on the Internet to make this happen. I.e., it will be hacked.

3 thoughts on “Smart Locks Bricked by Bad Update? The Right Approach!”

  1. I think your argumentation is flawed. First you equate the lock with phones and laptops, saying that they should receive automatic updates over the internet since they will have bugs. Then you say that the lock will have security issues that will either break it or brick it, but somehow that is not true for the other two classes of internet-connected things (phones and laptops). What’s the inherent reason that they should fail, and that they should fail more than phones and laptops?

  2. Good points. I am not saying that locks will fail more, necessarily. Just that the consequences feel worse while also being rather avoidable. I guess the argument I am making is “if it is on the net, it has to be updated — but does it actually have to be on the net??”.

    There is also the question of the “if it is software-driven, and not on the net — should it be on the net to be updateable??”

Leave a Reply

Your email address will not be published. Required fields are marked *