HAB secure boot on the imx8mp processor

Technical Support
, ,
1

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x40 0x1f 0xdd 0xc0
0x00 0x00 0x00 0x20

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)

--------- HAB Event 2 -----------------
event data:
0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x40 0x1f 0xcd 0xc0
0x00 0x00 0x00 0x04

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_ASSERTION (0x0C)
CTX = HAB_CTX_ASSERT (0xA0)
ENG = HAB_ENG_ANY (0x00)

--------- HAB Event 3 -----------------
event data:
0xdb 0x00 0x34 0x45 0x33 0x18 0xc0 0x00
0xca 0x00 0x2c 0x00 0x02 0xc5 0x1d 0x00
0x00 0x00 0x0b 0x50 0x40 0x1f 0xcd 0xc0
0x00 0x00 0x10 0x20 0x40 0x20 0x00 0x00
0x00 0x0c 0x3f 0x30 0x40 0x2c 0x3f 0x30
0x00 0x00 0xbf 0x20 0x00 0x97 0x00 0x00
0x00 0x00 0xa1 0x50

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_SIGNATURE (0x18)
CTX = HAB_CTX_COMMAND (0xC0)
ENG = HAB_ENG_ANY (0x00)

--------- HAB Event 4 -----------------
event data:
0xdb 0x00 0x34 0x45 0x33 0x18 0xc0 0x00
0xca 0x00 0x2c 0x00 0x02 0xc5 0x1d 0x00
0x00 0x00 0x0b 0x50 0x40 0x1f 0xcd 0xc0
0x00 0x00 0x10 0x20 0x40 0x20 0x00 0x00
0x00 0x0c 0x3f 0x30 0x40 0x2c 0x3f 0x30
0x00 0x00 0xbf 0x20 0x00 0x97 0x00 0x00
0x00 0x00 0xa1 0x50

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_SIGNATURE (0x18)
CTX = HAB_CTX_COMMAND (0xC0)
ENG = HAB_ENG_ANY (0x00)

hello all,

I get these HAB events when tying to secure boot the processor.

looks like there is something wrong with my second stage fit image key judging by the address.

here is the cert file for my second stage fit image

[Install CSFK]

Key used to authenticate the CSF data

File = “…/…/crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem”

[Authenticate CSF]

[Install Key]

Key slot index used to authenticate the key to be installed

Verification index = 0

Target key slot in HAB key store where key will be installed

Target index = 2

Key to install

File = “…/…/crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem”

[Authenticate Data]

Key slot index used to authenticate the image data

Verification index = 2

Authenticate Start Address, Offset, Length and file

Blocks = 0x401fcdc0 0x60000 0x1020 “imx-boot”,
0x40200000 0x53000 0xC3F30 “imx-boot”,
0x402C3F30 0x116F30 0xBF20 “imx-boot”,
0x970000 0x122E50 0xA150 “imx-boot”

I have not blown any fuses yet, would this make the error go away? as currently you would expect the key to be wrong as it will be comparing against a random set of data in the fuses.

any help would be much appreciated

2

Greetings @solaire,

So if I understood correctly, you generated the signed binaries and flashed them to the device, but you haven’t set any fuses yet, correct? Not even the fuses related to your keys?

If that is the case then it would be expected to have HAB events since the validation process fails without the fuse keys being set. That said in theory setting those fuses should make the HAB events go away, assuming you got everything else correct. Just make sure to not set the final closing fuse until you are confident everything is correct.

By the way, did you take into account the issue described in this thread here: https://community.nxp.com/t5/i-MX-Processors/imx8mp-HAB/m-p/1546498#M197035

Otherwise you’ll run into a similar issue as well.

On a final note, we’re in the process of creating a Yocto meta-layer that will automate the HAB process via Yocto build. This layer can be found here: GitHub - toradex/meta-toradex-security

It’s still a work in progress but at least Verdin i.MX8M Plus has been tested. Perhaps this can be of assistance if you run into further issues.

Best Regards,
Jeremias

3

@solaire If my notes are correct, then the hab events will go away once you close the device.
I saw the same codes (config, state, sts, rsn, ctx, and eng) in my environment with SRK fused but not yet closed.

4

NO! Closing with any hab events in the log will brick it! You need clear HAB event log, only then you are almost safe to close.

Once closed, suppose you brick your target somehow, uuu and imx_usb won’t let you recover, unless you have specially crafted image, which HAB authenticates via uuu/imx_usb. So you should definitely check what your HAB log looks like USB recovering not yet closed device. HAB logs should be clear as well, else secure recovery won’t be possible. I’ve no details about imx8, but both imx7 and imx6ull need different, specially crafted u-boot images, different for uuu, imx_usb and native boot!

uuu needs to add additional auth block for IVT+DCD in OCRAM.
imx_usb additionally to above needs image signed with IVT.DCD pointer cleared. Isn’t it too complicated already? No :-). csf for uuu and for imx_usb use different OCRAM addresses for IVT+DCD!

No matter what guides and blocks tell you, you shouldn’t fuse anything until you manage to clean HAB log with fuses not touched.

Do you need fast auth or slow auth? You can’t change your decision without loosing fused device. So you should avoid fusing until you decide do you need fast authentication or standard, and sha or ec keys, as well decide 4096 or shorter keys. And only then fuse.

SRT certainly shouldn’t be fused in advance. Clean SRT auths all properly signed images, it just doesn’t matter what SRT is on your PC until SRT isn’t fused to target. It’s true at least for VF/imx6ull/imx7.
Even encrypted boot is doable without fusing, CAAM blob is used for encryption/decryption, not SRT.

See chapter 5.5 in AN4581. Only very old HAB versions required to fuse at least SRK to check signing. Since 4.1.2 it is fixed. imx7 uses 4.2.x.

image
image1197Ă—304 29.7 KB

Edward

5

thanks for all the help! Ed you are right you will brick a board this way. If anyone else it trying this highly recommend Jeremias advice to use the tdx-meta-security layer if your board is supported.
link is hear GitHub - toradex/meta-toradex-security.

1 Like
6

Hi @solaire ,

if the issue is solved you might want to mark the answer as a solution. That would help others to find their way.

Best Regards
Kevin