Patent Application
20180081666
With the growing number of deployed IoT devices the importance of secure firmware updating is significantly increased. Gartner, Inc. forecasts that 6.4 billion connected things will be in use worldwide in 2016, up 30 percent from 2015, and will reach 20.8 billion by 2020. In 2016, 5.5 million new things will get connected every day.
All these devices need a reliable firmware update system. The functions of many IoT devices, expected to be operational typically at all times, requires a minimal downtime for service tasks, including firmware update. The present invention provides a solution using parallel updates when all service actions are applied to the clone of the current execution environment with the extensive tests at the end. As soon as the new execution environment is ready and verified, a fast switch between execution environments occurs with the optional configuration synchronization.
A typical IoT device is also expected to be operational for a long time and may warrant or require many updates over its life. A consumer of an IoT solution needs to be able to receive and perform firmware updates for IoT devices to fix security vulnerabilities and firmware errors or add new features. The firmware update should be simple and should provide an easy way to roll back to the previous version if for any reason the update is ineffective. The embodiments of the present invention address these requirements and also allow to return back to the previous version of the firmware at any time.
In November 2015, ARM announced launch of the ARMv8-M architecture with ARM TrustZone technology. It provides developers with a reasonably fast and efficient way of protecting embedded software running on Internet of Things (IoT) devices. The present invention fully utilizes capabilities of the Security Extensions in an innovative way to implement a reliable and secure firmware update for Internet of Things (IoT) devices.
Limitations of the traditional firmware update approaches, compared to the present invention, will become apparent to the person having ordinary skill in the art through comparison of such approaches with the present invention.
The following references identify related art:
[1] Young, Fudally, Montgomery, “Secure Firmware Updates”, U.S. Pat. No. 9,218,178 B2, Dec. 22, 2015. [1] describes a secure firmware update system based on a pre-boot environment. The present invention uses Security Extensions of the hardware platform to provide TEE for firmware update process and is better suited for IoT devices.
[2]I Insyde Software Corp, “System And Method For Updating Firmware”, U.S. Pat. No. 9,235,403 B2, Jan. 12, 2016. [2] describes a firmware update mechanism which uses ROM image to store firmware update code. While this approach provides a reliable protection for the updater code it prevents future updates of the updater itself. The present invention does not have this limitation.
[3]I Keller, Sotack, Hayter, “Failsafe Firmware Updates”, U.S. Patent Application US 2012/0260244 A1, Oct. 11, 2012. [3] describes a failsafe method of updating an electronic device using 3 separate non-volatile memory partitions. The present invention supports multiple dynamic copies of the execution environment and ability to switch between copies at any time with optional configuration synchronization.
[4] Challener, Davis, Springfield, Waltermann, Lenovo Singapore Pte Ltd, “System And Method To Update Device Driver Or Firmware Using A Hypervisor Environment Without System Shutdown”, U.S. Pat. No. 8,201,161 B2, Jun. 12, 2012. [4] describes a system, method, and program for a firmware/driver update of a device using a hypervisor environment without system shutdown. The present invention uses firmware update code running in the TEE to update the whole IoT device OS and not only device drivers or firmware.
[5] Cassapakis Chris , Rao Bindu Rama, Palm Inc, “Updating An Electronic Device With Update Agent Code”, U.S. Pat. No. 8,578,361 B2, Nov. 5, 2013. [5] describes a method of updating an electronic device with update agent code. The present invention runs firmware update code in TEE and applies all changes to the cloned OS without modification of the original execution environment. This process do not interrupt the work of IoT device and requires only a minimal downtime during execution environment switch.
During the switching process a new execution environment receives an access to the real hardware (peripheral) devices connected to an IoT device and becomes a primary environment.
Preferred embodiments of the present invention should have a hardware-enforced Trusted Execution. Environment (TEE). While the main purpose of SoC Security Extensions is isolation between “Normal” and “Secure Worlds”, as those terms are defined in ARM TrustZone use, the present invention provides the innovative approach of using these Security Extensions to isolate and protect firmware update system for an IoT device.
All critical firmware update modules Hardware Access Control (HAC), Firmware Update Service (FUS) (107), and Software Configuration Management (SCM) (108)—are running in the Trusted Execution Environment (102). Internal data (including cryptographic keys, certificates, configurations) of these modules is protected by the hardware Security Extensions too.
FUS provides a functionality to verify Firmware Update Package (FUP) using cryptographic algorithms inside TEE, creates a new (Stage) execution environment, copies existing execution environment into the new one, and applies an update. After successful update the control is passed to the SCM. The SCM is responsible for post update validation testing, configuration backup and restore, and execution environment activation and deactivation.
The SCM performs health monitoring of the Embedded OS Execution Environment. In case of detected problems SCM may initiate rollback to one of the previous copies of the execution environment or to the factory default state if no backup copies exist.
Optionally, the SCM may backup configuration and current state of the execution environment at defined intervals and store it in a separate protected database. A user may use this data later to create a new execution environment or restore a previous version of the environment.
The Scheduler (210) is responsible for parallel execution of multiple execution environments. During the update process of the SEE, the CEE supports normal operation and works in parallel. The SEE can receive significantly lower execution priority compared to the CEE because boot time of the Stage environment is not really important.
Hardware Access Control (209) manages access to the peripheral devices connected to the IoT device. SEE uses device drivers in the emulation mode (213) to avoid collisions.
Optionally an external agent such as the user or service may clone the existing execution environment and activate it without an actual firmware update. This action can be used to create an on-the-fly backup of the IoT device firmware.
During the switching process, new execution environment OS (312) receives an access to the hardware via Real Device Drivers (313) and Hardware Access Control (309) while Backup Execution Environment (301) OS (305) switches to Emulated Device Drivers (306). Later this execution environment can be used for recovery initiated either by a user or automatically in case of detected failures in the new primary execution environment.
After successful update, validation of the new environment and switching between environments, the BEE remains active for the defined interval and works in parallel. The BEE is hibernated or shut down by the Scheduler (310) after receiving a confirmation from the new CEE about successful competition of the switching process.
Optionally, a user or external service can initiate switching between CEE and BEE without an actual firmware update or recovery.
The recovery process can be initiated either by a user or by the Management module in case of detected failures in the execution environment. Optionally, the configuration and state of the execution environment can be restored from separate backup copies created by the SCM during normal operations.
