S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application Hello NXP Support, We are using an S32K311 with HSE_B. Our primary bootloader uses Advanced Secure Boot (ASB) with an AES-CMAC-authenticated Secure Memory Region and a Core Reset entry. UID-diversified ADKPm has already been programmed, and Secure Recovery is enabled. We need to regenerate the authentication data for a replacement Secure Recovery Application after a firmware update, without changing the existing ADKP or retaining its derived signing key in host-accessible memory. The recovery application begins with the Cortex-M7 vector table. Its layout is: Region Address Recovery IVT 0x00480000 Recovery application vector table and code Starts at 0x00482000 Recovery IV, 12 bytes 0x0049FFE4–0x0049FFEF Recovery GMAC, 16 bytes 0x0049FFF0–0x0049FFFF Signing the IVT separately succeeds. However, submitting the raw recovery application's vector-table address to HSE_SRV_ID_BOOT_DATA_IMAGE_SIGN returns HSE_SRV_RSP_INVALID_PARAM. The request uses inTagLength = 28 and an output buffer in system SRAM. On S32K311 HSE_B, with UID-diversified ADKPm already programmed and Secure Recovery enabled, how can the host generate the 12-byte IV and 16-byte GMAC for a raw Secure Recovery Application? HSE_SRV_ID_BOOT_DATA_IMAGE_SIGN returns HSE_SRV_RSP_INVALID_PARAM when pInImage points to the Cortex-M7 vector table. Is there an HSE service that generates the Secure Recovery GMAC using the internally derived ADKP without exposing that key? If not, must the GMAC be generated externally? Additionally, does the IVT Secure Recovery length include the 12-byte IV, and what exact bytes are authenticated? Thank you. Re: S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application Hi @sameer_chawla
Some time ago, the secure recovery process was incorrectly described in the manual (in some old revision, probably 2.3, it is already updated). From that time, I have these additional notes, which summarize how it should be implemented:
Don’t add AppBL header format to Secure Recovery Image
The "First executable byte" of the Secure Recovery Image means its Vector Table start address. Boot header / IVT is not needed in the image.
Don't use HSE_SRV_ID_BOOT_DATA_IMAGE_SIGN service for Secure Recovery Image GMAC generation
The IV should be specified by customer and the GMAC should be generated by customer also (by some general tool like OpenSSL or in separate application project by HSE)
Before customer calculating the GMAC, the 12-byte IV should be added into the image end, and its length(12-byte) also should be added in the image size
Don’t use AES-128 (ADKP) for GMAC calculation. Instead of that, use AES-256 (ADKP-Hash256) to calculate the GMAC as shown in Figure 11 in HSE Firmware reference manual rev. 2.8.
The manual now explicitly says in “2.6.1.3.1 Secure Recovery Mode”:
Regards,
Lukas Re: S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application Hi @lukaszadrapa, Thank you for the quick reply. We have since tested an alternative using Advanced Secure Boot, as we wanted to avoid retaining or separately provisioning ADKP-Hash256 for recovery-image GMAC generation. Our configuration is: CB (our primary bootloader) is authenticated through SMR0. SRB (our recovery bootloader) is authenticated through SMR1 using AES-CMAC and an HSE-resident key, following the same authentication approach as CB. The Core Reset entry selects CB as the primary destination and SRB as the alternate destination. If CB authentication fails, HSE authenticates SRB before starting it. Our understanding is that this uses ASB’s authenticated alternate boot path rather than the dedicated ADKP-based Secure Recovery mechanism. ADKP remains provisioned for its existing IVT authentication and secure-debug purposes. Is this a supported and recommended approach on S32K311 HSE_B? Is using a separate SMR and CR alternate boot destination a usual design for an authenticated recovery bootloader, or are there limitations compared with the dedicated Secure Recovery mechanism that we should consider? Thank you, Sameer Re: S32K311 HSE_B ASB: Generating ADKP-derived GMAC for a raw Secure Recovery Application Hi @sameer_chawla
Yes, this is also a valid approach. You can use the alternate boot destination instead of the dedicated Secure Recovery mechanism.
The choice mainly depends on the level of fallback protection required. If one fallback level is sufficient, using a separate SMR for SRB and configuring it as the alternate boot destination is an appropriate solution. If an additional fallback level is required, for example if authentication of the alternate boot image also fails, the Secure Recovery mechanism can still be used as another recovery level.
So, it ultimately depends on the application requirements. There is no inherent limitation in using the alternate boot path for this purpose. In fact, it provides more configuration flexibility than the relatively simple dedicated Secure Recovery image mechanism.
Regards,
Lukas
記事全体を表示
