LS102xA: is Secure Boot with key extension supported?

[jean-francoisri]

I have been testing various Secure Boot scenarios on my LS102xA board with QSPI flash. I started by generating 4 SRK and burning their hash in the SRK Hash registers. Then I tried:

• Signing all boot components using the 1st SRK => it works
• Signing U-Boot and its bootscript with the 1st SRK, signing secondary boot components using a different key whose hash is specified in the corresponding esbc_validate command => it works
• Signing U-Boot and 5 IE keys with the 1st SRK, then signing the bootscript and secondary boot components with one of the extension keys => it fails!

I have little details on the failure: after programming my flash with the secure boot components, it just freezes. Using a Lauterbach debugger, I can see that DCFG_CCSR_SCRATCHRW1 contains indeed the address of my U-Boot CSF header, but DCFG_CCSR_SCRATCHRW2 is equal to 0, which would indicate there was not secure boot failure reported by the Secure Boot ROM. So perhaps the failure is in U-Boot.

In the LS1021A SDK v0.4 documentation (section 31.8.2.4.2), it is written that:

Key Extension feature is applicable only for NOR secure Boot. It is not applicable for RAMBOOT (where data has to be copied onto RAM, eg:- NAND, SD, SPI)

I'm using QSPI NOR flash, which I assumed should support key extension. So my questions are:

1. Is the LS102xA family supposed to support key extension?
2. If so, do all members of that family support key extension, in particular the SEC-less LS1022A?

Thank you for your help.

[bpe]

>Is the LS102xA family supposed to support key extension?
>
[Platon] Yes, all crypto-enabled LS102xA, LS104xA and LS1012A implement
NXP Trust Architecture 2.1 which does support IE Key Extension.

>If so, do all members of that family support key extension, in particular the SEC-less LS1022A?
>
[Platon] TA 2.1 ISBC relies on the presence of SEC. Thus parts without
it cannot perform Secure Boot in general.

Note, we have a very limited range of Secure Boot and TA-related materials
that can be shared without NDA. If you need more help with your boot
scenario, please be sure to open a Support Case:

https://nxpcommunity.force.com/community/CommunityContextPage

Have a great day,
Platon

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jean-francoisri]

Thank you Platon for the confirmation! It turns out that my flash chip was misbehaving and was clearing arbitrary bits in the first sector I was updating. After switching to a functioning chip, I was able to secure-boot from my LS1022A board configured with key extension.

One thing I'm puzzled about is that, according to the LS1021A Reference Manual, the LS1022A is not supposed to have a SEC, as shown in the B-1 table:

Features	LS1021A	LS1022A
DDR memory controller	DDR3L/DDR4 with ECC and interleaving support	DDR3L 8/16-bit with ECC
SerDes lanes	4-Lane 6 GHz SerDes	1-Lane 5 GHz SerDes
SATA controller	Yes	No
USB controller	2 (1-USB2.0 (ULPI) and 1-USB 3.0w/ PHY)	1 (USB 2.0 (ULPI))
2D-ACE	Yes	No
QUICC Engine	Yes	No
Ethernet complex	3x GbE - SGMII, MII, IEEE 1588, RGMII, RMII	2x GbE - MII, IEEE 1588, RGMII, RMII
PCI Express 2.0 controller	2	1 (x1 only)
SEC	Yes	No

However, I'm clearly able to secure-boot from my LS1022A board. Is it because:

• there is a SEC but it's not available for use outside of Secure Boot?
• cryptographic operations are performed in software emulation by the internal Boot ROM?