i.MX8X Secure Boot with encrypted OS container

[arturobuzarra]

Dear NXP,

We are using the i.MX8QXP processor on a custom board to implement Secure Boot. After several tests we are able to build and boot successfully an U-Boot binary signed and encrypted following your Security Reference Manual. Also we are able to build a signed OS container with different binaries (Kernel, Device tree files, boot scripts, etc). However we are blocked adding the encryption to these OS containers.We are using an U-Boot based on your release rel_imx_5.4.47_2.2.0

The simplest test is to try to run a signed U-Boot script. We create this U-Boot script and build it with the mkimage tool. After that we signed it with the CST tool v3.3.1. The output file (in this example we called it boot.src) contains a Container Header and after a few bytes of padding, we have the content of the U-Boot Script. In U-Boot this signed U-Boot Script is successfully authenticated by authenticate_os_container() and we can run it

=> tftp 0x88280000 boot.scr
Using ethernet@5b040000 device
TFTP from server 192.168.1.1; our IP address is 192.168.42.30
Filename 'boot.scr'.
Load address: 0x88280000
Loading: #
         2.1 MiB/s
done
Bytes transferred = 11264 (2c00 hex)
=> auth_cntr 0x88280000                                                     
Authenticate OS container at 0x88280000
container length 888
img 0, dst 0x80280000, src 0x88282000, size 0xc00
memreg 7 0x80020000 -- 0xffffffff
   Authenticate image from DDR location 0x88280000... OK
=>

We are able to check the content of the file in the address 0x88282000 and execute it

=> md.b 0x88282000

Our next test is modify the CSF file to add the "Install Secret Key" section to encrypt the OS Container. After that we obtain an output file (boot.scr) with the same Container Header but in this case the section in the Signature Block for the Blob Offset is set with an offset (in the test case for only signed the container this field is empty with 0x0000), this implies that this container is encrypted and we check that the content of the original U-Boot script is encrypted. We Insert the DEK Blob into this Container Signature Block in the right offset and finally we test it in our device.

However in this case, with the OS container signed and encrypted the authentication works fine but the original content of the U-Boot script remains encrypted after call to the authenticate_os_container() and obviously we cannot run our U-Boot script.

=> tftp 0x88280000  boot.scr               
Using ethernet@5b040000 device
TFTP from server 192.168.1.1; our IP address is 192.168.42.30
Filename 'boot.scr'.
Load address: 0x88280000
Loading: #
         2.1 MiB/s
done
Bytes transferred = 11264 (2c00 hex)
=> auth_cntr 0x88280000                                      
Authenticate OS container at 0x88280000
container length 976
img 0, dst 0x80280000, src 0x88282000, size 0xc00
memreg 7 0x80020000 -- 0xffffffff
   Authenticate image from DDR location 0x88280000... OK
=> md.b 0x88282000                                           
88282000: 3b a7 eb 99 45 d6 50 b1 93 53 e3 e4 b4 e8 64 05    ;...E.P..S....d.
88282010: 3d 9b 91 fd 4a 6b 1a 9f 11 c1 65 c1 b6 4a ab cc    =...Jk....e..J..
88282020: 39 91 d9 19 b6 d3 3e 64 40 8e 4e 8d 2d dc 53 11    9.....>d@.N.-.S.
88282030: 2b be 0c b5 19 e1 51 8c 0e e2 a1 23 97 64 79 43    +.....Q....#.dyC
88282040: ab d1 87 64 c3 5e 56 77 81 bb 3d 89 c9 87 e7 a4    ...d.^Vw..=.....
88282050: b2 c9 af 8b 4b a3 c9 ff f7 3b ce 74 3a eb b3 03    ....K....;.t:...
88282060: 95 66 3f bf 98 81 cf 5f 6f 99 d1 6b 6f 88 73 0e    .f?...._o..ko.s.
88282070: 90 c6 e6 d8 f9 65 c8 35 1c 1f b8 46 e6 58 07 14    .....e.5...F.X..
88282080: 52 4c 8d b9 e7 e2 50 56 76 76 ad 5e f3 d2 c2 ea    RL....PVvv.^....
88282090: 6c 0d bd 33 ce df 51 b8 2d 5a 20 53 2b 00 17 b7    l..3..Q.-Z S+...
882820a0: 95 e6 2e d2 75 25 73 98 37 fc 28 26 16 b6 8a f6    ....u%s.7.(&....
882820b0: f9 56 e1 d2 49 d2 b3 81 7c c9 0d 9c 5a 05 8e bb    .V..I...|...Z...
=>

Could you provide us some guidance about how to fix it?

Best regards

Arturo

[arturobuzarra]

Hi,

After debug the code in deep, we found that the function authenticate_os_container() copy the decrypted content to a different memory position defined in the img->dst variable (it is a different behavior than the HABv4 devices, where the decrypted content in placed in the same source position), but we are not able to find any reference about this behavior into the Security Reference Manual.

Also we found that this destination address is defined in the mkimage_imx8 command line, when the flash_kernel target is called, but here also we not found any reference about this hard coded value.

Could you confirm this behavior?

Could you point us to the right place where this behavior is explained?

Thanks in advance,

Arturo

[igorpadykov]

Hi Arturo

I asked internally about this case, they required additional details:

------------------------

1. Customer wants to sign and encrypt boot image, is the signed boot image successful but the encrypted image failed, right?

2. Which manual they refer to do encrypted boot?

For i.MX6 and i.MX7, they can refer to the AN12056.

-------------------------

For i.MX8X, I sent you additional document via mail.

Best regards
igor

[kanimozhi_t]

@igorpadykov can you share the "AHAB encrypted boot on the i.MX 8QXP" document with us? Thanks in advance.

[paul_geurts]

Hi Arturo,

For i.MX8X, I sent you additional document via mail.

Is this not a publicly available document? If not, can you send it to me as well?

Kind regards

Paul

[arturobuzarra]

Hi Paul,

I think all these docs are under NDA, sorry I can't share them, but the NXP tech support guys could also provide them to you.

Best regards,

Arturo.

[paul_geurts]

Hi Arturo,

OK I will do that. Can you at least provide a document number for that document? Than I can do a specific request.

br, Paul

[arturobuzarra]

Hi Paul,

The document has no PN, the title is "AHAB encrypted boot on the i.MX 8QXP"

Best regards,

Arturo.