Why shared secrets alone are not enough for a commercial-scale OTA firmware update system

Updating firmware over the air (OTA) and securely on IoT devices in the field means your organization will need to put into place key infrastructure components like:

  • A security-aware bootloader on the device;
  • A security-aware application firmware downloader and installer on the device;
  • PC tools for generating secure firmware;
  • Secure key management processes

With that said, what makes an OTA firmware update system secure? Or put another way, what is it that is being protected by outside threats that require this added capability and complexity?

A secure firmware update system is trying mitigate two main threats to an organization's business:

  1. Firmware copying, also known as duplication or cloning.  Unsecured firmware can be copied and used in a competitor product, analyzed for business intelligence or weaknesses to be exploited.  
  2. Device hijacking.  With an ability to install their own firmware on your device, an attacker can turn your devices and your entire network and product line against you in ways you might not even imagine.

Execution of either of these threats can destroy an organization's reputation, competitive advantage and ability to effectively operate. 

A proper secure OTA firmware update system will be able to prevent firmware cloning through encryption (firmware confidentiality) as well as prevent device hijacking through public key cryptography (firmware authenticity).

Both confidentiality and authenticity can be implemented using symmetric cryptography and shared secrets. An example would be the AES-GCM cipher mode.

However, shared secrets come with risks.  Shared secrets offer a huge attack surface to your potential attackers: your entire fleet of devices.   Just one device can be moved into a lab in some far corner of the world, attacked mercilessly with methods you have never heard about (but they do exist), eventually yielding that one tiny little secret - too bad it is shared with all your devices.  Now the attackers can generate their own firmware, inject it into any one of your devices, and begin to carry out the attack.

This should scare you.  It scares me.  This is why shared secrets are not good enough.  They are, however, necessary for implementing the confidentiality portion of the secure product defense.  So yes, any one of your devices can potentially cough up access to an attacker looking to copy or clone your firmware. But with the additional security feature in place that I will talk about next, your attacker will not be able to load firmware onto your existing devices, mitigating a huge threat to your organization's business success.

Asymmetric, also known as public-key, cryptography has a feature that allows a product maker to control who can put firmware onto their devices without placing any secret key material on the devices.  Instead, a public key is placed onto the fleet of devices.  Because this key is "public", it does not matter if an attacker can learn what it is.  Only the owner of the private portion of this key-pair, which is the product maker, can "sign" the firmware in such a way that the devices will accept it.

If an attacker is able to gain access to a device in such a way as to "install" their own public key corresponding to a private key that they control, the best they can do is load their malicious firmware onto that one device.  This is a much, much different situation than if one attack compromised your entire fleet of devices by extracting a shared secret.  Using asymmetric cryptography, the attacker must duplicate the effort on each device.

Security is never a guarantee.  Think of it more as a bar to set for what you are willing to pay in terms of development, implementation, management and product cost versus the likelihood of a successful attack and associated cost to your business should a successful attack be carried out.  

Smart Meters may have a higher security bar than pet trackers.

At the end of this story it is sufficient to say, although no surprise to anyone I'm sure, that Firmware Modules has you covered in terms of implementing robust secure OTA firmware update systems for your next IoT project. 





  • There are no comments yet. Be the first one to post a comment on this article!

Leave a comment

Please note, comments must be approved before they are published