Hello,
I am trying to completely secure boot on i.MX6UL (provide encrypted nad signed u-boot (boot loader second stage) image).
Signing is working. The SPL is authenticate and hab_status do not report any events.
To sign and encrypt SPL (without IVT and DCD and Boot data) I use following CSF file:
[Header]
Version = 4.2
Security Configuration = Open
Hash Algorithm = sha256
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS
Engine = CAAM
[Install SRK]
File = "../crts/SRK_1_2_3_4_table.bin"
Source index = 0
[Install CSFK]
File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
[Install Key]
Verification index = 0
Target Index = 2
File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
[Authenticate Data]
Verification index = 2
Blocks = 0x00907400 0x00000000 0x00008c00 "./SPL"
#0x00907400 - start of area in RAM to be authenticate
#0x00000000 - start of area in SPL to sign
#0x00008c00 - size of area in SPL to sign (include IVT and DCD)
If the CSF file ends here the signing is working
#Encrypt the boot image and create a DEK
[Install Secret Key]
Verification Index = 0
#Master KEK index - 0 = OTPMK fuses
Target Index = 2
Key = "./dek.bin"
Key Length = 192
Blob Address = 0x00911fb0
How to calculate this blob address?
[Decrypt Data]
Verification Index = 2
Mac Bytes = 16
#The CST encrypts only image data of SPL.
Blocks = 0x00907400 0x1174 0x7a8c "./SPL"
What should contain Blocks?
When the CSF file ends here the evk do not boot from sd card.
Next step (in theory) is to boot signed image + DEK and run dek_blob 0x82000000 0x83000000 192 to generate dek blob.
If I run above command in u-boot which is only signed I get:
Encapsulating provided DEK to form blob 0x82000000
Error in SEC deq
Error in Encapsulation -1
Command failed, result=-1
I think that in section [Install Secret Key] and [Decrypt Data] Block address and Block could be incorrect.
What is the structure of signed and encrypted image? (IVT, Boot data, DCD, u-boot, HAB data, DEK). What are the offsets of each parts in SPL?
Does anyone had run signed and encrypted SPL on i.MX6UL?
已解决! 转到解答。
Hello Robert,
How to calculate this blob address?
After you have generated the DEK blob by issuing dek_blob command in u-boot with dek.bin in memory, you need to append it to the boot image, preferably after the HAB data used for authentication. Keep in mind that DEK blob must fit within the load region, which, by default, is (sizeof(u-boot.imx) + 0x2000). For example, with 128-bit AES:
cat u-boot.imx hab-data_padded.bin dek_blob.bin > u-boot_encrypted.imx
u-boot.imx: 0x5EC00
hab-data_padded.bin: 0x1FB8
dek_blob.bin: 0x48
Total encrypted image size: 0x60C00
HAB data and DEK blob fit in the 0x2000 extra bytes of load region set by imximage when building secure uboot.
By default, the boot address with i.MX6UL is 0x87800000, that is where u-boot.bin goes. u-boot.imx prepends a 0xc00 bytes header, so it is loaded to 0x877FF400. Adding uboot.imx size, 0x5EC00, and hab-data_padded to the load address, gives 0x8785FFB8 - this is where dek_blob will be loaded into DRAM, the last 0x48 bytes of the load image.
What should contain Blocks?
First argument - start address of the region to be encrypted/decrypted in DRAM. I suggest to set this to the entry point.
Second argument - offset from the start of the file (on your build system). cst encrypts the data, so you need to skip the 0xc00-byte header to be able to boot. You need to encrypt only the part of the image which corresponds to u-boot.bin.
Third argument - length of the data section to be verified or encrypted/decrypted
Please note: you do not need to sign anything beyond the entry point, as it is already authenticated by the [Decrypt Data] step.
Caveat #1: You may need to use the patch in the attachment, if you have not already done so.
Caveat #2: When using dek_blob in u-boot, first disable the cache memories (icache off, dcache off).
Please let me know if you have any other questions, in this thread or by e-mail.
Apologies for the long time to respond to your request.
Kind Regards,
Witek Ewert
Please check this patch series posted in the U-Boot list:
[U-Boot] [PATCH 0/5] arm: imx6: Enable Secure Boot (HAB) with SPL Builds
Hello Robert,
I am having trouble with the getting the signed SPL running. The errors tell me that the DCD data is not signed properly.
My SPL image hexdump is follows:
Can you please check your hexdump and tell me if its similar. Also do you know where SPL's DCD information which is used to initialize the RAM is present?
Thanks & Greets,
Satya
Hello Satya,
Unfortunately, right now I'm using the old fashioned one file u-boot. I know for sure that the DCD pointer is located in the offset 12 of the IVI structure (one file u-boot):
od -x -N 48 u-boot.imx
0000000 00d1 4020 0000 8780 0000 0000 f42c 877f 0000020 f420 877f f400 877f a000 8788 0000 0000 0000040 f000 877f f000 0008 0000 0000 01d2 40e8 0000060
Offset | Name | Value |
---|---|---|
0 | vt.header | 0x402000d1 |
4 | ivt.entry | 0x87800000 |
8 | ivt.reserved1 | 0x00000000 |
12 | ivt.dcd_ptr | 0x877ff42c |
16 | ivt.boot_data_ptr | 0x877f420 |
20 | ivt.self | 0x877ff400 |
24 | ivt.csf | 0x8788000a |
28 | ivt.reserved2 | 0x00000000 |
32 | boot_data.start | 0x877ff000 |
36 | boot_data.size | 0x0008f000 |
In fact, I tested the U-Boot is case of signing and encrypting - it works.
repo: git://git.freescale.com/imx/uboot-imx.git
branch: imx_v2016.03_4.1.15_2.0.0_ga
config: mx6ul_14x14_evk_...
What errors you get about DCD? What is your section [Authenticate Data] in CSF? Did you compile u-boot with V=1 option? (make -j8 V=1)
Hello Robert,
I solved my problem by removing DCD address from IVT. I explained it here https://community.nxp.com/thread/438580 . Please have a look.
Greets,
Satya
Hi Robert,
My HAB erros for SPL is as follows:
The meaning of the error code is as follows:
0x33 - HAB failure
0x06 - Invalid Command
0xC0 - Executing DCD or CSF
0x00 - Engine
0xcc 0x00 0x04 0x04 - This hex stuff is the command that has to be executed "cc 00 04 04".
0xcc - Write Data
0x00 & 0x04 is the length which is 4 bytes
0x04 - parameter which means the address is 32 bit value.
The CSF Authenticate is as follows
[Header]
Version = 4.0
Hash Algorithm = sha256
Engine = ANY
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS
[Install SRK]
File = "../crts/SRK_1_2_3_4_table.bin"
Source Index = 0
[Install CSFK]
File = "../crts/CSF1_1_sha256_3072_65537_v3_usr_crt.pem"
[Authenticate CSF]
[Install Key]
Verification index = 0
Target Index = 2
File = "../crts/IMG1_1_sha256_3072_65537_v3_usr_crt.pem"
[Authenticate Data]
Verification index = 2
Blocks = 0x00907400 0x400 0x9C00 "../u-boot-denx/SPL.imx"
The values with V=1 in make matches with my CSF values. The error is with DCD data. In my case it is kinda empty, not really empty but only 4 bytes in length. On the other hand my single stage booting works well in SECURE_BOOT.
I hope the ENGINE=Any is not a problem. Can you get any info from the error messages?
Greets,
Satya
Hello Robert,
How to calculate this blob address?
After you have generated the DEK blob by issuing dek_blob command in u-boot with dek.bin in memory, you need to append it to the boot image, preferably after the HAB data used for authentication. Keep in mind that DEK blob must fit within the load region, which, by default, is (sizeof(u-boot.imx) + 0x2000). For example, with 128-bit AES:
cat u-boot.imx hab-data_padded.bin dek_blob.bin > u-boot_encrypted.imx
u-boot.imx: 0x5EC00
hab-data_padded.bin: 0x1FB8
dek_blob.bin: 0x48
Total encrypted image size: 0x60C00
HAB data and DEK blob fit in the 0x2000 extra bytes of load region set by imximage when building secure uboot.
By default, the boot address with i.MX6UL is 0x87800000, that is where u-boot.bin goes. u-boot.imx prepends a 0xc00 bytes header, so it is loaded to 0x877FF400. Adding uboot.imx size, 0x5EC00, and hab-data_padded to the load address, gives 0x8785FFB8 - this is where dek_blob will be loaded into DRAM, the last 0x48 bytes of the load image.
What should contain Blocks?
First argument - start address of the region to be encrypted/decrypted in DRAM. I suggest to set this to the entry point.
Second argument - offset from the start of the file (on your build system). cst encrypts the data, so you need to skip the 0xc00-byte header to be able to boot. You need to encrypt only the part of the image which corresponds to u-boot.bin.
Third argument - length of the data section to be verified or encrypted/decrypted
Please note: you do not need to sign anything beyond the entry point, as it is already authenticated by the [Decrypt Data] step.
Caveat #1: You may need to use the patch in the attachment, if you have not already done so.
Caveat #2: When using dek_blob in u-boot, first disable the cache memories (icache off, dcache off).
Please let me know if you have any other questions, in this thread or by e-mail.
Apologies for the long time to respond to your request.
Kind Regards,
Witek Ewert
Hey Witekewert,
Do you have a patch for the imx6ull secure memory registars?
The iMX6ULL does not support CAAM, and CAAM is hard coded in. So is there a patch for the iMX6ULL?
Thanks for the help!
Hello,
Please refer to the following : Encrypted boot loader on SabreSD i.MX6q board
Have a great day,
Yuri
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------