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

i.MX-RT1170's Secure Boot

1. Overview

Based on the https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/13/rt1170_documents/rt-117x-going-through-the-mx-rt1170-hard-soft-platform, 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

• Image: The NXP Tools(elftosb) must be used to create a secure bootable image;

• Provisioning: Configures the device by programming corresponding eFUSEs, for more information, please refer to the link https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/13/rt1170_documents/rt-117x-imx-rt1170-provisioning-guideline.The SEC_CONFIG[1] fuse bit must be programmed to set a security mode into the CLOSED mode.

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

• Command Sequence File (CSF): Commands processed by the HAB for code authentication, including public keys, signatures, certificates, and Auth Data commands. The CSF is generated by an individual tool named cst. Link: https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX_CST_TOOL .

• 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 process of the binary raw data transforming to the signed bootable image

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

Next, we should know how to generate signatures (image signature and CSF signature) in the NXP CST tool. We can obtain the source code of the CST from the https://www.nxp.com/webapp/sps/download/view_license.jsp?colCode=IMX_CST_TOOL.

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:

• https://www.openssl.org/docs/man1.1.1/man3/CMS_sign.html

• https://www.openssl.org/docs/man1.1.1/man3/CMS_add1_signer.html

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.

PKI tree – normal boot

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.

PKI tree - fast boot

The HAB supported devices include the revocation of SRKs. Only one SRK may be selected at the boot time through the Install SRK CSF command that is stored in CSF header. When one or more SRKs are compromised, it is possible to revoke that SRK. There are up to four SRK revoke fuse bits that map to the SRK table indexes:

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

The following block is shown the process of the SRKH generation, please refer to the link https://github.com/usbarmory/usbarmory/wiki/Secure-boot-with-NXP-tools-(Mk-I).

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.

After a device is moved to the CLOSED mode, only authorized software signed by one of the corresponding private keys can be executed on the device including the USB/SERIAL download via the Blhost (NXP Flashloader). The execution is possible only when the Flashloader is signed with the corresponding private key on closed devices.

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:

(Provisioning) keys generation and eFUSE programming

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

signing CSF and Image

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.

Please refer to the [X-NAV] Signing image with the HSM (SignServer)

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

Both the encrypted application’s image and the DEK are passed to the NXP Flashloader, which manages the DEK encryption by the SNVS master key. For more SNVS master key in the board eFUSE, https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/13/rt1170_documents/rt-117x-imx-rt1170-provisioning-guideline. By default, the on-chip unique key (OTPMK) is used, which ensures that this specific key is the only key that can encrypt and decrypt the DEK blob. The unwrapping DEK blob is programmed into the external memory along with the encrypted image. The key blob contains another MAC for the DEK integrity verification.

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

Based on the https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/13/rt1170_documents/rt-117x-going-through-the-mx-rt1170-hard-soft-platform, generated s19 bare-metal application, this section will show how to burn the s19 bare-mental application to the Nor Flash using the MCUXpresso Secure Provisioning Tool.

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)

According to the link https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/13/rt1170_documents/rt-117x-imx-rt1170-provisioning-guideline, when a signed image is provided, authentication is performed and errors (if any) are logged, but authentication errors do not prevent the boot.

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.

1. In the Toolbar set Boot type to Authenticated (HAB).

2. In the Build image view

3. For Use the following keys select any key, for example, SRK1: IMG1_1+CSF1_1.

4. Click Build image.

5. Check that the bootable image was built successfully. To write the image, switch to Write image view.

6. Make sure that the board is set to Serial bootloader (ISP) mode. See Table 6 for more information.

7. Make sure that the Use built image checkbox is selected.

8. Select the HAB Closed life cycle.

9. Click Write image.

10. 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.
CA	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	On-The-Fly AES Decryption, document https://www.nxp.com/doc/AN12324.
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	Tightly Coupled Memory.
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	NXP provided solid first stage boot program, that cannot be re-programmed.
SNVS	Secure Non-Volatile Storage.
CLOSED	The SEC_CONFIG[1] fuse bit was programed to set a security mode into the CLOSED mode. In other words, provisioned device is into the CLOSED mode.