Are your Firmware and Application Updates Secure?

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.

About the Author

Philip Attfield, Chief Technology Officer

Philip Attfield

Philip Attfield is the CTO of SecEdge Inc. He brings a strong background in computing, networking, security and systems modeling. He has more than 20 years of industry experience in large enterprises and small entrepreneurial firms. Starting his career at Nortel, Phil was a member of its scientific staff and developed software tools and in-house products for modeling, synthesis and verification of telecom and network equipment hardware.

IoT Security and the Protection of IP at the Edge

We are witnessing a true wave of innovation at the network edge. According to Enterprise Management Associates, more than 60 Billion smart devices are expected to be online in the coming years. Even more exciting is the level of processing power and intelligence being implemented in smart IoT devices. Systems like factory and building control systems, medical devices, autonomous vehicles and machines, and solutions for the home will be applying machine learning (ML) and artificial intelligence (AI) at the edge in unprecedented volume. In fact, Gartner predicts that edge computing will process 75% of all data generated. The capability to make our industrial world smarter, safer and more efficient is increasing exponentially.

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. There inherently must be also more interconnectivity built into the products with a need for access to the internet to receive critical updates to AI models, firmware or file systems. 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.

IoT device developers need to ensure their products are protected from attacks, safe and secure through the manufacturing process, and able to be managed securely throughout the life of the product. Without the appropriate implementation of IoT Security, vendors risk damage to their products, credibility and brand, as well as the loss of critical intellectual property. At the forefront of this critical approach is the protection AI models at the edge.

The approach for protecting AI models (verifying that the model is authentic and hiding it from threats) on a smart device can vary, depending on the nature of the hardware and its application. Factors to consider include:

  1. The memory available to house and encrypt the model or application.
  2. The level of risk in the surrounding environment (for example, will the model coexist with other less trusted applications on the same device?
  3. The hardware being used to  execute the application (for example, is a GPU involved in run the AI model and deliver an inference?)

After understanding the environment, developers can protect AI at the Edge with an approach optimized for need. Here are some examples of best practices.

Encrypting the Application at Rest. This method protects the model while it is not being actively used by the device. This approach involves storing and encrypted version of the model in non-volatile memory. Whenever the model is needed, it is authenticated and decrypted. Once the inferences are complete, any un-encrypted data is removed from volatile memory. This greatly reduces the time the model is exposed as well as the associated attack surface.

Isolating the model using Arm® TrustZone®. In an Arm TrustZone architecture, it is possible to house sensitive portions of the model in a secure partition of memory, or secure enclave. Using this approach, the model is never exposed to the non-secure application environment (e.g. Linux). This method requires allocation of memory in the secure area and some development time to build the application to the secure enclave specification, but is the most secure way to protect AI models.

Enabling a Model accessing multiple hardware blocks and run-time environments using virtualization. If dedicated hardware is used to run the model—for example, a GPU—the model may be housed one virtual environment (e.g. Linux) and accessed by another environment another environment with access to the hardware (GPU) for processing and generating inferences. Using virtualization, the application can be authenticated, decrypted, and then run in a dedicated environment, housed in an isolated virtual machine. The running model can only be accessed by the isolated environment with access to the GPU and inferences are sent securely to the run-time environment which houses the encrypted model.

Because there are a vast number of potential IoT security threats to endpoint devices, manufacturers and integrators must remain focused on their search for best-in-class security strategies and products capable of locking down their products, as the IP contained within simply cannot be compromised. AI model protection methods like these bring security to smart devices, and enable a new era of intelligence at the edge.

About the Author

Philip Attfield, Chief Technology Officer

Philip Attfield

Philip Attfield is the CTO of SecEdge Inc. He brings a strong background in computing, networking, security and systems modeling. He has more than 20 years of industry experience in large enterprises and small entrepreneurial firms. Starting his career at Nortel, Phil was a member of its scientific staff and developed software tools and in-house products for modeling, synthesis and verification of telecom and network equipment hardware.