LPC55S16-EVK bricked after using FFR_KeystoreWrite(...)

[Tantanplan]

Hello,

we're having an LPC55S16-EVK board which (presumably) won't enter the ISP mode anymore. That happened after having the MCU execute the FFR_KeystoreWrite function.

Now, the LinkServer won't find any available SWD devices (even when forcing ISP mode with JS3 shorted), therefore reprogramming/mass erase is not feasible. We also tried using SPSDK/blhost with USB connection via J4 and UART via JP3, but no device can be detected.

I'm wondering if there are further options we could try in order to access the LPC55S16, or is the device ultimately bricked?

In addition: I don't understand how the FFR_KeystoreWrite() function could cause such problems. AFAICS it should not alter the CMPA/CFPA pages, right? We also never touched those pages, so they should still be in factory state.

Thanks!

[Julián_AragónM]

Hi @Tantanplan,

1. I'm wondering if there are further options we could try in order to access the LPC55S16, or is the device ultimately bricked?

Yes, there are some options, please help me take a look into this article: Recovering bricked LPC55Sxx EVK Boards | MCU on Eclipse.

2. I don't understand how the FFR_KeystoreWrite() function could cause such problems. AFAICS it should not alter the CMPA/CFPA pages, right?

Please help me take a look into this thread similar to your inquiry: Bricked LPC55S28 by writing partial key data to FF... - NXP Community, and also looking into the Application Note; LPC55Sxx usage of the PUF and Hash Crypt to AES coding (AN12324), in Chapter 3 (Key Management), the process to store a key code into the flash memory is explained, and this note is added:

"The secure boot uses the secure-boot KEK code. The flash encryption by PRINCE uses the PRINCE1 to PRINCE3 key codes for its protected regions. When correct key codes are found, they are applied to PRINCE by the boot process. The boot process checks the key code storage for existing code validity. If the AC (or KC) is corrupt, booting stops and blocks the MCU forever."

I hope you find this helpful!

Best regards, Julian

[Tantanplan]

Hi, @Julián_AragónM,

thanks a lot for your referrals.

"The secure boot uses the secure-boot KEK code. The flash encryption by PRINCE uses the PRINCE1 to PRINCE3 key codes for its protected regions. When correct key codes are found, they are applied to PRINCE by the boot process. The boot process checks the key code storage for existing code validity."

Does calling FFR_KeystoreWrite implicitly enable secure boot? We never enabled/used secure boot up to this point. So the presumption was that the MCU will just ignore the contents of the three key store pages.

I'd really appreciate a clarification on that since the related threat you mentioned (which indeed covers the same problem) does not answer if the function has any side effects (other than writing the key store pages).

Thanks!

[Julián_AragónM]

Hi @Tantanplan,

Are you utilizing any SDK examples for your applications? It might be enabled by default in a template or example you used. Please help me check this.

Best regards, Julian

[Tantanplan]

Hi @Julián_AragónM,

yes, we used some examples:

• The demo puf_hashcrypt_crypto
• The driver examples mcan_interrupt_transfer and usart_interrupt_transfer

When creating the projects within MCUXpresso, the TrustZone option was disabled (i.e. TrustZone Project Type set to None).

We also never created any images with digital signatures (unless this happened implicitly and 100% hidden from the programmer).

Thanks!