Secure Boot and Chain of Trust

IN SECURITY WE TRUST

The information below describe the features of the Trusted Bootchain and in particular the i.MX Secure Architecture.

Secure Boot / Chain of Trust

Ensure your device is not running tampered software by verifying its authenticity before execution. Establish software authenticity all the way from the bootloader to user applications. Our secure boot services help implement:

• Verified bootloader (NXP i.MX / QorIQ, Qualcomm Snapdragon, TI Sitara, Atmel SAMA5, Xilinx Zynq and more)
• Kernel verification (FIT image, SoC specific mechanisms)
• Root filesystem verification (dm-verity, IMA/EVM, FIT image)
• Filesystem cryptography, Filesystem-level encryption (dm-crypt)

Nowadays, with the growth of the number of connected devices (IoT, home automation, industry 4.0, …) security risks are increasing and are a big concern.

Hackers can attack simple objects like home sensors, but also payment systems or critical-mission systems on dangerous plants, and they can do it in a simple way if we not think about protecting our products.

Attacks can be driven locally or remotely, and in a physical or in a logical (software) manner. Moreover, decommissioned products can be used to extract useful data that can helps to hack installed ones.

From these considerations it’s clear that taking care on products protection must be done at the very early start of the project, and should be thought without minimizing possible risks.

IEC defines a series of standards in IEC62443 regulation, that provides general requirements (called foundational requirements) to address and mitigate current and future security vulnerabilities in industrial automation and control systems.

To fulfill these requirements and to allow users to execute critical software in a trusted environment, ARM defines various peripherals and technologies on its chips.

One of these technologies is the secure boot, which allows to be confident that only software produced by you can be executed on the SOC.

In the following picture are described the STM32MP1 trusted boot features.

There are two possible solutions for ARM SoC that runs on every power cycle.

Trusted Execution

• TrustZone Secure (relying on processor modes)
• Isolates execution of critical SW
• Realize an hardware firewall between CPU and peripherals

High Assurance Boot

• NXP i.MX6 i.MX7 i.MX8 specific
• Authenticate/Signed boot: prevent unauthorized software execution
• Encrypted boot: protects software confidentiality
• Signature checks embedded in on-chip boot ROM

HAB Secure Boot chain

Secure boot on NXP i.MX chips is named High Assurance Boot (HAB).
HAB-enabled chips bases their functionalities on some secure peripherals on board, beside to a process of software signing.

It is also possible to encrypt your software to protect it from reverse-engineering. Therefore, where cryptography comes in, we have to deal with keys, and especially about keys protection: to not vanish the work done on our device to secure it, we have to protect our private keys with extreme diligence (but that’s another story).

Basically, HAB section in chip’s BootROM can verify if a software is authentic (based on its signature) or can decrypt it if is encrypted. Encryption, decryption and hashing operations are done via hardware by dedicated peripherals to ensure fast operations.

This image illustrates the procedure to sign a software:

n this case asymmetric cryptography is used: software image hash is encrypted with the private key and is deployed with its signature on device flash. The public key is burned in chip’s OTP zone. After enabling secure boot feature, at every boot HAB takes image signature and decrypt it with the public key, calculates software image hash and compare the two hashes: software will be executed only if they are equal.

With encrypted images, the workflow is a little different:

Here symmetric cryptography is involved: the secret key used to encrypt image is stored on the device in a key blob, generated by the device itself (using manufacturing tool) encrypting the secret key with a univocal, non-knowable and non-readable internal key programmed on-chip by NXP at production time.

At boot time, HAB decrypts secret key, uses it to decrypt software image and runs it. With image encryption, also authenticity is assured.

More details

Document Number: AN4581 – NXP Semiconductors Application Note – Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using HABv4 : https://www.nxp.com/docs/en/application-note/AN4581.pdf

Keywords

• Boot ROM: Small piece of one-time programmable firmware written in on-chip read-only memory location and the very first unsigned-software which is executed by the processor on power-on or reset.
• Secure Boot ROM: Similar to Boot ROM, but capable of running signed-software using secure libraries.
• HAB Library: Secure software library executed in i.MX Boot ROM, using Signing and Encryption processes.
• Signed Software/Image: Software Image further padded or processed using Signature that can capable to run only on secure environment.
• Signature: Legally binding secure attributes to Signed Image, these attributes can be Private/Public keys, HAB data, Certificate, Secrete keys etc which is understandable by the HAB.
• CSF: Command Sequence File, a binary data structure interpreted by the HAB to guide signing and/or decryption process.
• CST: Code Signing Tool, like OpenSSL an application running on a build host to generate PKI tree, SRK table along with associated CSF file.
• PKI tree: Public Key Infrastructure, a hierarchy of public key certificates in which each certificate (except the root certificate) can be verified using the public key above it.
• RSA: Public key cryptography algorithm used for Signing or Authentication process.
• SRK: Super Root Key, an RSA key pair which forms the start of the boot time authentication chain. The hash of the SRK public key is embedded in the processor using OTP hardware(e-fuse). The SRK private key is held by the Signature generation for software image.
• DEK: Data Encryption Key (DEK), is the key that will be used to actually encrypt the image.
• DEK Blob: Encryption of DEK using OTPMK with the help of CAAM HW
• OTPMK: AES-256 key burned to fuses by NXP before the IC is shipped. This is unique per chip and only CAAM can access the key.
• Secret Key: Generally an outcome key of DEK Blob key used to encrypt and decrypt.
• AES: Advanced Encryption Standard used for Encryption process

Conclusion

Securing a device may seem a simple subject, but there are many aspects and considerations involved more than the ones showed in this simple introduction.

KOAN can assist you to build trusted devices and can help you to improve your development cycle with a plethora of services.