> For the complete documentation index, see [llms.txt](https://carloss-organization-4.gitbook.io/tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://carloss-organization-4.gitbook.io/tech/ecus/rt117x_documents/rt-117x-imx-rt1170-provisioning-guideline.md).

# \[RT-117x]IMX RT1170 Provisioning Guideline

The NXP [i.MX](http://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](http://i.MX) RT117x/6x Fuse Provisioning for Security . While For the eFUSE provisioning, mainly reference the NXP document of the MCUXpresso Secure Provisioning Tool&#x20;

{% embed url="<https://drive.google.com/file/d/1CUOfHsQ1Ifm1SfwQLhqdgeJkBPqE0I22/view?usp=drive_link>" %}

## 1. eFUSE Introduction <a href="#id-1.-efuse-introduction" id="id-1.-efuse-introduction"></a>

### 1.1 Security Lifecycle for RT117x devices <a href="#id-1.1-security-lifecycle-for-rt117x-devices" id="id-1.1-security-lifecycle-for-rt117x-devices"></a>

<figure><img src="https://1204947731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtqiX1ZbXhRorHX3bwk1r%2Fuploads%2F1PKhiasyw7UuOCr08vKv%2Fimage.png?alt=media&amp;token=714987e0-4730-4db5-8917-faec30766e72" alt="" width="375"><figcaption></figcaption></figure>

#### 1.1.1 Open Lifecycle <a href="#id-1.1.1-open-lifecycle" id="id-1.1.1-open-lifecycle"></a>

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

#### 1.1.2 Closed Lifecycle <a href="#id-1.1.2-closed-lifecycle" id="id-1.1.2-closed-lifecycle"></a>

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

#### 1.1.3 Field Return <a href="#id-1.1.3-field-return" id="id-1.1.3-field-return"></a>

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

### 1.2 Key Manager Config <a href="#id-1.2-key-manager-config" id="id-1.2-key-manager-config"></a>

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.

<figure><img src="https://1204947731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtqiX1ZbXhRorHX3bwk1r%2Fuploads%2FuEj9idAGA9ERuJMPNZzW%2Fimage.png?alt=media&amp;token=b9ca2033-bfa8-4e56-b294-b0e45d85e517" alt="" width="563"><figcaption></figcaption></figure>

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.

#### 1.2.1 SNVS Master Key <a href="#id-1.2.1-snvs-master-key" id="id-1.2.1-snvs-master-key"></a>

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.

<figure><img src="https://1204947731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtqiX1ZbXhRorHX3bwk1r%2Fuploads%2FildfcyjQ1e9LxsnwVPVO%2Fimage.png?alt=media&amp;token=b239a8de-1fba-49b8-aede-0921f558aba1" alt=""><figcaption></figcaption></figure>

#### 1.2.2 On-the-Fly AES Decryption Key <a href="#id-1.2.2-on-the-fly-aes-decryption-key" id="id-1.2.2-on-the-fly-aes-decryption-key"></a>

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](https://www.rfc-editor.org/rfc/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.

#### 1.2.3 LOAD\_IEE\_KEY <a href="#id-1.2.3-load_iee_key" id="id-1.2.3-load_iee_key"></a>

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

#### 1.2.4 PUF\_ENABLE <a href="#id-1.2.4-puf_enable" id="id-1.2.4-puf_enable"></a>

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

#### 1.2.5 UDF\_ENABLE <a href="#id-1.2.5-udf_enable" id="id-1.2.5-udf_enable"></a>

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

### 1.3 OTFAD config <a href="#id-1.3-otfad-config" id="id-1.3-otfad-config"></a>

### 1.4 Keys <a href="#id-1.4-keys" id="id-1.4-keys"></a>

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.

#### 1.4.1 Super Root Key Hash (SRK\_HASH) (0xB00-0xB70) <a href="#id-1.4.1-super-root-key-hash-srk_hash-0xb00-0xb70" id="id-1.4.1-super-root-key-hash-srk_hash-0xb00-0xb70"></a>

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.

#### 1.4.2 SRK\_REVOKE\[3:0] (0x8D0\[11:8]) <a href="#id-1.4.2-srk_revoke-3-0-0x8d0-11-8" id="id-1.4.2-srk_revoke-3-0-0x8d0-11-8"></a>

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.

#### 1.4.3 One-Time Programmable Master Key (OTPMK) <a href="#id-1.4.3-one-time-programmable-master-key-otpmk" id="id-1.4.3-one-time-programmable-master-key-otpmk"></a>

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.

#### 1.4.4 USER\_KEY1 and USER\_KEY2 (0xE00-0xE70 and 0xE80-0xEF0) <a href="#id-1.4.4-user_key1-and-user_key2-0xe00-0xe70-and-0xe80-0xef0" id="id-1.4.4-user_key1-and-user_key2-0xe00-0xe70-and-0xe80-0xef0"></a>

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.

#### 1.4.5 USER\_KEY3 and USER\_KEY4 (0xF00-0xF70 and 0xF80-0xFF0) <a href="#id-1.4.5-user_key3-and-user_key4-0xf00-0xf70-and-0xf80-0xff0" id="id-1.4.5-user_key3-and-user_key4-0xf00-0xf70-and-0xf80-0xff0"></a>

&#x20;

#### 1.4.6 USER\_KEY5 (0x1000-0x1070) <a href="#id-1.4.6-user_key5-0x1000-0x1070" id="id-1.4.6-user_key5-0x1000-0x1070"></a>

### 1.5 Boot configuration <a href="#id-1.5-boot-configuration" id="id-1.5-boot-configuration"></a>

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.

#### 1.5.1 BT\_CORE\_SEL (0x960\[12]) <a href="#id-1.5.1-bt_core_sel-0x960-12" id="id-1.5.1-bt_core_sel-0x960-12"></a>

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.

#### 1.5.2 BOOT\_CFG (0x940-0x950) and BT\_FUSE\_SEL (0x960\[4]) <a href="#id-1.5.2-boot_cfg-0x940-0x950-and-bt_fuse_sel-0x960-4" id="id-1.5.2-boot_cfg-0x940-0x950-and-bt_fuse_sel-0x960-4"></a>

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.

#### 1.5.3 BOOT\_PARAM (0x970-0x9B0) <a href="#id-1.5.3-boot_param-0x970-0x9b0" id="id-1.5.3-boot_param-0x970-0x9b0"></a>

Depending on the boot device and configuration used, there might be additional configurations for boot in the `BOOT_PARAM` fuse words.

#### 1.5.4 ENCRYPT\_XIP\_EN (0x940\[1]) <a href="#id-1.5.4-encrypt_xip_en-0x940-1" id="id-1.5.4-encrypt_xip_en-0x940-1"></a>

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.

#### 1.5.5 ENCRYPT\_XIP\_ENGINE (0x970\[12]) <a href="#id-1.5.5-encrypt_xip_engine-0x970-12" id="id-1.5.5-encrypt_xip_engine-0x970-12"></a>

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.

#### 1.5.6 PUF\_ZEROIZE (0x970\[13]) <a href="#id-1.5.6-puf_zeroize-0x970-13" id="id-1.5.6-puf_zeroize-0x970-13"></a>

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.

#### 1.5.7 BOOT\_CFG\_MISC (0xC70-0xCA0) <a href="#id-1.5.7-boot_cfg_misc-0xc70-0xca0" id="id-1.5.7-boot_cfg_misc-0xc70-0xca0"></a>

Depending on the boot device and configuration used, there might be additional configurations for boot in the `BOOT_CFG_MISC` fuse words.

#### 1.5.8 SDP\_DISABLE, UART\_SDP\_DISABLE, and USB\_SDP\_DISABLE (0x9A0\[0], 0x9A0\[1], and 0x970\[11]) <a href="#id-1.5.8-sdp_disable-uart_sdp_disable-and-usb_sdp_disable-0x9a0-0-0x9a0-1-hardbreak-and-0x970-11" id="id-1.5.8-sdp_disable-uart_sdp_disable-and-usb_sdp_disable-0x9a0-0-0x9a0-1-hardbreak-and-0x970-11"></a>

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.

### 1.6 eFUSE Locking <a href="#id-1.6-efuse-locking" id="id-1.6-efuse-locking"></a>

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.

### 1.7 Secure Fusing Checklist <a href="#id-1.7-secure-fusing-checklist" id="id-1.7-secure-fusing-checklist"></a>

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>

## 2. eFUSE Provisioning <a href="#id-2.-efuse-provisioning" id="id-2.-efuse-provisioning"></a>

### 2.1 Procedure to read eFUSE <a href="#id-2.1-procedure-to-read-efuse" id="id-2.1-procedure-to-read-efuse"></a>

#### 2.1.1 Target Hardware <a href="#id-2.1.1-target-hardware" id="id-2.1.1-target-hardware"></a>

<figure><img src="https://1204947731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtqiX1ZbXhRorHX3bwk1r%2Fuploads%2FgvWOyh51l321CLjaSjNl%2Fimage.png?alt=media&amp;token=d6953177-bd12-41f6-9388-1083cf762d55" alt=""><figcaption></figcaption></figure>

#### 2.1.2 Provisioning IDE <a href="#id-2.1.2-provisioning-ide" id="id-2.1.2-provisioning-ide"></a>

The boot mode shall select the `Unsigned`item if the board hasn’t been provisioned yet.

<figure><img src="https://1204947731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtqiX1ZbXhRorHX3bwk1r%2Fuploads%2FJYBDTBb8nfr2tJYUGmuj%2Fimage.png?alt=media&amp;token=4bf3a4d6-3df6-4ac9-9dc8-a802faa099ee" alt=""><figcaption></figcaption></figure>

We shall conduct to test the connection before reading eFUSE.

<figure><img src="https://1204947731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtqiX1ZbXhRorHX3bwk1r%2Fuploads%2FyFLUbOc6ggKWTvSiSPMp%2Fimage.png?alt=media&amp;token=cd13e809-8fc0-4db1-bc2e-bf31e5f9aef8" alt=""><figcaption></figcaption></figure>

Click the OTP configuration button after testing connection, the OTP (eFUSE) layout will show a GUI window.

<figure><img src="https://1204947731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtqiX1ZbXhRorHX3bwk1r%2Fuploads%2FTxNMI9jIHag1t6CIgQNs%2Fimage.png?alt=media&amp;token=c32e474e-5b36-4b38-a16c-edf1da33c92a" alt=""><figcaption></figcaption></figure>

The eFUSE layout is shown in the GUI window:

<figure><img src="https://1204947731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FtqiX1ZbXhRorHX3bwk1r%2Fuploads%2FYyQTSkeuHNDUGgexRBS1%2Fimage.png?alt=media&amp;token=2987e418-70f7-4416-8d2d-fc48c0a07ecb" alt=""><figcaption></figcaption></figure>

You can make use of the [Secure fusing checklist](https://docs.google.com/spreadsheets/d/1RlmLi1KJTwtNvXfBzEkVtMA9-dK1VGmG7o-WpInvnOA/edit#gid=0) to check each fuse item.