- 1. Background
- 2. Issue description
- 3. Impacted devices
- 4. Workarounds
- 4.1 Do not re-install a key if the key slot is already being used.
- 4.2 Use only one Authenticate Data command per CSF.
- 4.3 Prevent Unlock CSF from being added by CST.
- 4.4 Remove any unnecessary commands from CSF.
- 4.5 Do not add extensions to key certificates.
- 5. Conclusion
1. Background
The HABv4 in Boot ROM allows users to store up to 5 public keys (1 SRK, 1 CSF Key, 3 IMG Keys) to Key Indexes which can be used to authenticate boot images. The current implementation of hab4_pki_tree.sh script generates a basic PKI tree that contains up to 4 SRKs with a single CSF key and IMG key per SRK. If necessary users can generate additional keys using OpenSSL or add_key.sh script.
In the default configuration, HAB installs SRK in slot 0, CSF Key in slot 1, and IMG Keys in slots 2-4. Users can store additional IMG keys in the remaining slots by adding an Install Key command in CSF.
- Key Index 0 = SRK Table
- Key Index 1 = CSF Key
- Key Index 2 = IMG Key
- Key Index 3 = IMG Key (Optional)
- Key Index 4 = IMG Key (Optional)
In HABv4 it is possible to include up to four SRKs in a signed image, although only one SRK can be used per reset cycle. Additional IMG keys must be generated from the same SRK.
When HAB processes the Install Key command it verifies the Target Index, copies the key to respective Key Index in OCRAM HAB Persistent Memory Region, and validates the Key against the SRK defined in the Verification index.
[Install Key]
Verification index = 0
Target Index = 2
File= "../crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem"
Overwriting occupied key slots is not allowed, although a repeated command to reinstall the same public key occupying the target slot will allocate the persistent memory, decode the key and compare it with the key already installed on this slot.
2. Issue description
Due to a memory limitation in OCRAM Persistent Memory Region in HAB versions prior to v4.4.0, users storing multiple IMG keys can face an Exhausted Storage Region (HAB_OVR_STORAGE) error in certain i.MX devices which indicate that the system is low in persistent memory.
--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x1c 0x42 0x33 0x2d 0xc0 0x00
0xca 0x00 0x14 0x00 0x04 0xc5 0x1d 0x00
0x00 0x00 0x10 0x10 0x19 0x00 0x00 0x00
0x00 0x00 0xd0 0x20STS = HAB_FAILURE (0x33)
RSN = HAB_OVR_STORAGE (0x2D)
CTX = HAB_CTX_COMMAND (0xC0)
ENG = HAB_ENG_ANY (0x00)
This issue only happens with 4096-bit or 3072-bit* IMG keys, multiple smaller keys can be stored in OCRAM Persistent Memory Region without errors.
In i.MX 8MQ TO 1.0 the available HAB persistent memory can be lower due to the presence of a 2048-bit HDMI firmware key. In this case the issue can happen when trying to re-install the third 3072-bit IMG key.
3. Impacted devices
The following devices are impacted by this limitation:
| Device | Silicon Revision (TO) |
|---|---|
| i.MX 8MQ | 1.0 |
| i.MX 8MM | 1.0 |
| i.MX 7ULP | 2.0 |
| i.MX 7SD | 1.1 -> 1.3 |
| i.MX 6DQP | 1.0 -> 1.1 |
| i.MX 6DQ | 1.2 -> 1.6 |
| i.MX 6DLS | 1.1 -> 1.4 |
| i.MX 6SX | 1.2 -> 1.4 |
| i.MX 6SL | 1.2 -> 1.4 |
| i.MX 6SLL | 1.0 -> 1.1 |
| i.MX 6UL | 1.1 -> 1.2 |
| i.MX 6ULL | 1.0 -> 1.1 |
| i.MX 6ULZ | 1.0 |
| i.MX RT1050 | 1.0 -> 1.1 |
| i.MX RT1020 | 1.0 |
Users storing multiples IMG keys can adopt the workarounds mentioned in this document to prevent this issue.
The HAB_OVR_STORAGE event can happen when trying to install the third 4096-bit IMG key in the following devices:
• i.MX 7ULP 2.0
• i.MX 7SD 1.0 → 1.3
• i.MX 6DQP 1.0
• i.MX 6DQ 1.1 → 1.3
• i.MX 6DLS 1.1 → 1.3
• i.MX 6SX 1.2 → 1.3
• i.MX 6SL 1.2 → 1.4
• i.MX 6SLL 1.0 → 1.1
• i.MX 6UL 1.0 → 1.1
• i.MX 6ULL 1.0 → 1.1
• i.MX RT1050 1.0 → 1.1
• i.MX RT1020 1.0
In certain devices affected by the RNG self-test issue or CAAM manufacturing protection issue the available HAB persistent memory is lower due to the presence of a HAB Warning on this memory region. In this case, this event can happen when trying to install the second 4096-bit IMG Key:
• i.MX 8MQ 1.0
• i.MX 8MM 1.0
• i.MX 6DQP 1.1
• i.MX 6DQ 1.6
• i.MX 6SX 1.4
• i.MX 6UL 1.2
• i.MX 6SDL 1.4
In i.MX8MQ TO 1.0 the available HAB persistent memory can be lower due to the presence of a 2048-bit HDMI firmware key. In this case, the issue can occurs when trying to re-install the third 3072-bit IMG key.
4. Workarounds
The workaround for this issue is to preserve the HAB persistent memory region. We recommend users to use smaller keys, 3072-bit keys gives a good margin.
In case using a signed HDMI firmware in i.MX8MQ TO 1.0 it’s recommended to use 2048-bit keys.
In case it’s required to use multiple 4096-bit keys the following methods can be adopted in order to preserve persistent memory region:
4.1 Do not re-install a key if the key slot is already being used.
The current CST implementation does not allow the user to sign an image without installing the respective key, the following two commands are mandatory in CSF:
[Install Key]
Verification index = 0
Target Index = 2
File= "../crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem"
[Authenticate Data]
Verification index = 2
Blocks = <image_load_addr> 0x0 0x<image_size> "image1.bin"
When authenticating an image the HAB code encounters an Install Key command, it attempts to copy this key to persistent memory before checking if it matches the one already installed in the key slot. In a situation with 4 or more 4096-bit keys that are installed the re-installation of a key may cause an out of memory error.
In order to avoid the key re-installation users can use the same CSF file that installed the key for the first time. This can be achieved by following the next method.
4.2 Use only one Authenticate Data command per CSF.
When authenticating multiple images or regions with the same key, a single Authenticate Data command can be used, users can use multiple blocks lines as the example below:
[Authenticate Data]
Verification index = 4
Blocks = 0x<image_load_addr> 0x0 0x<image_size> "imageX.bin", \
0x<image_load_addr> 0x0 0x<image_size> "imageX.bin"
4.3 Prevent Unlock CSF from being added by CST.
This can be achieved by setting Engine=SW or Engine=ANY in CSF Header.
Setting Engine=SW increases the boot time since the image authentication is not hardware accelerated.
[Header]
Version = 4.2
Hash Algorithm = sha256
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS
Engine = ANY
Users need to make sure RNG_TRIM fuse is set appropriately otherwise the board may fail to boot in closed mode, for more details please check AN4581.
4.4 Remove any unnecessary commands from CSF.
Make sure to have only necessary commands in CSF file. For more details on each command and its purpose please refer to CST user’s guide in CST package.
4.5 Do not add extensions to key certificates.
The use of extension in key certificates may require more space in OCRAM persistent memory region, avoiding its use can preserve the persistent region. Customer planning to use this feature should refer to Optional Extended Key Usage x.509 Extension not Supported document.
5. Conclusion
Adopting the methods mentioned on this document it’s possible to use one extra key slot. For a full list of the number of 4096-bit IMG keys supported please check the table below.
| Device | Silicon Revision (TO) | IMG Keys supported |
|---|---|---|
| i.MX 8MQ[1] | 1.0 | 2 |
| i.MX 8MM[2] | 1.0 | 2 |
| i.MX 7ULP | 2.0 | 3 |
| i.MX 7SD | 1.1 -> 1.3 | 3 |
| i.MX 6DQP | 1.0 | 3 |
| 1.1 | 2 | |
| i.MX 6DQ | 1.1 -> 1.3 | 3 |
| 1.6 | 2 | |
| i.MX 6DLS | 1.1 -> 1.3 | 3 |
| 1.4 | 2 | |
| i.MX 6SX | 1.2 -> 1.3 | 3 |
| 1.4 | 2 | |
| i.MX 6SL | 1.2 -> 1.4 | 3 |
| i.MX 6SLL | 1.0 -> 1.1 | 3 |
| i.MX 6UL | 1.0 -> 1.1 | 3 |
| 1.2 | 2 | |
| i.MX 6ULL | 1.0 -> 1.1 | 3 |
| i.MX 6ULZ | 1.0 | 3 |
| i.MX RT1050 | 1.0 -> 1.1 | 3 |
| i.MX RT1020 | 1.0 | 3 |
[1]: In case using a signed HDMI firmware in i.MX8 MQ TO 2.0 it’s possible to use 3x 3092-bit IMG keys by adopting the methods mentioned in this document.
[2]: In case SoC is not impacted by the CAAM manufacturing protection issue it's possible to use up to 3x 4096-bit keys.
In devices supporting HAB v4.4.0 or newer it's possible to store up to 3 4096-bit image keys.
This issue does not impact the Secure Boot flow and does not compromise the i.MX security.
