Posts in category: Firmware

According to Enterprise Management Associates, 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.

In order to enjoy the benefits provided by “smart” devices—especially those implementing ML and AI in their applications—it becomes critical to protect the critical intellectual property that represents a large part—if not all —of the solution’s value. A need for access to the internet to receive critical updates to firmware or functionality inherently requires more interconnectivity to be built into the products. 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 determines how a device is identified, authenticated, and started up when it is powered on. Secure Boot also includes the protection of the firmware images stored in non-volatile memory whether or not the device is powered on. This process requires several stages of authentication, protection, and encryption/decryption, in order to ensure that the device is secure.

A common misconception is that a device is secure if its first software payload, loaded from 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 this 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.

These principles can be applied during product updates to protect 1) authenticate firmware and applications, and 2) 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 re-boot, 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 (SPL), which will load the updated software.
4. The device determines—by memory and registers holding the boot state variable and reset status—that the boot process is an update.
5. The device locates and reads the payload in the update location.
6. The Secure Boot steps described above, in which memory is partitioned, secure and non-secure areas are set up, and the new software is 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 at peak performance 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 your fleet of devices.