What are the best security practices to follow when issuing an OTA update to a fleet of IoT devices? What are the significant causes for concern?

For example,

  • preventing an update from being intercepted
  • following established standards
  • platforms for software distribution
  • automatic updates v.s. optional updates
  • 5
    This question is too wide to be a good fit for Q&A. Dec 6, 2016 at 18:46
  • 1
    @SeanHoulihane, I have narrowed down the focus to security of OTA. How does it look now? Dec 6, 2016 at 18:50
  • 2
    It's still pretty broad as each bullet point can be a full stand alone question of its own. Even just for the last bullet point of testing the successes you could write a whole book about it.
    – Dom
    Dec 6, 2016 at 18:51
  • thanks for the input, I will split these into separate questions. Dec 6, 2016 at 18:56
  • 1
    edit the title too? Dec 6, 2016 at 21:22

1 Answer 1


That question is too broad, but given that you omitted the single most important thing, I feel I need to pipe up.

Authenticate the update.

If you want to make sure that your devices are running your code, then you need authentication, not encryption. Encryption ensures that other people can't know what's in your code, and that's hard to achieve and rarely useful. (You can encrypt, but if the decryption key is on the device, you didn't gain anything unless you have a way to protect the decryption key that doesn't let you protect the code directly.) Authenticity is the property that other people can't produce a fake update, and that property is usually desirable.

Note that encrypting does not help with authenticity. This is a false belief that people who don't really understand security sometimes have, but it's just not true.

For some devices, it's fine to run any firmware if the owner so chooses. In that case, you still need some mechanism to ensure that only the owner of the device can install firmware, and not some random passer-by. Generally that means that the device must authenticate the update as coming from the registered owner.

  • This is not really correct. Encryption is neither very hard to achieve nor is it only "rarely useful". Furthermore, that encryption "does not help with authenticity" is only semi-true. Most modern encryption modes,like GCM, are actually so called "authenticated encryption" schemes, which combine authenticity and confidentiality.
    – mat
    Apr 4, 2017 at 8:08
  • @mat I've changed that sentence to be formally correct. Encryption is not hard, but I was refering to confidentiality, which is hard. Encryption doesn't give you confidentiality if you aren't able to keep the key confidential. Encryption does not help with authenticity at all. If you use authenticated encryption, it gives you both, but the fact that it includes encryption does not help in getting authenticity. Apr 4, 2017 at 10:56
  • If your key gets leaked, every crypto looses its usefulness, be it for confidentiality or for authentication. If it makes sense to use encryption with an unprotected key on the device, depends on your threat model (accesibility of the device, abilities of the adversaries)
    – mat
    Apr 4, 2017 at 11:14
  • @mat No. I should have reacted to that GCM remark in my previous comment, in fact. GCM is not a decent way to broadcast updates, because it means authenticity is checked with a class key. Unless you're making a highly hardened platform (e.g. smartcard), a class key is as good as public. Updates should use asymmetric cryptography. That way, to deploy a fake update to a device, that particular device needs to be breached: to produce a fake update that works everywhere, the attacker would need to break the server or the protocol and these are typically better protected than devices in the field. Apr 4, 2017 at 12:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.