Are Your Connected Device Firmware and Application Updates Secure?

Both manufacturers and consumers seek to enjoy the value that comes from the deployment of “smart” devices, either on the functionality or revenue side. However, when those devices include proprietary ML and/or AI within the device or system application(s), protection of critical intellectual property should be the top priority to ensure long-term viability. These devices become especially vulnerable when performing firmware or application updates. Philip Attfield, CEO, Sequitur Labs, details the key principles to follow when ensuring safe and secure updates across the smart device ecosystem.

According to Enterprise Management Associates (EMA), more than 60 billion smart devices are expected to be online in the coming years. While this development is exciting, it underscores the ever-increasing importance of security at the network edge. The increasing proliferation of connected IoT devices performing mission-critical tasks means that there are more vulnerable access points than ever.  

To enjoy the benefits provided by “smart” devices, especially those implementing ML and AI in their applications, it becomes vital to protect the critical intellectual property that represents a large part, if not all, of the solution’s value. There must inherently be more interconnectivity built into the products with a need for access to the internet to receive critical updates to firmware or functionality. While the data center may be thought to be safe from outside intrusion, IoT devices are far more exposed, making them an ideal entry point for those looking for an easier way to exploit systems. One particularly vulnerable instance is the time at which a device is performing a firmware or application update.

Firmware and application updates are inherently tied to the device boot process. A secure boot process authenticates the software and identities a device when it is powered on. Secure boot uses encrypted firmware images, which protects them while stored in non-volatile memory, whether or not the device is powered on. This process requires several stages of authentication, protection, and encryption/decryption to ensure that the device is secure. 

Learn More: Secure the Weak Points in Critical Infrastructure Environments Before It’s Too Late

A common misconception is that a device is secure if its first software payload, loaded by read-only memory (ROM), can be authenticated. This is, in fact, only the start of a truly secure boot process, which also includes:

1. Partitioning memory into two areas (Secure and Non-Secure). The secure area will house sensitive elements like keys, certificates, and encrypted applications.
2. Setting up the secure area using a dedicated operating system (called a Trusted Execution Environment, or TEE) and loading all relevant elements into the secure area. 
3. Setting up the non-secure area and executing the process of authenticating and decrypting the operating system (e.g., Linux Kernel), followed by the same process for device applications.

Learn More: Physical Device Security Is Vital in the Remote Work Era

Ensuring Safe and Secure Firmware and App Updates

These principles can be applied during product updates to authenticate firmware and applications and protect critical intellectual property from malicious attacks.

1. A device application manages a schedule or set of events that determine that an update will be performed.
2. When prompted for an update, the device performs a reboot, with boot state variables signaling that the device will follow an update process prior to the secure boot process.
3. The read-only memory (ROM) then loads and verifies the secondary boot loader (SBL), which will load the updated software.
4. The device determines by memory, then registers and holds the boot state variable and reset status, thereby facilitating the boot process update.
5. The device locates and reads the payload in the update location.
6. The Secure Boot steps described above, where memory is partitioned and both secure and non-secure areas are set up, new software verified, de-encrypted, and loaded, are followed.

Following this process, the device can execute a firmware or application update safely and securely. This process can be executed locally, over an enterprise network, or through a cloud service.

An IoT device must be maintained to remain useful. To ensure that the device is running as intended throughout its lifecycle, firmware updates, administered locally via a network or Over-the-Air (OTA), are essential. Keeping these principles in mind ensures safe and secure updates for the administrator’s fleet of devices.

Let us know if you liked this article or tell us on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!