I am doing tests concerning the usage of secure boot with the complete verdin series modules (TI and NXP modules) for future reference and better understanding of the secure boot process and i have some questions regarding the usage of backup keys.
The TI modules (Verdin AM62 series) have 2 sets of keys for module fuse part (custMpk and backMpk) where the NXP has the option to fuse 4 sets of keys (SRKs).
Are these backup keys usages supported with the current implementation of the secure boot yocto configurations or are these to be developed?
Since the NXP based bbclass (imx-hab.bbclass) states the following:
"
TDX_IMX_HAB_CST_KEY_INDEX: Zero-based index of the SRK to be used within the
SRK table. NOTE: This is not fully handled yet so it should be set to 0.
"
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Thank you for reaching out with your question about secure boot on Verdin modules. Let me provide you with some insights based on the available information:
For the TI-based Verdin AM62 modules, secure boot functionality is supported. According to TI documentation, AES keys are optional and will be automatically generated if not specified.
Regarding the NXP-based Verdin iMX8M Plus modules, they include security features such as Arm TrustZone, High Assurance Boot, and the Cryptographic Acceleration and Assurance Module.
However, when it comes to your specific inquiry about backup keys (custMpk/backMpk for TI and multiple SRK sets for NXP), the current documentation does not provide detailed information on the implementation status or support for these configurations within the Yocto build system.
For further details, I recommend checking the official Toradex documentation and resources, such as the Toradex Developer Center, for the most up-to-date information on secure boot implementations.
If you have any more questions or need further assistance, feel free to ask!
That comment does seem to suggest the usage of the other key indexes is not supported currently. Let me raise this question with our team and double-check whether the comment is still accurate. As well as our own plants to implement the usage of the backup keys in the build.
My understanding was that the other SRKs can be programmed in order to do revocation. On the NXP that is done by blowing e-fuses and the code always points to zero as the fuses will set the first SRK that is not revoked at that index.
Yes, you can revoke any of (up to) 4 SRK’s on NXP. But to have something to revoke you need to provide them in advance. You can’t add more SRK’s or change them after SRK hash fuse pattern is fused to target.
So you have up to 4 keys, SRK fuse pattern fused. You may sign your image with any out of those 4 keys, which where used to create SRK fuse pattern (table) using srktool. SRKINDEX and key file belonging to the same index in SRK table should match in csf file:
[Install SRK]
Source index = <SRKINDEX>
[Install CSFK]
File = “CST_CSF_CERT_<SRKINDEX>”
You may revoke simultaneously more than one SRK’s or one, then later another one or more SRKs burning corresponding revocation bit fuse(s). This will make HAB authentication fail for images signed with formerly valid but revoked SRKINDEX.
# Determine key index (use file name)
local kidx
kidx=${TDX_IMX_HAB_CST_SRK_CERT##*/}
kidx=${kidx##SRK}
kidx=${kidx%%_*}
if [ "${#kidx}" != 1 ]; then
echo "Certificate file name (defined by TDX_IMX_HAB_CST_SRK_CERT) does" \
"not match expected pattern - could not determine key index."
exit 1
fi
kidx=$((kidx - 1))
Note from docs you cited seems being little weird. There’s revocation (bit)mask, not revocation index. It is stated so somewhere, could look for if you wish. Mask allows to revoke any indexes at your will. So I’m not sure what does that note really mean. Does it mean you could revoke idx3 first, than indexes 0 to 2 in any order, and with all keys “revoked” idx3 will get unrevoked forever? I don’t know fuse, which would tell which index is “revoked last”. So, shouldn’t be bricked chip with all keys revoked treated as smaller security concern than such unrevoking feature? So the best you should do, with 3 keys revoked disable writing to revoke fuses with SRK_REVOKE_
LOCK fuse.
Regarding the revocation, i have no further experience with this and only found that in the manual which was present in the CST generation tool which i got via NXP.
I brought this topic up briefly with our team internally. At the moment we haven’t really explored or tried using the backup keys to sign the image during the Yocto build. It’s not quite known yet what changes will be needed to accommodate this in the meta-layer, and it will require some investigation from the team.
That said I don’t have any timeline or anything to provide yet considering I just had the initial conversation with the team.
@RiBe_Act, just checking is this something you urgently need, or are you just checking these things out early on?
It not something we urgently need but we plan to use the Verdin series modules for all future Linux based projects and secure boot is a part of our development process with the coming of all new regulations regarding cyber security so i want to understand as much of it as possible, and how to use the backup keys feature (should we need to use it).
I too will be following this as we have just finished developing our solution which is now in manufacturing. We had not dug that deep and just assumed it would already be possible to sign using an alternative key.
I will have to make a note on this for our support desk so we can raise again if needed later.
