IMX8 QXP AHAB secure boot OEM closed secure boot verification issue

[tthalath]

Iam doing the secure boot varication on IMX8 QXP board , and I corrupted the image hash and expected the seco events are Bad signature and Bad hash (AHAB_BAD_SIGNATURE_IND ,AHAB_BAD_HASH_IND) and note that the life cycle is in OEM closed and i received the below response.

>$ seco events
SECO Event[0] = 0x0087F029
SECO Event[1] = 0x00890029

question :

1. why I didn't get the response  bad hash seco event 

expected response for corrupted image hash  :

$ seco events
 SECO Event[0] = 0x0087F000
SECO Event[1] = 0x0088F100

2. what does the meaning of below seco events 

SECO Event[1] = 0x00890029 ?

3. Even though the response F0 expected but the status I got  29 (The request failed) instead of 00 (The request was successful) ?

[Harvey021]

Hi 

I validated on my side, it's consistent with your results.

1. Change the image hash:

It will return error for authenticating container. Please note that it will not continue to "verify image" if it already failed to authenticate container header, and will jump to "release container". You can refer to the code logic in uboot  ./arch/arm/mach-imx/imx8/ahab.c

2. Modify the image body:

It will return 0x0088F129, indicating image verify failed.

Best regards

Harvey

[mason2036]

tthalath and I know it will get fail. 

That is a test, tthalath  makes the damage. It certainly get fail and event. 

We want to know how to read the event. 

We know the meaning of 0x88, 0x29, etc. Because we can get the meanings in the code, in the headers.

But why has  and what is 0x89 cmd, we cannot get it as 0x88, 0x29 can get in headers.

What does 0x89 mean? (0x29 is correct resp)

1. corrupted hash of img

response :

SECO Event[0] = 0x0087F029

SECOEvent[1] = 0x00890029

And I expected :

SECO Event[0] = 0x0087F000

SECO Event[1] = 0x0088F100

That is question.  

For such long time, as security NXP expert. Do you really know what we are talking about?

[Harvey021]

Hi @tthalath 

Did you change the hash value in the img array, or the content of the image IMG itself? If it is the previous one, then the sig of its container header will not match, so there will be problems. Try to change the IMG itself, don't touch the HASH in CONTAINER HEADER.

If the problem persists, can you send us correctly signed and incorrectly signed images?

Best regards

Harvey

[mason2036]

I believe tthalath is asking you about the test result. 

I think tthalath knows about the hash could not be changed in the real world. 

Just, it is a test  to understand the behaviour and events code decoding. 

[tthalath]

hi thanks for response , I did both , first i corrupted the hash of image array and second i corrupted only the data of img and below are the response .

1. corrupted hash of img 

response : 

SECO Event[0] = 0x0087F029

SECOEvent[1] = 0x00890029

And I expected : 

SECO Event[0] = 0x0087F000

SECO Event[1] = 0x0088F100

2. corrupted img data 

response :

SECO Event[0] = 0x0088F129

And I expected :

SECO Event[0] = 0x0088F100

My question : what is the expected response of seco events for OEM closed board when I corrupt the hash of img array and when only corrupt the img data ?

Note : and this is not problem i am doing the secure boot verification test , attached the normal and corrupted bin files

[Harvey021]

Hi @tthalath 

1. why I didn't get the response  bad hash seco event 

>$ seco events
SECO Event[0] = 0x0087F029
SECO Event[1] = 0x00890029

Please note that the first SECO EVENTS 0x0087F029 means: The "authenticate container" command failed, because signature data is bad.

0x87 - AHAB_AUTH_CONTAINER_REQ 

0xF0 - AHAB_BAD_SIGNATURE_IND

0x29 - the request failed -> it is expected on OEM closed board because the data contained in container header(the part used to calculated the signature) is modified, which cannot match the signature data.

The second SECO EVENT returned is 0x00890029, it means release container. 

0x89 - AHAB_RELEASE_CONTAINER_REQ

- Why there is no "bad hash" event?

As said before, because the "authenticate container" command failed, it will not continue to "verify image", but directly jump to "release container". You can refer to the code logic in uboot  ./arch/arm/mach-imx/imx8/ahab.c

2. what does the meaning of below seco events 

SECO Event[1] = 0x00890029?

As explained in above. It means "release container". 

0x89 - AHAB_RELEASE_CONTAINER_REQ

0x29 - the request failed

3. Even though the response F0 expected but the status I got 29 (The request failed) instead of 00 (The request was successful)?

It is expected on OEM closed board because the AHAB_AUTH_CONTAINER_REQ command failed. 

4. what is the expected response of seco events for OEM closed board when I corrupt the hash of img array and when only corrupt the img data ?

Your results are reasonable. Please see the flows as below:

The complete procedure for authenticating images included in a container is:
• The requestor sends the Authenticate Container message, which will trigger the process of authenticating the container header.
• The requestor sends the Verify Image message, which will request the SECO to validate one or more of the images included in the Image Array of the previously authenticated container header.
• The requestor sends the Release Container message after completing the authentication of images in a container

(1) If you corrupt the hash of image array, it means the data included in "signed part" is corrupt, so the request "Authenticate Container" will fail directly. Then it will directly send "Release Container" request as explained above.

(2) If you only corrupted img data:

The request "Authenticate Container" can pass, then "Verify Image" request fails.

So your results are as expected. Hope these information help you.

Best regards

Harvey

[mason2036]

0x29  should be  AHAB_FAILURE_IND in scfw code headers. 

You expect 0x00  should be  AHAB_SUCCESS_IND. 

But it is not a success.

0x89 here I believe, it is last cmd release container.

[tthalath]

hi 

thanks for the response ,

the thing is i am gettig the exact response for NXP closed life cycle , but not in OEM closed and there is no document available the expected seco events when corrupting the binary (ie image hash , srk , signature),

even though i am getting the right seco event but the status byte is 0x29 and its meant request failed .

and one extra seco event , 0x890029  this event not mentioned any where in the AHAB secure boot docs .

[mason2036]

If you running signed image on NXP close device(chip), it could have event. But  I believe the ROM code will ignore the event. 

But if it is OEM close, I believe the ROM will stop.  

Like 0x29 and some event you can find in scfw code and scfw document.

That is all we have.

0x89 is my guess. Because in scfw documet has container release command. 

I think 0x88 could not be the last command. Because in your first case, you damage the container header. 

But in your second case, you just damage the image not the container. no need to release the container header. 

It is still my guess.  

For real case, you just follow the steps in uboot imx doc. and make sure you have no event with uboot command. 

You do not have to use scfw command to check the event. But for study, scfw command is good way.

https://github.com/nxp-imx/uboot-imx/blob/lf_v2022.04/doc/imx/ahab/guides/mx8_mx8x_secure_boot.txt

1.5.5 Verify SECO events
-------------------------

If the fuses have been written properly, there should be no SECO events after
boot. To validate this, power on the board, and run ahab_status command on
U-Boot terminal.

No events should be returned after this command:

=> ahab_status
Lifecycle: 0x0020, NXP closed

No SECO Events Found!