Secure firmware updates are intricately tied to the secure boot. (It is recommended to review Secure Boot Solutions Brief prior to this solutions brief.) For updates, the steps are as follows:

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).
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 update software is loaded, and the update’s Binary Large Object (BLOB) payload is verified by checking its signature.
7. An update key is generated to de-crypt the payloads.
8. The update is re-encrypted with the device’s diversified key (see Secure Boot Solutions Brief), and stored to the specified location.
9. The device then attempts to perform a Secure Boot process as normal with the freshly applied update.
10. Following the Secure Boot process, the shared memory and SecEdge CoreTEE™ is established, and Rich Environment functions, such as UBoot and Linux kernels, are loaded.

EmSPARK™ also provides a payload verification API for validating application updates. This API can also be used by Linux to validate an update package prior to initiating the update process. This allows for validating the integrity of the update package prior to initiating the reboot.

The payload validation process is shown below: