Meta-toradex-security layer

anmsn44 · April 19, 2026, 7:59pm

im using the imx8qm and torizon 6.7. i signed the container using the variables as specified in the meta-toradex security layer docs and i choose to use keys that are already generated by me using the cst tool manually. so by using TDX_IMX_HAB_CST_DIG_ALGO = ”sha256” and TDX_IMX_HAB_CST_KEY_SIZE = “2048“ , do i guarantee that the digest algorithm option used by the SRKTOOL command in CST is sha256 ?

are the keys digest hash needs to be the same as the digest algorithm used in srk tree? and whats the influence of the digest algorithm option used by SRKTOOL ?

ToradexAI · April 19, 2026, 8:00pm

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

To help you properly with the meta-toradex-security layer configuration for your iMX8QM module, I need to clarify your specific setup first.

Could you please specify:

Which exact version of Torizon OS are you running? (You mentioned 6.7, but could you confirm the full version?)
Are you using TorizonCore Builder or building with Yocto directly?

You can get this information by running the tdx-info command on your device. More details are available at: Getting Device Information with Tdx-Info | Toradex Developer Center

Regarding Your Digest Algorithm Questions

Based on the available documentation, when you set TDX_IMX_HAB_CST_DIG_ALGO = "sha256" and TDX_IMX_HAB_CST_KEY_SIZE = "2048", this configuration should align with the digest algorithm used by the SRKTOOL command (1).

The documentation shows that for AHAB-based SoMs (which includes iMX8QM), the srktool command uses the digest algorithm specified in the configuration:

$ cd $CST_DIR/crts
$ ../linux64/bin/srktool -a -s sha256 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -f 1 \
-c ./SRK1_sha256_2048_65537_v3_ca_crt.pem,./SRK2_sha256_2048_65537_v3_ca_crt.pem,./SRK3_sha256_2048_65537_v3_ca_crt.pem,./SRK4_sha256_2048_65537_v3_ca_crt.pem

(1)

The -s sha256 parameter in the srktool command corresponds to your TDX_IMX_HAB_CST_DIG_ALGO setting (1).

However, to provide you with the most accurate guidance for your specific Torizon 6.7 setup and confirm the exact interaction between these variables, please share your platform details so I can give you precise instructions.

Common platforms to consider:

Hardware: Verdin i.MX8M Plus, Verdin AM62, Aquila AM69, Apalis i.MX8QP, Colibri i.MX8X
OS versions: Torizon OS 6.8.2, Torizon OS 7.2.0, BSP 7
Implementation: TorizonCore Builder, Yocto build system

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

anmsn44 · April 19, 2026, 8:02pm

APALIS imx8 and im using torizon os 6.7

ToradexAI · April 19, 2026, 8:02pm

Perfect! Now I can provide specific guidance for your Apalis iMX8 with Torizon OS 6.7 setup.

Digest Algorithm Configuration

Yes, when you set TDX_IMX_HAB_CST_DIG_ALGO = "sha256" and TDX_IMX_HAB_CST_KEY_SIZE = "2048", you are specifying that the digest algorithm used by the SRKTOOL command in CST should be sha256 (1).

According to the meta-toradex-security documentation, the TDX_IMX_HAB_CST_DIG_ALGO variable is described as “Digest algorithm as entered into the CST tool” with a default value of “sha256” (1).

Key Digest Hash and SRK Tree Relationship

The digest algorithm used for the keys must match the digest algorithm used in the SRK tree. This is because:

Certificate Generation: When you generate your certificates with the CST tool manually, the certificate filename includes the digest algorithm (e.g., SRK1_sha256_2048_65537_v3_ca_crt.pem) (1)
Build Process Alignment: The cert filename expected by OpenEmbedded is generated based on the configuration parameters TDX_IMX_HAB_CST_DIG_ALGO and TDX_IMX_HAB_CST_KEY_SIZE (1)
Consistency Requirement: If you use different values when creating the certificates with the CST versus what’s configured in the build system, the certificate file will not be found during the build (1)

SRKTOOL Digest Algorithm Influence

The digest algorithm option used by SRKTOOL has several important influences:

Hash Calculation: It determines how the public keys are hashed when creating the SRK table and fuse values
Certificate Validation: The SoC’s AHAB will use this same algorithm to verify signatures during boot
Security Level: Different algorithms provide different security levels (sha256 is currently the standard)

For Your Apalis iMX8 Setup

Since you’re using Apalis iMX8 (which uses AHAB), ensure that:

Your manually generated certificates use sha256 as the digest algorithm
The certificate filenames match the expected pattern: SRK1_sha256_2048_65537_v3_ca_crt.pem
Your TDX_IMX_HAB_CST_DIG_ALGO = "sha256" setting matches what you used during key generation

This consistency ensures that the build system can locate your certificates and that the AHAB verification process works correctly.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

anmsn44 · April 19, 2026, 8:05pm

Signature Block:
Version: 0
Length: 1368 bytes
Tag: 0x90
Certificate Offset: 0x0
SRK Table/Array Offset: 0x10
SRK Table:
Tag: 0xD7
Length: 1088 bytes
Version: 66
SRK Record:
Tag: 0xE1
Length: 271 bytes
Sign Algorithm: RSA
Hash Algorithm: SHA2_256
Key Size/Curve: RSA2048
SRK Flags: None
Modulus (N):
A787603F2E9F30E1741B880656E5590C448FDC95F7C25D9F282A9B8D9B5C613E
764C03562514D0B948F9E82F84BE816F4ABFC01C1C11046C53F0E41CE45A2780
451FC958B3AF3B388BCE2141829645A8A9D8AFBA93C9971CD963AB20052D6952
4F4AF1D2F22739CAE9BC9996397411319810FD059FCF51A5169690CEE991E4E3
19E12A8D33585172B91E1BECD52B5558C01C883BFAFE536E29B6F1F4D38E91E5
55F7F9CF5DEFB009480C55C3817B2E8BBED1C4DA350D8A76A723194D7125DD19
EAD8BC7860582DF998D3187669F10618561C4D39B741427D2311800CF28B1E8A
2EEFC071A3E7BBEAABA1DB62E852A463595405BF1C38E1C5E97AD82F116206C3
Exponent (E):
010001
SRK Record:
Tag: 0xE1
Length: 271 bytes
Sign Algorithm: RSA
Hash Algorithm: SHA2_256
Key Size/Curve: RSA2048
SRK Flags: None
Modulus (N):
F5EE6DADE6E5E266EA9E318448573C2EDAEBB57376D1B7A77B972DDB679C6E03
72F4028761D9B8735E3B2ED5F9A409D805E993D4188E157A66898421A836CF81
E8CAFDD108AAF731DB171EE8E7D2F827E5DF530321C892AD8169C25C8D4B3270
36EF3F7BBD31F7EEE3569F4E15E0F8976B3746A471D00C824C84792ACA507179
83D0BF67CEA7288263A27343A7DD63013F78629AA60C5A862600A64AA1A4A0A6
5816FBEE2FF7CCAEB316FF6F17DE2B20770D8A0B09DDD149F840436735D8F485
CE1246D26AE4F75EAEB68E07337218F06A7E328CDBFCB327596992C3607D0A33
8D96EC61B4B3A084E478D0AA584AB62DF9A7A7F62DAC1EF394F4BEDA8969EE71
Exponent (E):
010001
SRK Record:
Tag: 0xE1
Length: 271 bytes
Sign Algorithm: RSA
Hash Algorithm: SHA2_256
Key Size/Curve: RSA2048
SRK Flags: None
Modulus (N):
AD6878FED09BB0B9E50AD5EF188276300185EB0741DFA61507043CDE9A2468B1
626D21EC8ADF16346BB0B3D4C9106D6D7418996FB486A7236F0BAA36EF2204D6
19F446B12E1E50D19F791FFEC38830E076E5EE1433C436DFC8E4E4E8949413FB
81CDE9577242AFFD002C23F5EAFC299BD35B802F78409F9E810054C64B4AE775
9E39369B22034D3F43801A122556EACDD60CD8E12220D140DED4241B5BDCE48C
ED508B5E51B55F7A5C9E10C9103179364BB988D10D289D8CB3E84E20419AAC1E
106A1523FBA9A97954A21C0A6C687B72E8CF5558B7AED1959F436882017D77C0
DAA71A7FE28E93FDDF1E9088058E7DF38592C8A09487E7C254E8B514BFA4E2E7
Exponent (E):
010001
SRK Record:
Tag: 0xE1
Length: 271 bytes
Sign Algorithm: RSA
Hash Algorithm: SHA2_256
Key Size/Curve: RSA2048
SRK Flags: None
Modulus (N):
B81491091BB3641E4E0D8B2D328033BD129AD516E77BE6CAB967B66F0569377D
738DB96C3B82F605A3AAD26ABC21200BFF06048D03728BA4B2939A8371072F06
7FA0E0E99520FCA1778E3E054BA52383F83938D150A8CDA82F4121B5D54C836D
00AFBA60A1A7B017875817F2D3A37EF1B978ECC5B48DE29A59AFEFE8029F38B6
9015BAA9DFCE929297345EBA325C9F5BD03DF2165BF702C73D4695A0DCE682B3
EE9E2624A99AD1C9089FE5A412D529F0E90BEBA1D6D731180B575EE92FF23ED2
9228A134D600FAF759BE784E401D77CB7344F678DAD13067869D5DC1EDDA2CE1
3742A6F4744867F6FD2838EA2A936ED7374245A93F2508E334B4F40F29EA3753
Exponent (E):
010001
Blob Offset: 0x0
Key Identifier: 0x0
Signature Data:
45D88B96C3ACC6B5F565C88D6682B8009DF6DC1FCE4A1A54DAD76446390FC6C0
A24AE8C57E0F1F52BD02A8C0B0C0A33BECBDA1997F7BAF1ECB82B35B13A3B651
738CD7E3000135736BD25103A5255F08C66D116B147A3DB6257BC704F640DC6A
F5549E07E37691544CC277B7EEEB5F32C73E25E647C90D4706A65FB47CA6223F
91B1A20572E686B649A325D921C4F402AC254379121DDABAF586BEDDBFEB8385
4A3FBB9FB30159448BECD7ABF9873DF18D0E9104927EC9D450BFA4CF145415F2
FBE364EA3F535D9751CE17F59BC0B8AA081EC9EEFE7ABEDA9101268BB201E062
7A2B2A066514A697949D47843B5A2FED5840E031DBDA7F8FD91B3B9AE5AA14B9
Signature verification successful
Warning: Remember to verify the hash value of the SRK table(s) carefully.

this is the ahab_image_verifier output, this is the signature part

jeremias.tx · April 20, 2026, 6:00pm

do i guarantee that the digest algorithm option used by the SRKTOOL command in CST is sha256 ?

I’m not sure I understand the question. This meta-layer does not directly use the srktool. You are expected to manually use the srktool prior to use this meta-layer when you’re generating all the needed input files.

The TDX_IMX_HAB_CST_DIG_ALGO variables just tells the scripts what algorithm you selected when creating the files. Since the selected algorithm affects the filenames of the generated files. So we need this information for our scripts to find and select the correct files.

are the keys digest hash needs to be the same as the digest algorithm used in srk tree? and whats the influence of the digest algorithm option used by SRKTOOL ?

Again I’m not sure I understand the question here. If you followed the key generation instructions for the cst tool then everything should work as expected.

Best Regards,
Jeremias