要約

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 signature, like putting a seal or a manual signature at the bottom of a letter, enables this integrity.

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:

• Output confidential and sensitive data. If used in the medical industry, for example, malware injection could cause devices, such as a portable health monitor, to inadvertently transmit private medical information. In perhaps a more wide-reaching effort, malicious firmware could make an encryption key accessible to the public.
• Force the device to operate incorrectly. A latest incident is Oldsmar water treatment facility attack, which hacker accessed the software system and increased the sodium hydroxide content from 100 ppm to 11,100 ppm that could cause severe damage to the digestive system.
• Induce unpredictable device behavior. This includes behavior that could threaten human life.

Authentication and Integrity of the Firmware

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).

Asymmetric Cryptography Applied to Secure Boot and Secure Download

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 controlled development 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.

Challenges

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:

• SHA-256 hash—Computing a SHA-256 hash on a large piece of firmware can be time consuming when done through software.
• ECDSA signature verification—ECDSA signature verification is computationally intensive, and in an embedded application, typically performed with a suitable math accelerator resource.
• Implementation—Proper implementation of the cryptography is critical to avoid vulnerabilities that would be discovered and exploited.
• Protection of the public verification key against modification—The public key must match the legitimate private key used to sign firmware or configuration data. An attacker generating its own private key and injecting the corresponding public key into the embedded system would be able to generate its own arbitrary firmware or configuration data and have them successfully verified by the embedded system

Secure Boot and Secure Download using DS28C36

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, Analog Devices' 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.

• As discussed previously, a system public-private key pair for the secure boot or secure download function is established at the R&D facility. The private key of this pair is used to sign firmware, or a data file, that ultimately is verified by the DS28C36 embedded in the end system. This system private key never leaves the controlled development environment. The system public key of this pair is installed and locked in the DS28C36 in a key register location that has an "authority key" attribute; this is a configurable setting in the DS28C36.
• The system private key is used to compute the digital signature of the firmware or data file. As noted previously and shown in Figure 2, this signature is computed on the SHA-256 hash of the data file.
• The Maxim DS28C36 with the preprogrammed system public key (configured with authority attribute) is located on the system board and interfaced to the host processor.
• When firmware is required to be run by the processor, or a configuration data file is needed for system use, it is first retrieved by the processor boot manager and delivered to the DS28C36 in sequential 64-byte blocks to compute a SHA-256 hash.
• After the DS28C36 completes the SHA-256 hash computation, the processor delivers the ECDSA signature of the firmware or data that was computed in the development environment and appended to the file.
• After the DS28C36 receives the ECDSA signature the processor sends commands to use the preinstalled system public key to perform a signature verification.
• If the DS28C36 verifies the signature, a GPIO pin is set to logic 0 and a pass result parameter byte is delivered to the processor. The status of this pin and parameter byte result acts as a go/no-go result to the processor to run the firmware or use the configuration file.

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.

• For an additional level of security and to address the concern that GPIO state change and/or parameter result byte can be spoofed, the DS28C36 can optionally ECDSA-sign an internal state result that indicates pass or fail of the secure boot or secure download sequence. This result is irrefutable.

Secure Boot and Secure Download using DS28C40 for Automotive

Maxim's DS28C40 is an automotive AEC-Q100 Grade 1 qualified secure authenticator. It provides a cost-effective hardware-based IC solution with the ECDSA cryptography to perform the calculations required to verify the authenticity and integrity of downloaded software for connected cars. Figure 5 illustrates how the DS28C40 can be interfaced to the host ECU.

The process flow is identical to the one previously described for the DS28C36.

Secure Boot and Secure Download using MAXQ1061

The MAXQ1061 is a security coprocessor providing a cryptographic toolbox supporting:

• Secure boot and secure download
• Secure communication through the TLS protocol
• Secure key storage
• Encryption and digital signature

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 6 illustrates how the MAXQ1061 can be interfaced to the host processor and a summarized version the operation is explained in the steps below the figure.

• As discussed previously, a system public-private key pair for the secure boot or download function is established at the R&D facility. With the MAX1061, ECDSA key pairs can have 256-, 384- or 521-bit key lengths. The private key of this pair is used to sign firmware or a data file that ultimately is verified by the MAXQ1061 embedded in the end system. This system private key never leaves the controlled development environment. The system public key of this pair is installed in the MAXQ1061.
• As shown in Figure 2, the system private key is used to calculate the signature. It is computed on the SHA-x hash of the data file and is appended to the firmware or data file.
• The main processor sends the "VERIFY BOOT" command to the MAXQ1061 along with the firmware to be verified and its expected digital signature.
• The MAXQ1061 returns the result of the operation, either with "success" or an error code. Optionally the RESET_OUT pin is asserted. The RESET_OUT pin can be used to trigger an interrupt for the main processor or to set it in the reset state.
• If the signature verification is successful, then the general security condition "SECURE BOOT" is met. Thanks to the secure filesystem, the MAXQ1061 user can configure access to some objects to a successful firmware verification. When the secure boot condition is met, access to such objects is granted, if not it is locked. A typical usage of this feature is to store a firmware encryption key in the MAXQ1061, the encryption key would be usable to decrypt the firmware only after its signature has been verified. Optionally, the firmware is sent to the AES-SPI hardware engine to be decrypted.

Secure Boot and Secure Download using MAXQ1065

The MAXQ1065 is a low-power fixed-function security co-processor that provides edge-to-cloud turnkey security solution for embedded connected system. It uses TLS/DTLS 1.2 to enable secure communications for IOT devices. It features similar crypto functions as the MAXQ1061. In addition, the ChipDNA^TM PUF security technology in the MAXQ1065 protects the secure key which never resides statically in registers or memory, nor does it ever leave the electrical boundary of the IC. The ChipDNA technology provides an exponential increase in protection against the invasive and reverse engineering attacks that hackers apply.

The process flow is very similar to the MAXQ1061 with optional "RESET_OUT" assertion and fixed ECDSA key length.

• When firmware is required to be run by the host microcontroller, it is first retrieved by the host MCU boot manager and delivered to the MAXQ1065 in sequential 2048-byte blocks to compute a SHA-256 hash.
• After the MAXQ1065 completes the SHA-256 hash computation, the processor delivers the ECDSA signature of the firmware or data that was computed in the development environment and appended to the file.
• The main processor sends the "VERIFY BOOT" command to the MAXQ1065 along with the firmware or data file to be verified and its expected digital signature.
• The MAXQ1065 returns the result of the operation, either with "success" or an error code.
• If the signature verification is successful, then the general security condition "SECURE BOOT" is met. The secure filesystem enables user to gate access to some MAXQ1065 objects based on the status of the firmware verification. When the secure boot condition is met, access to such objects is granted, if not it is locked. A typical usage of this feature is to store a firmware encryption key in the MAXQ1065, the encryption key would be usable to decrypt the firmware only after its signature has been verified. Optionally, the firmware is sent to the hardware AES engine to be decrypted.

Secure Boot and Secure Download using DS28S60

The DS28S60 DeepCover^® cryptographic coprocessor provides the simplest solution for IOT security applications. With a fixed command set and no device-level firmware development required, the DS28S60 makes it fast and easy to implement full security for IoT devices. This secure coprocessor provides a comprehensive cryptographic toolbox for securing a broad range of embedded equipment. The hardware accelerators in the DS28S60 enable fast SHA and ECDSA computation. The integrated ChipDNA PUF technology provides robust countermeasures in protection against the security attacks.

The process flow is similar to the DS28C36 with AES encryption/decryption features.

• The DS28S60 with the preprogrammed system public key (configured with authority attribute) is located on the system board and interfaced to the local or remote host processor.
• When firmware is required to be run by the processor, or a configuration data file is needed for system use, it is first retrieved by the processor boot manager and delivered to the DS28S60 in sequential 64-byte blocks to compute a SHA-256 hash.
• After the DS28S60 completes the SHA-256 hash computation, the processor delivers the ECDSA signature of the firmware or data that was computed in the development environment and appended to the file.
• After the DS28S60 receives the ECDSA signature the processor sends commands to use the preinstalled system public key to perform a signature verification.
• If the DS28S60 verifies the signature, a pass result parameter byte is delivered to the processor. It sends a go/no-go command to the processor to run the firmware or use the configuration file. Optionally, the firmware is sent to the hardware AES engine to be encrypted/decrypted.

Conclusion

Secure boot or secure download is a proven security solution to address related threats that IoT devices are exposed to. It can determine the integrity and authenticity of firmware or a configuration data file that are either installed or downloaded to an embedded system. Successfully implementing secure boot and secure download in your system can:

• Ensure that a downloaded data file or firmware is authentic and unmodified
• Prevent hacked data or firmware from being installed in device hardware
• Improve safety in industrial and medical applications
• Control feature enablement

Analog Devices offers a portfolio of turnkey security IC solutions with varying capabilities to provide system designers with a straightforward solution to guarantee secure boot of firmware or secure download of data to their embedded systems, both in the factory and in the field.