AN12056 Encrypted boot application note questions.

[noorahmadshinwa]

Hi Everyone!

I have been implementing encrypted boot according to the AN12056 document on an i.mx6 board, and I have the following questions:

1. Why does the document say that the csf binary should be padded to size 0x2000 and that the DEK_blob should be added after that?
according to the knowledge base document (https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Encrypted-boot-loader-on-SabreSD-i-MX6q-...), the CSF + padding + dek_blob cannot exceed 0x2000.
The way it is implemented in the Application note, it is guaranteed to exceed 0x2000! (and this is why I had problems decrypting my SPL image until i changed the padding to be less than 0x2000)

2. Is it necessary to sign the entire image again after the encryption step (as in the application note)? what does this achieve?
I can see that part of the Image (IVT+DCD+Boot data) is signed and the binary itself is encrypted in the first step. However the application note signs the entire image again with a seperate CSF. Why?

Thank you.

Regards,

Noor.

[noorahmadshinwa]

Hi @Yuri .

I appreciate your response. Just to clarify my question a little more please see the notes below

1. In figure 5, the CSF without the DEK blob is of size 0x2000. In the community thread, it clearly (and correctly) says: "** (CSF bin data + padding + dek_blob.bin) has to have size 0x2000 ". This includes DEK blob. I think there might be a mistake in AN12056.

2. I understand the process. my question is: is there any security benefit of signing the entire image again in a second step? during the first encryption step, parts of the image are already signed, and the main binary is encrypted.

Thank you for your time!

[Yuri]

@noorahmadshinwa 
Hello,

  AN12056 is correct - "Size 0x2000 includes the CSF and Padding, DEK blob is located after the padding. It is also working(aligned with AN's setting). The important thing we need to notice is to keep the blob address in memory match the blob address defined in CSF. "

Regards,
Yuri.

[Yuri]

@noorahmadshinwa 
Hello,

1.
   I will check size 0x2000 issue with app team.

2.
   The digital signature mechanism allows to verify boot image, which can contain third
party signed firmware.

Regards,
Yuri.

[Yuri]

@noorahmadshinwa 

Hello,

1.
Figure 5 (Memory layout of the encrypted U-Boot) in AN12056 shows
the csf binary size of 0x2000 in accordance with the Community thread

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Encrypted-boot-loader-on-SabreSD-i-MX6q-...

2.
The boot data is encrypted and a digital signature of the whole boot data
image including the boot data structure or vice versa) is generated. Note,
that the boot data structures do not contain any confidential data and are
used by the ROM before the CSF is processed. Therefore, these data structures
remain in plain text and are included in the digital signature.
This allows the boot ROM to access the necessary pointers to initialize the data
structures and modules required by HAB.

Regards,
Yuri.