Safety-certified tools Tools for Automotive Applications C-STAT Static analysis C-RUN Runtime analysis Debugging and trace probes
As the Internet of Things (IoT) proliferates, billions of cloud-connected devices are expected to be designed, manufactured and deployed over the next decade. However, the challenges are growing, requiring ever-increasing efforts to prevent hacking of connected devices and protect critical data and intellectual property. The industry is rapidly converging on best practices for keeping next-generation IoT devices safe by demanding a robust “chain of trust” across the entire product lifecycle.
At Secure Thingz, we believe there are three critical areas to consider when applying trust across the supply chain to create a chain of trust:
In a previous article, we addressed how Secure Development is the first step in creating a chain of trust and discussed the role of the Secure Boot Manager (SBM) in the MCU device. In this second part of the series, we will discuss Secure Mastering of the software image that will be accepted by the SBM.
Delivering security-oriented, embedded systems is a major challenge today. A "supply chain of trust" includes silicon vendors (MCU device), embedded software companies, programming solutions providers, and OEMs who develop the end IoT products. For truly secure products, the only real solution is to develop a "zero trust" approach across the supply chain to minimize vulnerabilities and continually authenticate and individualize deliverables as far as possible. The chain of trust can be thought of as a process flow, where any step in the process depends upon the security of the previous step. A simple flow of trust is required to engender security starting with the MCU device, progressing to how the OEM provisions the device, then advancing to how the product is programmed and manufactured.
Secure products need to be architected and implemented with the correct OEM security framework which encompasses the root of trust, management of secrets and secure services offered, and the operating system and applications. Ideally, the OEM provisions the MCU with a Secure Boot Manager along with the OEM keys that are used to load all firmware and software into the MCU, immediately ensuring that the product has a unique identity and that all software loaded into the MCU has a known providence. Any firmware or software image that is to be loaded into the MCU must go through a "Mastering" process where the image is signed and encrypted.
Inhibiting intellectual property theft, reducing over-production and cloning, and undermining counterfeiting are the key goals of the secure manufacturing process. To achieve secure manufacturing, it is therefore fundamental to encrypt the application software as early as possible and only decrypt the software in-situ in the device itself, securing as many touch points as possible. While simple in theory, there are multiple aspects that must be secured, including the device itself, how we master the application, how we handle and share the keys securely, and fundamentally how the application is loaded in to the device.
The OEM that designs the product develops the application software and may want to target it for a specific product or family of products. It also specifies some type of personalization or versioning for the software. To assist with the development of security, the software IDE can help establish security certificates and key hierarchies that are used to provision the SBM and MCU device. All OEM personnel developing the product software should be authorized. To enable secure manufacturing, only a limited number of personnel should have the ability to configure and master the software image that will released to production.
The mastering process itself accepts the application software image and encrypts the image with a secure Advanced Encryption Standard (AES) key, then creates an Update Key Block (UPK) containing the AES key and version info that is signed with a unique cryptographic mastering key and encrypts the image with other product specific keys. The mastering key and other keys must be handled securely to prevent third parties from having access to it, and it is optimal to incorporate a solution that integrates a robust hardware security module (HSM).
The mastering may utilize specific device identifiers, such as UUID or device type identifiers, if engendered by the silicon vendors. However, for initial implementations, it is presumed that these need to be provisioned at the secure programming center.
The output of the mastering process is a pair of encrypted files that are loaded into a secure manufacturing process. These secure files can only be decrypted and verified by the Secure Boot Manager that was provisioned with the corresponding master key and product keys.
The threats to connected devices are only increasing. For a truly secure device, a "zero trust" design philosophy across the supply chain is required. After security is architected and implemented into the design of a device, it is still essential to encrypt the application as early as possible, and only decrypt the software in-situ on the device, securing as many touch points as possible to achieve secure manufacturing.
Secure Thingz is a founder member of the IoT Security Foundation where many “"Best Practice" guidelines are currently being deployed.
This article is written by Secure Thingz, a leading provider of advanced security solutions focused on the IoT.
For more information about Secure Thingz, go to www.securethingz.com