[RT-117x]IMX RT1170 Provisioning Guideline
最后更新于
最后更新于
The NXP i.MX RT117x/6x series provides several security features, most of which are controlled using one-time programmable (OTP) fuses. For secure applications, there are some fuses that are not related to security features and might need to be configured. This document discusses eFUSE provisioning for secure applications and provides fuse configuration recommendations for X-NAV devices.
This document includes the eFUSE introduction and eFUSE provisioning. For the eFUSE introduction https://drive.google.com/file/d/1o1PWMqjLf4pV75kw-NuIYEQKFWgLNVBj/view?usp=drive_link, mainly reference the NXP document of AN13434 i.MX RT117x/6x Fuse Provisioning for Security . While For the eFUSE provisioning, mainly reference the NXP document of the MCUXpresso Secure Provisioning Tool
Open ( SEC_CONFIG [1:0] fuse = 0b01), Intended for use in non-secure products or during the development phases of a secure product. Signed images are optional. If a signed image is provided, authentication is performed and errors (if any) are logged, but authentication errors do not prevent the boot. The secure Non-volatile Storage module (SNVS) transitions to the Non-secure state during boot.
The SNVS master key is not available to the Cryptographic Acceleration and Assurance Module (CAAM).
Closed ( SEC_CONFIG [1:0] fuse = 0b11; FIELD_RETURN fuse = 0), Intended for use in secure products. Signed images are mandatory. Non-authenticated code does not boot. SNVS transitions to the Trusted state during boot. The SNVS master key is available to the CAAM module as long as a security violation does not occur (for example, attaching a debugger).
Field Return ( SEC_CONFIG [1:0] fuse = 0b11; FIELD_RETURN fuse = 1). Intended for security products that have been returned to NXP. The device must not be returned to regular service (cannot return to the Closed state). Signed code with specific commands in the High Assurance Boot (HAB) Command Sequence File (CSF) is required to allow the transition from Closed to Field Return.
Note,The status of the Field Return isn’t our focus. The provisioning definition is the security lifecycle transition from Open to Closed.
RT117x devices include a Key Manager (KEYMGR) that is responsible for routing keys over secure key buses to several crypto accelerators and security blocks in the chip. As shown in the key manager block diagram below, the KEYMGR operation is primarily controlled by fuses that determine which key options are used for different modules.
The following sections describe the fuses used to configure the KEYMGR. The fuse address for each fuse is listed. For example, MASTER_KEY_SEL is bit 2 at fuse address 0x8E0.
SNVS Master Key Select (MASTER_KEY_SEL) (0x8E0[2]). KEYMGR has two options for the key that can be routed to the SNVS module as its OTPMK (one-time programmable master key). Although the key is referred to as OTPMK at the SNVS module, the key manager can use either an OTPMK fuse derived key or a PUF key to send to SNVS.
The MASTER_KEY_SEL fuse is used to determine which key is used. There is also a corresponding MASTER_KEY_SEL_LOCK fuse that can be blown to prevent software reconfiguration of MASTER_KEY_SEL through the KEYMGR registers.
On-the-Fly AES Decryption Key Selects (OTFAD1_KEY_SEL and OTFAD2_KEY_SEL) (0x8E0[4] and 0x8E0[6]).
The two On-the-Fly AES Decryption (OTFAD) modules can be used for on-the-fly decryption of all or portions of the FlexSPI1 (using OTFAD1) or FlexSPI2 (using OTFAD2) memory regions. OTFAD modules use RFC3394 wrapped key blobs to configure the four supported contexts. The unwrapped key blob structures contain:
128-bit key to use for decrypting the context
64-bit counter value which is combined with the address to create a counter value used when decrypting data for the context
64-bit region descriptor (start address, end address, and configuration for the context)
As described above, the decryption keys for the contexts are contained within the key blobs. Instead of selecting keys to use for any of the regions/context, the OTFAD key selects are used to specify unwrapping keys used to decrypt the key blobs for each of the OTFAD modules.
KEYMGR routes USER_KEY5 [127:0] or a PUF based key to be used as the OTFADn unwrap key based on the value of the OTFADn_KEY_SEL fuse. There are also corresponding OTFADn_KEY_SEL_LOCK fuses that can be blown to prevent software reconfiguration of OTFADn_KEY_SEL through the KEYMGR registers.
LOAD_IEE_KEY (0x8E0[8]), the LOAD_IEE_KEY fuse enables KEYMGR to perform the initial load of the Inline Encryption Engine (IEE) keys during system startup. This fuse must be blown to use IEE encrypted eXecute-In-Place (XIP) boot.
The PUF_ENABLE (0x860[6]) fuse enables the PUF block within KEYMGR. This fuse must be blown to use any of the PUF functionality (masterkey, OTFADn keys, and/or application keys).
The UDF_ENABLE fuse enables the Undocumented Function (UDF) block within KEYMGR. This fuse must be blown to allow the UDF key manager within the KEYMGR module to provide the SNVS module's OTPMK
There are several key fuses available on the RT117x/6x devices. The following sections provide more detail on each of the keys. The SRK_HASH is the only value that requires programming for secure applications. The other key values are optional depending on the use case.
The SRK_HASH fuses must be blown with a value for secure applications running authenticated code. The value to program into the fuses corresponds to the public halves of the code signing key pairs that are used for the device. The SRK_HASH is used to authenticate the public key table that is appended to the signed image.
The SRK_HASH fuse words use ECC for integrity, so they are automatically locked to prevent additional writes when they are programmed. The SRK_HASH value is derived from public key information. Read locking of the SRK_HASH is not supported or required.
Note, If you are using the MCUX Secure Provisioning Tool and have selected an authenticated boot mode, the tool automatically calculates the SRK_HASH value and programs the SRK_HASH fuses.
The SRK_REVOKE fuses allow you to manage root keys. Each bit corresponds to one of the four allowable super root key indexes. When one of the SRK_REVOKE fuses is blown, the corresponding SRK can no longer be used for authenticated boot. If an image attempts to use a revoked SRK, authentication fails.
In normal operation, the ROM sets the OCOTP_SW_STICKY[SRK_REVOKE_LOCK] field which prevents writes to the SRK_REVOKE fuses. To enable writes to the SRK_REVOKE fuses, a signed code with an unlock revoke command in the HAB CSF is required. When authentication with the unlock revoke command is included in the CSF passes, the OCOTP_SW_STICKY[SRK_REVOKE_LOCK] bit is not set. It allows the application code to burn SRK_REVOKE fuses.
OTPMK is a device-unique key, different on every processor, that is used as a seed for key derivation. The OTPMK fuse value is programmed by NXP during chip manufacture. OTPMK is also written and read-locked so that it cannot be modified or read directly from fuses.
The OTPMK value is sent to the SNVS module over a private bus (depending on the MASTER_KEY_SEL fuse value). Then the OTPMK key value can be used as the SNVS master key (or a component of the key) that is sent to the CAAM module. The OTPMK-derived key can be used on the device but cannot be read even by NXP.
When the IEE module is used for encrypted XiP boot, USER_KEY1 and USER_KEY2 are combined to create a single 512-bit AES-XTS key. This key is used to unwrap a ROM-defined IEE key blob.
Most boot configuration fuses do not directly control security features, but their usage can have an impact on overall system security. The following sections discuss how to secure systems that must provision the boot configuration fuses with details on the fuses that do specifically control security features.
The RT117x/6x parts that include both the Cortex M7 and M4 cores can use any core as the primary boot. . The BT_CORE_SEL fuse is used to determine which core is used for booting. By default, the M7 core is the boot core. The BT_CORE_SEL fuse should be configured appropriately for your specific application.
Boot configuration for a device can be controlled using GPIO overrides or fuses. To save pins and to prevent an attacker from changing the boot configuration, secure applications must use the boot from fuses boot mode ( BOOT_MODE [1:0] = 00).
When the BOOT_MODE [1:0] = 00 option is used to boot from fuses, the BT_FUSE_SEL value controls the boot flow. If BT_FUSE_SEL = 0, indicating that the boot configuration fuses are not programmed yet, the boot flow jumps directly to the Serial Downloader. If BT_FUSE_SEL = 1, the normal boot flow is followed, where the ROM attempts to boot from the selected boot device. Therefore, BT_FUSE_SEL must be blown for normal boot operation using the BOOT_CFG fuse values.
Depending on the boot device and configuration used, there might be additional configurations for boot in the BOOT_PARAM fuse words.
The ENCRYPT_XIP_EN fuse can be blown to enable the encrypted XIP boot from FlexSPI feature. In this mode, one of the OTFAD modules or the IEE is configured for on-the-fly decryption of the FlexSPI space used for the main application. The application and data from the FlexSPI space is available as plaintext within the processor, but is encrypted on the external bus. This feature ensures the confidentiality of FlexSPI contents without the need to decrypt the data and copy it to another location.
The RT117x/6x ROM supports encrypted XIP boot using either the OTFAD modules or the IEE module. The specific OTFAD module to use is determined by the FlexSPI module used for boot. The ENCRYPT_XIP_ENGINE fuse is used to determine if the ROM should use one of the OTFAD n modules or the IEE when encrypted XIP boot is enabled. By default ( ENCRYPT_XIP_ENGINE fuse is not blown), OTFAD is selected. To use the IEE module instead, the ENCRYPT_XIP_ENGINE fuse must be blown.
The PUF_ZEROIZE fuse can be used when OTFAD encrypted XiP boot is being used and the OTFADn_KEY_SEL fuse is configured to select the PUF key. When this fuse is set, the ROM reconstructs the PUF key, and then requests OTFAD to unwrap the key blobs. When the OTFAD keyblob unwrap is complete, ROM sets the KEYMGR_CTRL[ZERIOIZE] bit. It causes all PUF security parameters to be erased, and PUF moves to an error state preventing any additional PUF operations.
Use of the PUF_ZEROIZE feature is optional. If the application uses other PUF keys later, which could include using a PUF key to unwrap key blobs for the OTFAD module that is not used for boot, the `PUF_ZEROIZE `fuse should not be blown. If the application does not use other PUF keys, the PUF_ZEROIZE fuse can be blown to prevent any potential unwanted use of PUF after boot.
Depending on the boot device and configuration used, there might be additional configurations for boot in the BOOT_CFG_MISC fuse words.
The ROM supports a Serial Download Protocol (SDP) mode. SDP mode can be entered by changing the BOOT_MODE settings or if no valid image is found during boot. If SDP mode is not used in the field, or if only one port (UART or USB) is used, NXP recommends disabling the unused functions to prevent them from potentially being misused. To disable the SDP mode completely, the SDP_DISABLE fuse can be blown. If SDP functionality is required, the UART_SDP_DISABLE or USB_DSP_DISABLE fuse can be blown to disable SDP operation on just one serial communication channel.
In general, it is recommended to write locking as many fuse words as possible in a final secure configuration to prevent malicious or unintended misuse. In particular, the BOOT_CFG and BOOT_PARAM fuse words should be write-locked to prevent modification of the boot setup.
RT117x/6x parts use two different methods for integrity checking fuses--redundancy and ECC. Fuse words that use redundancy (RED) for integrity checks can be written multiple times, setting additional fuse bits in each write. Fuse words that use ECC for integrity checking can only be written one time, and are automatically write-locked when they are written to prevent additional writes. Therefore, only fuse words using RED ever require explicit write locking.
The secure fusing checklist can be found in Chapter 9 Secure fusing checklist of https://docs.google.com/spreadsheets/d/1RlmLi1KJTwtNvXfBzEkVtMA9-dK1VGmG7o-WpInvnOA/edit#gid=0
The boot mode shall select the Unsigneditem if the board hasn’t been provisioned yet.
We shall conduct to test the connection before reading eFUSE.
Click the OTP configuration button after testing connection, the OTP (eFUSE) layout will show a GUI window.
The eFUSE layout is shown in the GUI window:
You can make use of the Secure fusing checklist to check each fuse item.
