Referring the above doc, I was able to create a signed u-boot binary, after which on trying to create a signed kernel image binary, I got some error.
I had followed the steps as per the document, and then on step 16, while running the script ‘habUimagegen’, I am getting the following error: “Unsupported argument: Blocks in command InstallKey”
I had asked about this error in NXP Support. They replied that the reference I am using is quite old for old BSP and asked me to to raise a case to Toradex, referring your new references for the signing.
Can you please direct me to the right reference that can be used for the HAB process?
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
For enabling Secure Boot on the Toradex Colibri iMX6ULL module and dealing with issues related to the High Assurance Boot (HAB) process, it’s crucial to follow the guidelines specific to the Toradex environment and the NXP i.MX processors. While the document you referred to from NXP is a good starting point, Toradex provides tailored support for Secure Boot through its documentation and resources tailored to its modules.
The error you encountered, “Unsupported argument: Blocks in command InstallKey,” suggests there might be a discrepancy between the script’s expectations and the arguments provided or a version mismatch between the tools and the BSP (Board Support Package) you are using.
For the Colibri iMX6ULL, the process involves several steps, including generating the necessary cryptographic keys, signing the U-Boot bootloader, and then ensuring the kernel and any other boot components are also signed correctly. This process ensures that only authenticated code runs on the device, a critical aspect of Secure Boot.
Given the specific nature of your issue and without direct access to the latest Toradex documentation or tools updates, I recommend the following general steps to address the problem:
Ensure Compatibility: Verify that the version of the tools you are using for the HAB process is compatible with the BSP version deployed on your Colibri iMX6ULL. Toradex periodically updates its BSPs, and using a version-matched toolchain is crucial.
Review Secure Boot Documentation: While I cannot direct you to specific documents, Toradex provides comprehensive guides and application notes on Secure Boot implementation for its modules. These documents typically cover the generation of keys, signing of binaries, and troubleshooting common issues.
Use Toradex-Specific Tools: If Toradex provides specific tools or scripts for the HAB process, ensure you are using these, as they are likely optimized for the hardware and may include workarounds for known issues.
Check for Updates or Patches: Sometimes, the issue might be known to Toradex, and there could be updates or patches available that address the specific error you are encountering.
Secure Boot Configuration: Ensure that the Secure Boot configuration on the iMX6ULL is correctly set up to accept your signed binaries. This might involve configuring fuses or settings within the U-Boot environment.
Error Analysis: Analyze the error message in detail. Sometimes, the issue could be related to the format or type of the key being used, or specific
Please, also check if these links can help you solve your problem:
It means you have wrong *.csf file. Commands in *.csf are words and phrases in square brackets. Lines without square brackets belong to the command in last one line with square brackets. Like this
[ X ]
part of X command
part of X command
…
[Y]
part of Y
part of Y
…
[InstallKey] is one of such commands. “Blocks =” can’t be specified inside [InstallKey] command. it can be only inside [Authenticate Data] command.
I’m not sure if you are aware, but we do have our own meta-layer for implementing a chain of trust on our hardware: GitHub - toradex/meta-toradex-security
That said we only use HAB to sign and verify the bootloader binary. For the kernel we use FIT image verification instead.
Is there a specific reason you want to use HAB to also validate the kernel? I know the NXP documentation states this is possible. But it’d be helpful to know if there was a reason you specifically want to use HAB to validate the kernel rather than some other method.
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
For enabling Secure Boot on the Toradex Colibri iMX6ULL, you should follow the steps outlined in the Toradex documentation for Secure Boot. Here is a summary of the key steps you need to follow:
Setup Yocto Project: Ensure your host PC is set up for building Torizon OS from source. Add the necessary configurations to your conf/local.conf file.
Generate Keys and Certificates: Create a PKI tree, SRK tables, and Efuse hash. Store these securely as they are critical for signing software and verifying authenticity.
Build Secure Boot Image: Use the Yocto Project/OpenEmbedded build system to generate a Torizon OS image with Secure Boot support. Ensure you have the meta-toradex-security layer included in your build.
Flash the Secure Boot Image: Use the Toradex Easy Installer to flash the unfused Toradex SoM. Note that the Easy Installer does not support burning Efuses out-of-the-box.
Burn Efuses: Access the U-Boot CLI via the debug serial interface to burn the Efuses. This step is crucial to enable Secure Boot and ensure the boot ROM validates the bootloader.
Key Management: Manage your signing keys with care. You can burn up to four Efuse hashes on the SoC HAB/AHAB, allowing you to have multiple valid signing keys.
For the specific error you encountered with the habUimagegen script, it seems related to an outdated reference. Ensure you are using the latest tools and scripts provided by Toradex and NXP. The error message “Unsupported argument: Blocks in command InstallKey” suggests that the script or command you are using is not compatible with the current BSP or toolchain.
If you need further assistance with the specific steps or encounter additional issues, please provide more details about the exact commands and configurations you are using.
Steps 2 and 6 are out of order. You do step 2 once for product, so that further OTA / non-OTA updates are fine with the same SRK, which is fused to target, which is already in the field. Of course you may change keys (SRK) more often , but you won’t be able to use new image, signed with new key (and SRK) on target, which is fused with old SRK.
Step 6, eh, four Efuse hashes? Definitely not true. Four hashes are somehow summed to form single Efuse SRK. You need to fuse whole SRK, not parts of it, to make each out of 4 hashes to work signing images. You may ban any out of 4 hashes (burning some further fuses), so that only image with not yet banned hash will pass authentication.
