8

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
Gilles 'SO- stop being evil'
  • 988
  • 1
  • 8
  • 19
Noam Hacker
  • 339
  • 1
  • 9
  • 5
    This question is too wide to be a good fit for Q&A. – Sean Houlihane Dec 06 '16 at 18:46
  • 1
    @SeanHoulihane, I have narrowed down the focus to security of OTA. How does it look now? – Noam Hacker Dec 06 '16 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 06 '16 at 18:51
  • thanks for the input, I will split these into separate questions. – Noam Hacker Dec 06 '16 at 18:56
  • I have made a separate testing question here – Noam Hacker Dec 06 '16 at 18:59
  • 1
    edit the title too? – Sean Houlihane Dec 06 '16 at 21:22
  • done, feel free to delete stuff if its still too broad – Noam Hacker Dec 06 '16 at 21:27
  • This question is still too broad. It depends on the type of device and on your security objectives. If you edit your question to define those, it might become properly answerable. Then ping me to update or delete my answer — I only posted it because you forgot something that's very important in most scenario and often forgotten by people who don't understand security. – Gilles 'SO- stop being evil' Dec 07 '16 at 00:25
  • Not an answer, but a few points to watch out for, FOTA is tough on small, embedded devices. You are going to need (at least) twice as much storage as your application size (or the largest update, if you are also updating parts of your o/s). Remember that you can downgrade, as well as upgrade (e.g roll back a bad new version), which gets even trickier in conjunction with the next point. Don't forget that if you have persistent data (e.g in NVMEM), the layout can change between versions, which requires additional code to convert, which becomes a nightmare when users skip updates or rollback – Mawg says reinstate Monica Dec 07 '16 at 10:37

1 Answers1

10

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.

Gilles 'SO- stop being evil'
  • 988
  • 1
  • 8
  • 19
  • 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 04 '17 at 08: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. – Gilles 'SO- stop being evil' Apr 04 '17 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 04 '17 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. – Gilles 'SO- stop being evil' Apr 04 '17 at 12:19