Unable to encrypt u-boot with SPL

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Unable to encrypt u-boot with SPL

Jump to solution
1,065 Views
noorahmadshinwa
Contributor III

Hello.

I hope somebody can help me with this issue I have with encrypted boot.

In my scenario I have 3 images: SPL, u-boot and uImage. i have already implemented secure boot (signing only) successfully with all 3 images. I even succeeded in generating an encrypted SPL image that can boot from my signed u-boot. However, when I tried to extend the encryption to u-boot (and hopefully uImage later), I faced some difficulty. Here are the details:

I have a CSF file that will sign the first 44 bytes of the image (header + first word of u-boot entry point) and the last 20 bytes (the IVT). As I understand, This is what is necessary for successful authentication. if I limit the file to this (commenting out the encryption commands), i can successfully authenticate the uboot from SPL.

The trouble is when i introduce [Install Secret Key] and [Decrypt Data]. SPL throws the following message 

Authenticate image from DDR location 0x177fffc0...
spl: ERROR:  image authentication unsuccessful
### ERROR ### Please RESET the board ###

 

I have checked many times and I am not overlapping the authentication and encryption. the size of my u-boot-ivt.img is 0x57020 bytes and it loads to 0x177fffc0,

here is my CSF file:

[Header]
Version = 4.1
Hash Algorithm = sha256
Engine = CAAM
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS

[Install SRK]
File = "../../crts/SRK_1_2_3_4_table.bin"
Source index = 0	# Index of the key location in the SRK table to be installed

[Install CSFK]
# Key used to authenticate the CSF data
File = "../../crts/CSF1_1_sha256_4096_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_4096_65537_v3_usr_crt.pem"

[Authenticate Data]
# Key slot index used to authenticate the image data
Verification index = 2
#        Address      Offset     Length       Data File Path
Blocks = 0x177fffc0   0x0000     0x44   "u-boot-ivt.img", \
 	 0x17856fc0   0x57000     0x20   "u-boot-ivt.img"




[Install Secret Key]
Verification Index = 0
Target Index = 0
Key = "dek.bin"
Key Length = 128
Blob Address = 0x17858f98


[Decrypt Data]
Verification Index = 0
Mac Bytes = 16
Blocks = 0x17800004 0x44 0x56F80 "u-boot-ivt.img"

 

The Blob address was calculated by deciding that my padded csf binary would be 0x1FB8 bytes long (this leaves 72 bytes in the end of the 0x2000 to hold the DEK_BLOB). 0x177fffc0 + 0x57020( size of u-boot-ivt) + 0x1FB8 (padded csf bin without DEK blob)

the encrypted block size is 0x56f80 and not 0x56fbc because I read that the encrypted block must be a multiple of the encryption key size (128). 

Note: I am using CST 3.1.0 and am re-using the DEK and DEK_BLOB that i encrypted the SPL with (using the -d option in cst). 

 

Any help with this would be greatly appreciated.

Thank you.

 

0 Kudos
1 Solution
1,034 Views
noorahmadshinwa
Contributor III

OK. I got it now.
SPL will load bytes into RAM according to the image header. Unlike the boot ROM which (always?) loads 0x2000 bytes in addition to the size of the initial boot image ( which would be SPL in my case).
The problem with my image was that SPL would read ih_size=00058fc0 (this does not include the size of the header itself) from the uboot image header, my uboot header + uboot binary + IVT = 0x57020 bytes.
this leaves (0x58fc0 + 0x40 (header)) - 57020 = 0x1FE0 bytes that will be loaded in addition to the uboot. this is all the space left for the csf+dek_blob.
I was padding my csf to 1FE0 so that the total csf + dek_blob would be 0x2000 (like for SPL image).
it is now obvious that this dek_bob will never be completely loaded into ram by SPL. and that is why the decryption was failing.

I just reduced my padding to allow the dek_blob to be loaded. and it works fine now.
I hope this is useful to someone.

View solution in original post

1 Reply
1,035 Views
noorahmadshinwa
Contributor III

OK. I got it now.
SPL will load bytes into RAM according to the image header. Unlike the boot ROM which (always?) loads 0x2000 bytes in addition to the size of the initial boot image ( which would be SPL in my case).
The problem with my image was that SPL would read ih_size=00058fc0 (this does not include the size of the header itself) from the uboot image header, my uboot header + uboot binary + IVT = 0x57020 bytes.
this leaves (0x58fc0 + 0x40 (header)) - 57020 = 0x1FE0 bytes that will be loaded in addition to the uboot. this is all the space left for the csf+dek_blob.
I was padding my csf to 1FE0 so that the total csf + dek_blob would be 0x2000 (like for SPL image).
it is now obvious that this dek_bob will never be completely loaded into ram by SPL. and that is why the decryption was failing.

I just reduced my padding to allow the dek_blob to be loaded. and it works fine now.
I hope this is useful to someone.