[RT-117x] i.MX-RT1170's Secure Boot

i.MX-RT1170's Secure Boot

上一页[RT-117x] Going through the MX-RT1170 hard/soft platform 下一页[RT-117x]Signing image with the HSM (SignServer)

最后更新于1年前

[RT-117x] i.MX-RT1170's Secure Boot

i.MX-RT1170's Secure Boot

1. Overview

Based on the , the section is to enable the IMX RT1170’s secure boot. The IMX RT1170 family provides the High Assurance Boot (HAB) feature ensuring that only authenticated software is executed on a device. It represents the secure boot using the High Assurance Protocol (HABv4) protocol built into the on-chip eFUSE to establish the root of trust. The BootROM is responsible for loading the initial program image from a boot source. The HAB enables the BootROM to authenticate the program image using digital signatures. The HAB is based on asymmetric cryptography, which uses private and public keys generated according to the Public Key Infrastructure (PKI). Image integrity, authenticity, and confidentiality can be achieved by enabling additional encryption, which is built on top of the HAB.

For covering Image integrity, authenticity, and confidentiality. The Secure boot uses the methods as follows:

Integrity: Make use of the SHA-256 digest to verify the image integrity.
Authenticity: Uses asymmetric cryptography (RSA or ECDSA) to guarantee the image authenticity, and the Super Root Key Hash is populated into on-chip eFUSE.
Confidentiality: Uses symmetric cryptography (AES-CCM 256 bit) to encrypt the image, and uses the Key Encryption Key (KEK) with Physical Unclonable Function (PUF) key store.

Depending on the algorithm, HAB will use the hardware IP - CAAM to accelerate the following crypto operations:

The ECC is accelerated by the CAAM.
The RSA is handled by the software within the HAB.
The AES is accelerated by the CAAM.
The SHA is handled by the HAB software or CAAM-accelerated, depending on the signature Command Sequence File (CSF).

2. Secure Boot High-Level

2.1 BootROM WorkFlow

FlexSPI NOR boot overview is shown in the following figure:

We only need to pay attention to the non-XIP mode.

2.2 Secure Boot Config Conditions

The security modes described in this section can be used on both the CM7 and CM4 cores;
The CM4 core must be configured by the BT_CORE_SEL eFUSE to behave as the main core;

2.3 Secure Bootable Image Layout

To create a bootable image, the BootROM requires including several structures along with the application’s image in a boot source memory, the layout is shown in the following figure:

The figure represents the boot layout for the most popular FlexSPI NOR memory, structures such as OTAD/IEE Key blobs, PUF Key Store, CSF, and DEK Blob are marked as “optional”.

OTFAD/IEE key blob (for non-XIP, don’t care it): Contains encryption keys and context structures for OTFAD or IEE. The blob must be placed at offset 0 in the external memory. It is available for the FlexSPI NOR XiP boot only.
Firmware Configuration Block (FCB): Contains parameters for the FlexSPI controller configuration. For the FlexSPI NOR, the BootROM will always look for the FCB at the 0x400 offset.
Physical Unclonable Function (PUF) key store: Contains a Key Encryption Key (KEK) for the OTFAD key blob unwrap. The KEK storage for the IEE key blob unwrap is not supported by the PUF key store.
Image Vector Table (IVT) and boot data: The image vector table consists of a list of pointers located at a fixed address that the ROM examines to determine where the other components of the program image are. Boot data indicates the program image location, the program image size in bytes, and the plugin flag. For the FlexSPI NOR, the boot ROM will always look for the IVT at the 0x1000 offset.
Device Configuration Data (DCD): Contains configuration information that the boot ROM uses to configure peripherals on the device. It is mainly used to configure the SEMC for SDRAMs. The DCD can be also used to configure the FlexSPI for HyperRams.
Application: User’s code and data.
Data Encryption Key (DEK) blob: The encrypted blob contains a DEK, essential for the HAB encrypted boot secure boot mode. It is encrypted by an SNVS master key to protect the DEK.

2.3.1 Procedure to Generate Secure Bootable Image

This demo is based on non-XIP mode storing in the NorFlash.

Generate CSF Header and Signature

The process of the binary raw data transforming to the signed bootable image is shown in the following figure:

The application in a signed bootable image

The CSF in a signed bootable image

The signature in a CSF header

Signatures contain a CSF signature and an image signature. The CSF signature is signed from the HAB command in the CSF header, and the image signature is the application binary raw data.

The application image is signed by the image private key, while the HAB commands is signed by the CSF private key.

About Private Key
Note, in the bd file for elftosb tool, although assigned a public key cert (CSF1_1_sha256_2048_65537_v3_usr_crt.pem ) shown in the following figure, the CST tool changes the file name to CSF1_1_sha256_2048_65537_v3_usr_key.pem to match the private key file according to the prefix string CSF1_1_sha256_2048_65537_v3_usr.

Note: OpenSSL 1.1.1 can be used with the restriction to convert the password file (“key_pass.txt”) to Unix format. The small tool convlb.exe that can be found within the keys directory does this conversion when using the script for generating the keys.

Generate Signatures

In the source code, the cst makes use of cst.c file create_sig_file function to generate the signature.

In the following c source file, the cst tool makes use of the openssl, CMS_sign to sign the data.

Please refer to:

The sign progress is shown in the following block:

        /* Read Data to be signed */
        if (!(bio_in = BIO_new_file(in_file, "rb"))) {
            snprintf(err_str, MAX_ERR_STR_BYTES-1,
                     "Cannot open data file %s", in_file);
            display_error(err_str);
            err_value = CAL_CRYPTO_API_ERROR;
            break;
        }

        /* Generate CMS Signature - can only use CMS_sign if default
         * MD is used which is SHA1 */
        flags |= CMS_PARTIAL;

        cms = CMS_sign(NULL, NULL, NULL, bio_in, flags);
        if (!cms) {
            display_error("Failed to initialize CMS signature");
            err_value = CAL_CRYPTO_API_ERROR;
            break;
        }

        if (!CMS_add1_signer(cms, cert, key, sign_md, flags)) {
            display_error("Failed to generate CMS signature");
            err_value = CAL_CRYPTO_API_ERROR;
            break;
        }

        /* Finalize the signature */
        if (!CMS_final(cms, bio_in, NULL, flags)) {
            display_error("Failed to finalize CMS signature");
            err_value = CAL_CRYPTO_API_ERROR;
            break;
        }

        /* Write CMS signature to output buffer - DER format */
        err_value = cms_to_buf(cms, bio_in, sig_buf, sig_buf_bytes, flags);
    } while(0);

CSF header Layout Summary

HAB command (generated by the NXP cst tool)
SRK table (generated by the NXP srktool)
Public Certs
- CSF public cert (DER format)
- IMAGE public cert (DER format)
Signatures
- HAB command signature (using CSF private key)
- Bootable image signature (using the IMAGE private key)

HAB command

SRK table

CSF cert DER

IMG cert DER

Signatures

Image Signature (CMS blob)

CSF Signature (CMS blob)

2.4 Authentication and HASH

In order to enhance security, the HAB features:

CMS PKCS#1 signature verification using the RSA public keys (from 1024-bit to 4096-bit) or ECC (P256, P384, and P521) and the SHA-256 hash algorithm.
Public Key Infrastructure (PKI) support using X.509v3 certificates.
Authentication of software loaded from any boot device (including the USB download).
Authenticated decryption of software loaded from any boot device (including USB download) using the AES keys (128-bit, 256-bit).
Root public key fingerprint in the manufacturer-programmable on-chip eFUSEs.
Multiple root public keys with revocation by fuses.
Supports fall-through USB/serial downloader if the primary or recovery boot fails.

2.4.1 SRKs PKI

2.4.2 Normal Mode

PKI Tree

The High Assurance Boot (HAB) authentication is based on public keys cryptography using the RSA or ECDSA algorithms, in which image data is signed offline using a series of private keys. The resulting signed image data is then verified by the BootROM using the corresponding public keys every time the device comes out from a reset. This key structure is known as a PKI tree. It is possible to generate up to four Super Root Keys (SRKs), corresponding CSF, and IMG keys for the secure normal boot mode in the following figure where a CSF key is used for signing the CSF section and an IMG key for the application’s code and data.

2.4.3 Fast Mode (for critical boot time)

The following figure shows the PKI tree for the fast authentication boot. It provides the option to use the SRK to verify the CSF data and the image data directly, instead of using the CSF and IMG keys. This reduces the number of key pair authentications that must occur during the ROM/HAB boot stage. Unless the boot time is critical, it is recommended that the CSF and IMG keys are used to validate their respective data. The fast authentication feature supplies the user with a faster boot time, at the cost of a less robust signature.

An SRK key is revoked by burning the corresponding bit in the SRK_REVOKE[3:0] eFuse field in the following figure:

Procedure to Generate SRKs Table

The process of the SRKH generation is shown in the following figure:

In the X-NAV solution, the fast boot mode is enough for the security requirement. For the srkool, please refer to the link:

Generate CA credential

The following block is shown the process of the CA credential generation that is containing:

CA Private Key
CA Cert derived from the CA Private key.

CA_PRIVATE_KEY="ca_private"
CA_PUBLIC_KEY="ca_public"
CA_CERT="ca_cert"

ca_generate() {
    ca_subj_req=/CN=CA1_sha256_2048_65537_v3_ca/
    ca_key_type=rsa:2048

    rm -rf key_pass.txt
    echo "123456" > key_pass.txt
    # 1. gen ca private key (pem) + ca cert (pem) PKCS#1
    openssl req -newkey ${ca_key_type} -passout file:./key_pass.txt \
                   -subj ${ca_subj_req} \
                   -x509 -extensions v3_ca \
                   -keyout temp.pem \
                   -out ${CA_CERT}.pem \
                   -days 3650 -config "openssl.cnf"
    if [ $? -ge 1 ]; then
       exit 2
    fi

    echo key_pass.txt > key_pass_1.txt
    # 2.Generate CA key in PKCS #8 format - both PEM and DER
    openssl pkcs8 -passin file:"./key_pass.txt" -passout file:"./key_pass_1.txt" \
                  -topk8 -inform PEM -outform DER -v2 des3 \
                  -in temp.pem \
                  -out ${CA_PRIVATE_KEY}.der
    if [ $? -ge 1 ]; then
       exit 2
    fi
    cp -r temp.pem ${CA_PRIVATE_KEY}_pkcs1.pem
    openssl pkcs8 -passin file:./key_pass.txt -passout file:./key_pass_1.txt \
                  -topk8 -inform PEM -outform PEM -v2 des3 \
                  -in temp.pem \
                  -out ${CA_PRIVATE_KEY}.pem
    if [ $? -ge 1 ]; then
       exit 2
    fi

    # 3. Convert CA Certificate to DER format
    openssl x509 -inform PEM -outform DER -in ${CA_CERT}.pem -out ${CA_CERT}.der
    if [ $? -ge 1 ]; then
       exit 2
    fi

    rm -rf temp.pem
}

ca_generate
ls -al
echo "CA cert done!"

Generate SRKS

The following block is shown the process of SRKs generation that is containing:

SRK private keys (1-4)
SRK CSR (1-4)
SRK public certs signed by CA private key (1-4).


CA_PRIVATE_KEY="ca_private"
CA_PUBLIC_KEY="ca_public"
CA_CERT="ca_cert"

num_srk=4

srk_generate() {

   i=1
   while [ $i -le ${num_srk} ]
   do
      SRK_NUM=${i}
      SRK_PRIVATE_KEY="srk${SRK_NUM}_private"
      SRK_PUBLIC_KEY="srk${SRK_NUM}_public"
      SRK_CERT_BY_CA="srk${SRK_NUM}_ca.cert"
      # 1. Generate SRK key (PEM)
      echo "123456" > key_pass.txt
      openssl genrsa -des3 -passout file:./key_pass.txt -f4 \
                     -out ./temp_srk.pem 2048
      if [ $? -ge 1 ]; then
         exit 2
      fi

      # 2. Generate SRK certificate signing request
      srk_subj_req=/CN=SRK${SRK_NUM}_sha256_256_65537_v3_usr/
      openssl req -new -batch -passin file:./key_pass.txt \
                       -subj ${srk_subj_req} \
                       -key ./temp_srk.pem \
                       -out ./temp_srk_req.pem
      if [ $? -ge 1 ]; then
         exit 2
      fi

      # 3. Generate SRK certificate signing request
      openssl req -new -batch -passin file:./key_pass.txt \
                       -subj ${srk_subj_req} \
                       -key ./temp_srk.pem \
                       -out ./temp_srk_req.pem
      if [ $? -ge 1 ]; then
         exit 2
      fi
      echo "Gen SRK CSR finish!"

      # 4. Generate SRK certificate (signed by a CA cert)
      openssl ca -batch -passin file:./key_pass.txt \
                 -md sha256 -outdir ./ \
                 -in ./temp_srk_req.pem \
                 -cert ${CA_CERT}.pem \
                 -keyfile ${CA_PRIVATE_KEY}_pkcs1.pem \
                 -extfile "v3_usr.cnf" \
                 -out ${SRK_CERT_BY_CA}.pem \
                 -days 3650 \
                 -config "openssl.cnf"
      if [ $? -ge 1 ]; then
         exit 2
      fi
      echo "signed CSR by CA cert and private key!"

      # Convert SRK Certificate to DER format
      openssl x509 -inform PEM -outform DER \
                   -in ${SRK_CERT_BY_CA}.pem \
                   -out ${SRK_CERT_BY_CA}.der
      if [ $? -ge 1 ]; then
         exit 2
      fi
      echo "Converted SRK Certificate to DER format!"

      echo key_pass.txt > key_pass_1.txt
      # Generate SRK key in PKCS #8 format - both PEM and DER
      openssl pkcs8 -passin file:./key_pass.txt \
                    -passout file:./key_pass_1.txt \
                    -topk8 -inform PEM -outform DER -v2 des3 \
                    -in temp_srk.pem \
                    -out ${SRK_PRIVATE_KEY}.der
      if [ $? -ge 1 ]; then
         exit 2
      fi

      openssl pkcs8 -passin file:./key_pass.txt \
                    -passout file:./key_pass_1.txt \
                    -topk8 -inform PEM -outform PEM -v2 des3 \
                    -in temp_srk.pem \
                    -out ${SRK_PRIVATE_KEY}.pem
      if [ $? -ge 1 ]; then
         exit 2
      fi
      echo "Generate SRK key in PKCS #8 format - both PEM and DER!"
      cp -r temp_srk.pem ${SRK_PRIVATE_KEY}_pkcs1.pem
      rm ./temp_srk.pem ./temp_srk_req.pem
      i=$((i+1))
   done
}

srk_generate
echo "done!"

Generate SRKH

gen_efuse_hash() {
   ./srktool -h 4 -t "SRK_1_2_3_4_table.bin" -e "SRK_1_2_3_4_fuse.bin" -d sha256 -f 1 \
             -c "./srk1_ca.cert.pem,./srk2_ca.cert.pem,./srk3_ca.cert.pem,./srk4_ca.cert.pem"
}

gen_efuse_hash
echo "gen_efuse_hash done!"

2.4.4 Authentication Flow

The following figure shows the certificates' generation flow along with the HAB enablement process. To generate a set of private and public keys and certificates according to the PKI tree, use the NXP Tools (elftosb). The HAB supports up to four SRKs in a signed image.

To enable the root of trust, the public keys are digested by the SHA-256 hash algorithm to create the super root key table and the Super Root Key Hash (SRKH). The SRKH is programmed into the corresponding SRK fuses on the device.

The signing of the CSF and image is done in the following way. The image is digested by the SHA-256 and the resulting hash is processed by the RSA or ECDSA digital signature algorithm to obtain the signature. The same generation flow is applied to the CSF section. The signing is done using the elftosb, cst, and dedicated Board Description (BD) file.

Provisioning and Sign Flow

The provisioning (keys generation and eFUSE programming) are shown in the following figure:

The signing CSF and Image process is shown in the following figure:

Note, we need to sign the image using the elftosb tool, and sign the CSF the CST tool.

Verification and Boot Flow

The image and CSF authentication flow is shown in the following figure:

For the authentication block:

2.5 Integrating with HSM

The NXP provides tools (elftosb and CST) that are bootable image and signature generation. In these tools, the private key (secret key) shall pass to the tool, which is difficult to make use of the HSM to sign image and CSF because the private keys cannot escape from the HSM.

2.6 Image Encryption (HAB encrypted boot)

The HAB encrypted boot is suitable for systems where the application’s image cannot stay in an external memory or when an execution from the internal memory is desired. Consider that the image footprint must always fit into the destination memory (ITCM/DTCM/OCRAM). On CM7 (default core), the FlexRam partitioning can be adjusted to the application image footprint. The encrypted boot is a combination of digital signature verification and image decryption, ensuring its integrity, authenticity, and confidentiality. The HAB encrypted boot does NOT support XiP.

2.6.1 Key Management and Image Generation

Stage 1: Encrypted Image Generation

During the enablement process for the HAB encrypted boot and in addition to signing the image described in the chapter Authentication Flow. The CST tool generates a random key called the Data Encryption Key (DEK), a.k. Red Key. The key is then used by the CST tool to encrypt the application’s image. This security mode is also based on symmetric cryptography (AES-CCM 128/192/256 bit), so the same key must be also used for decryption during the device boot. A MAC is generated to check the image integrity being populated into the CSF section.

The encrypting image process is shown in the following figure:

Stage 2: Black Key Generation and Image Burning

Stage 3: BootROM Decryption

During the boot, the ROM decrypts the key blob recovering the DEK key. The image is then decrypted by the recovered DEK and copied into the internal memory. Both the image and the DEK are verified using corresponding MACs. The HAB authentication is done on the plaintext image that is written to the internal memory.

The overview of the HAB encrypted boot flow is shown in the following figure:

2.6.2 Procedure to Run Image Encryption

The overview of the procedure is shown in the following figure:

Build Image

After the process, the provisioning tool will generate the:

Encrypted and signed image
app_hab_dek.bin (Red key)

Write Image

The DEK, encrypted and signed image, and signed flash loader will be burned into the board.

3. Secure Boot Low-Level

3.1 Procedure to Run Non-Secure Boot

3.1.1 Booting Board with SDP mode

3.1.2 Write Image

Utilize the NXP provisioning tool to burn the image, Configurations in the UI are shown in the following figure:

Check out the LED is blinking.

3.2 Procedure to Run Secure Boot with Local Keys (Only Auth)

3.2.1 Provisioning

You shall utilize the provisioning tool to blow the eFUSEs of the device. Because the device has been provisioned using the demo (local) cert and HAB has been set to the CLOSED life cycle, as a result, must use the cert files and key files to generate a secure bootable image.

This section describes the building and writing of an authenticated image.

In the Toolbar set Boot type to Authenticated (HAB).
In the Build image view
For Use the following keys select any key, for example, SRK1: IMG1_1+CSF1_1.
Click Build image.
Check that the bootable image was built successfully. To write the image, switch to Write image view.
Make sure that the board is set to Serial bootloader (ISP) mode. See Table 6 for more information.
Make sure that the Use built image checkbox is selected.
Select the HAB Closed life cycle.
Click Write image.
In the following window, confirm to write fuses: • Yes - Continue writing the image and burning fuses. Note: Burning fuses can only be done once, after that processor can only execute authenticated images. • No - Do not burn fuses, continue writing the image. • Cancel - Abort writing the image and burning fuses.

3.2.2 Burning Secure Bootable Image

After you download and uncompress the provisioning workspace, then click the Select Workspace in the provisioning GUI tool and select the extracted directory.

Please follow the following figure to configure your provisioning GUI tool:

Change the board to Serial Download Mode and then write the secure image to your board.

5. Terms and Abbreviations

Item

Description

Item

Description

AES

Advanced Encryption Standard.

HAB

High Assurance Boot; a software library executed in the internal ROM on the NXP processor at boot time, which, among other things, authenticates the software in the external memory by verifying the digital signatures in accordance with a CSF. This document is strictly limited to processors running HAB (NXP implementation of the secure boot).

CSF

Command Sequence File; a binary data structure interpreted by HAB to guide authentication operations.

Certificate Authority; the holder of a private key used to certify public keys.

X.509

Standard format for a public key certificate.

PKI

Public Key Infrastructure; a hierarchy of public key certificates in which each certificate (except for the root certificate) can be verified using the public key above it.

XIP

Execute-in-Place; refers to a software image that is executed directly from its non-volatile storage location rather than first being copied to the volatile memory.

IEE

Inline Encryption Engine (IEE) providing means for the XiP on-the-fly decryption using stronger AES-256-CTR or AES-512-XTS block cipher modes.

IEK

Image Encryption Key; defined for each OTFAD/IEE context structure used as the encryption key for image data defined by context structures.

OTFAD

MAC

Message Authentication Code.

RSA

Public key cryptography algorithm developed by Rivest, Shamir, and Adleman.

ECC/ecc

Elliptic Curve Cryptography.

ECDSA

Elliptic Curve Digital Signature Algorithm.

CAAM

Cryptographic Acceleration and Assurance Module; accelerator for encryption, stream cipher, and hashing algorithms with a random number generator and runtime integrity checker.

DCD

Device Configuration Data; a binary table used by the ROM code to configure the device at early boot stages.

OCOTP

On-Chip One-Time Programmable; the OCOTP hardware includes the masked ROM and electrically programmable fuses (eFuses).

KEK

Key Encryption Key; used for encryption of the OTFAD/IEE key blob.

SRK

Super Root Key; a RSA or ECC 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 OCOTP hardware. The SRK private key is held by the CA.

POR

Power On Reset.

eFUSE

Refer to

SDRAM

(synchronous DRAM) is a generic name for various kinds of dynamic random access memory (DRAM) that are synchronized with the clock speed that the microprocessor is optimized for.

OCRAM

On-chip RAM.

TCM

D-TCM

Data TCM.

I-TCM

Instruction TCM.

CM4

ARM Cortex-M4 core for IMX-RT1170.

CM7

ARM Cortex-M7 core for IMX-RT1170.

BootROM