Keywords: security, embedded, authentication, integrity, boot, download, cryptography, secure boot, digital signature, root of trust, ECDSA
The Fundamentals of Secure Boot and Secure Download: How to Protect Firmware and Data within Embedded Devices
As IoT devices proliferate our lives, the perpetual attempts to maliciously gain control of them also expands making adoption of embedded system security for device protection imperative. Take for example, the threat posed when a hacker attempts to modify the IoT device firmware or operational configuration data. The authenticity and integrity of the firmware and data used by these devices can generally be considered safe and secure during the manufacturing process. However once installed in the field, the devices can be exposed to hacker access or might periodically need firmware or configuration data updates. Access or updates provide the possibility for an intruder to modify the behavior, or even worse, take complete control of these devices with potentially disastrous consequences. One such type of attack is called malware injection. This involves the insertion of malicious code into the source of the firmware update. Once an attacker has succeeded in installing a fraudulent piece of firmware, this unauthorized configuration can:
To ensure that the target embedded device runs only authorized firmware or uses only authorized configuration data, we need to provide a way to verify both authenticity and integrity of the information. This means making sure that the data is trusted and not subsequently modified. Utilizing cryptographic digital signatures, like putting a seal or a manual signature at the bottom of a letter, enables this.
With this method, the firmware or configuration data loaded during the manufacturing phase and all subsequent updates is digitally signed. This way, the digital signature enables trust during the device's entire lifetime. A strong digital signature must be computed by a cryptographic algorithm. To bring the highest level of security, the algorithms need to be public and well proven. Here we consider asymmetric cryptographic algorithms, specifically the FIPS 186 Elliptic Curve Digital Signature Algorithm (ECDSA).
In asymmetric (public-key) cryptography, mathematically related key pairs (a public key and private key) are used for algorithm computations. As the term suggests, the public key can be known to any entity without introducing security risk. The private key, however, is critically confidential information that can never be released or known. The fundamental principle of secure download based on asymmetric cryptography is that the firmware developer uses the private key for signing, while the embedded device stores and uses the public key for verification. In contrast to symmetric-key cryptography, the main advantage of asymetric cryptography is that the confidential element (i.e., the private key for signing) is never stored in the embedded device. Hence, when using ECDSA there is no way an attacker can retrieve the private key used for signing firmware and data, despite using sophisticated invasive attacks. All the attacker can get from the device is the public key, and with ECDSA it is mathematically infeasible to derive the private key from the public key. This is a fundamental benefit of asymmetric cryptography.
Figure 1 presents the use of secure boot and secure download based on asymmetric ECDSA, which provides a high level of trust if the key length is adequate (typically a minimum of 256 bits). As shown, there are two aspects to the solution. In a R&D facility, where firmware or configuration data are developed or produced, an ECDSA key pair is created—the system private and public keys. Firmware or data to be protected are signed in the development of controlled environment with the system private key. As shown in Figure 2, the FIPS 180 SHA-256 algorithm is included in the crypto-data path resulting in the ECDSA signature being computed on the SHA-256 hashed value of the firmware image or data file. In practice this signature result is computed and appended to the firmware or data file at the R&D Facility as shown in Figure 1. It is this signature of the SHA-256 hash that enables resources in the end application to verify both authenticity and integrity of the firmware or data file. For the field usage, the end-application processor would have internal or external resources available to first perform a SHA-256 hash of the firmware or data file and then, using this computed value and the accessible system public key, verify that the appended ECDSA signature is valid, see Figure 3. If this verification check is successful, the firmware or data file is guaranteed to be both authentic and unmodified.
Figure 1. Use of ECDSA for secure boot and secure download.
Figure 2. ECDSA signing of the firmware/data file.
Figure 3. ECDSA verification of the firmware/data-file signature.
Clearly, a properly secured boot or download process would allow only authorized/authentic firmware to run on an embedded device; thus, preventing malware injection, even during firmware updates. Challenges associated with the process include:
For embedded systems that do not have a secure microcontroller with the computational capacity to perform the calculations required to verify the authenticity and integrity of downloaded software, Maxim Integrated's DS28C36 DeepCover® Secure Authenticator represents a cost effective hardware-based IC solution. Figure 4 illustrates how the DS28C36 can be interfaced to the host processor and a summarized version the operation is explained in the steps below the figure.
Figure 4. Interfacing the host processor to the DS28C36.
Additional description of the above sequence is illustrated in Figure 4. This includes the additional enhanced security step that enables the host processor to validate the secure boot result through a separate ECDSA sequence.Table 1. Detailed Secure Download Using DS28C36
|Step||Host Micro||Data Flow||DS28C36|
|1||Firmware or data file||→||SHA-256 hash the file using Compute Multi-Block HASH function|
|2||Firmware or data file ECDSA signature||→||Verify ECDSA Signature of the firmware and multi-block hash result, PIO change on success|
|3||PIO result can be detected electrically by the processor, also a logical check through parameter byte.|
|4||Random Challenge||→||Compute ECDSA signature of register data where secure boot logical pass/fail result is stored|
|6||Verify ECDSA result from challenge.
This verifies the logical PIO state set
by the DS28C36 matches physical output feedback value
|7||Firmware proceeds to run after
successful secure boot operation
The MAXQ1061 is a crypto controller that comes with its own embedded firmware supporting:
The MAXQ1061 was designed to act as the root of trust of an embedded connected system. It answers the challenges listed above. Its hardware accelerators enable fast SHA and ECDSA computation and offloads the main processor from these computationally intensive activities. The MAXQ1061 also enables a robust off-line public key infrastructure so that public key certificates can be made either immutable or upgradable only by duly-authorized parties. By making sure a public key cannot be replaced by a fake one, the MAXQ1061 makes the end product robust against attacks consisting of injecting a hacker's public key that would allow a successful verification of an untrusted firmware.
Figure 5. Interfacing the host processors with the MAXQ1061.
The process flow is very similar to the one described above for DS28C36
|Step||Host Micro||Data Flow||MAXQ1061|
|1||Firmware or data file along with ECDSA signature||→||Performs firmware hashing and verification of ECDSA signature|
|2||Firmware or data file ECDSA signature||←||Returns “VERIFY BOOT” command status: OK or fail|
|3||Is reset or receives an interrupt signal||←||Optionally RESET_OUT pin is asserted|
|4||→||Access to objects with “SECURE BOOT” condition is granted. E.g., encryption keys are accessible|
|5||Optionally firmware is sent to MAXQ1061 for decryption||→|
|6||←||MAXQ1061 decrypts the firmware and send the decrypted firmware back to the main microcontroller|
|7||Firmware proceeds to run after successful secure boot operation|
The ability to determine the integrity and authenticity of firmware or a configuration data file that are either installed or downloaded to an embedded system in the field is referred to as secure boot or secure download and is a proven security solution to address related threats that IoT devices are exposed to. Successfully implementing secure boot and secure download in your system can:
Maxim Integrated's DS28C36 and MAXQ1061 both provide system designers with a straightforward hardware solution to guarantee secure boot of firmware or secure download of data to their embedded systems, both in the factory and in the field.
|DS28C36||DeepCover Secure Authenticator||Samples|
|MAXQ1061||DeepCover Cryptographic Controller for Embedded Devices||Samples|
|EE-Mail||Subscribe to EE-Mail and receive automatic notice of new documents in your areas of interest.|
|Download||Download, PDF Format (516.2kB)|
|© May 19, 2017, Maxim Integrated Products, Inc.|
APP 6426: May 19, 2017
APPLICATION NOTE 6426, AN6426, AN 6426, APP6426, Appnote6426, Appnote 6426