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?
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,
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.
@igorpadykov can you share the "AHAB encrypted boot on the i.MX 8QXP" document with us? Thanks in advance.
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?
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.
OK I will do that. Can you at least provide a document number for that document? Than I can do a specific request.
The document has no PN, the title is "AHAB encrypted boot on the i.MX 8QXP"