HABv4 encryption with 4096-bit keys

[gary_bisson]

Hi,

I've written an article on how to use HABv4 on i.MX6/i.MX7  to sign and encrypt your bootloader.

https://boundarydevices.com/high-assurance-boot-hab-dummies/ 

During my testing, I've used 4096-bit keys and everything was working fine in open mode, no HAB events. However when I closed the device it wasn't booting!

I reported the issue here already with no answer:

https://community.nxp.com/docs/DOC-330622#comment-37543 

In order to boot the board with a signed bootloader I've had to add a 'Engine = CAAM' line although it was working fine in open mode with no HAB events reported! I think this should be documented somewhere.

However I couldn't get encryption to work, although, once again, it was working in open mode.

So my question: have 4096-bit keys been tested with encryption on close devices?

Looking at the HABCST_UG.pdf, it seems that a configuration for 4096 keys is provided (section 5.3.5):

• It doesn't have the [UNLOCK] section
  • Does this configuration force to set the RNG Trim in Fuse?
• It is providing the .der files instead of the .pem files, is it normal?

Please advise.

Regards,
Gary

[Yuri]

Hello,

  Please create request.

https://community.nxp.com/docs/DOC-329745 

Have a great day,

Yuri

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

Note: If this post answers your question, please click the Correct

Answer button. Thank you!

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

[gary_bisson]

Hi Yuri,

Isn't this support request for people that want something specific? Here I'm only asking for something that you claim in every documentation and every tutorial is working.

So it is not so much of a support request but instead a confirmation request that this feature has been tested with an explanation on how it has been verified.

Please advise.

Regards,

Gary

[Yuri]

Hello,

  As for 4096-bit key : there is an example, that I cannot locate here.

Regards,

Yuri.

[gary_bisson · Accepted solution]

Hi Yuri,

Thanks, it now works fine. Note this had nothing to do with the key length actually.

The problem was with the [Authenticate Data] section. It was authenticating the whole space before U-Boot entry (IVT + DCD + padding). This works in open device (no event).

But apparently when you close the device, the BootROM only copies the IVT + DCD, not the padding, hence the failure.

Regards,

Gary

[satyadamarla]

Hello Gary,

That means the (zero) padding after DCD isn't copied. This means that the authentication has to be very specific. I have few questions for you before I try them myself 

1. How does the Boot ROM know the size of the DCD? My DCD header is "D2 00 08 40". Is "0008", 8 bytes the size of DCD. So, should I be very particular in authenticating it exactly to that 8 bytes?
2. What happenes if the DCD address is made null (0x0) in the IVT ? I used multi-stage booting: "SPL + u-boot.img". So, DCD is not actually needed as that part is done by the second stage boot loader. Do you still think in closed mode, I have to sign the DCD to that 8 bytes mentioned above?

Greets,

Satya

[gary_bisson]

Hi Satya,

I *believe* that it means that the BootROM doesn't copy the zero padding, or at least not entirely. But at this point it is an assumption since NXP didn't comment on this.

As for your other questions:

1. Yes my guess is that the boot ROM reads the DCD Header (0xD2 tag), so yes I'd put the exact value. Note we are working on the U-Boot community so the imximage tool displays that value directly:
   [U-Boot] [PATCH] tools: imximage: display DCD block offset, length 
2. Don't know, but I guess it is fine if the pointer is null. How can the BootROM find the DCD Header above if the DCD pointer is null? I think you can just discard the DCD signing in that case, but there's only one way to know for sure ;-)

Regards,

Gary