Bricked LPC55S28 by writing partial key data to FFR?

[m_eiman]

Hi,

I've just stared working on a feature that uses the PUF, and I wanted to store the AC in FFR to make sure I don't accidentally erase it when I erase my application settings which I keep in a designated part of the normal flash.

Since I don't (yet) use secure boot or PRINCE, I didn't create any keycodes for the key slots of  the key code storage - I just put the AC and the magic value that indicates a valid AC into a 3*512 buffer and called ffr_keystore_write() on it.

Now my CPU doesn't boot up properly, which I assume is due to some sanity check in the boot ROM freaking out about the unexpected contents of the keystore flash.

Now, on to my questions:

* Is the non-booting due to the missing keys?

* Would it have worked properly if I had filled in the PRINCE0-2 keycode slots before writing the flash, or is there something else needed in addition to that?

* Is there any way to erase the relevant part of the flash to get my CPU up and running again?

The USB bootloader doesn't work, so I guess it stops early in the boot process. I haven't made any changes to the CMPA page (secure boot, PRINCE settings, etc), they should all be at their default values.

This is the code I used to write the AC to flash:

        uint8_t keystore[512*3];
        memset(keystore, 0, sizeof(keystore));
        *((uint32_t*)&keystore[0]) = 0x95959595; // marker indicating AC is valid
        *((uint32_t*)&keystore[4]) = 0; // PUF discharge time in ms, 0 is default
        memmove(&keystore[8], ac, sizeof(ac));
        // TODO what about the other keys, do we want to set them too?

        result = FFR_KeystoreWrite(&flash_config, (void*)keystore);

[Alice_Yang]

Hello,

Recommend you first run the demo in AN12324 first, then you will know the Puf and some command clearly.

BR

Alice

[Sang]

Can project AN12324 run on LPC55s28

[m_eiman]

I'm looking at the documentation for the ISP commands for key provisioning in section 8.6.14 of UM11126 (which I assume is what blhost.exe uses), to see how I could use that to set things up as I want them. But it seems that some details are missing or contraditory:

• Where is the AC generated by the Enroll operation stored? I'm guessing it's in RAM somewhere.
• What value should be given to the Memory ID parameter for the WriteNonVolatile and ReadNonVolatile operations? The AN12324 commands suggest value 0.
• The SetUserKey and SetIntrinsicKey operations are said to write to ROM, but the commands performed using blhost.exe in the example in section 3.3 of AN12324 suggest they data is stored in RAM and not written to the PFR until the WriteNonVolatile operation is performed?
• In UM11126 table 238 key type 12 is defined as "Reserved", but in AN12324 it is defined as "UDS"

Is it correct that the blhost.exe commands in section 3.3 of AN12324 will perform the following key provisioning operations using the ISP API:

1. Enroll
2. SetIntrinsicKey keyType 12, keySize 32
3. SetUserKey keyType 3, keySize [size of .\temp\tempSbkek.bin], data phase of keySize bytes
4. SetUserKey keyType 11, keySize [size of .\temp\UserKek.bin], data phase of keySize bytes
5. SetIntrinsicKey keyType 7, keySize 16
6. SetIntrinsicKey keyType 8, keySize 16
7. SetIntrinsicKey keyType 9, keySize 16
8. WriteNonVolatile

Are all of these operations required to have a complete and working set of parameters in the PFR, i.e. must all of the keys 3, 7, 8, 9, 11 and 12 be defined before writing to the flash?

Is the order of the operations for settings the keys important?

If making a mistake with this didn't brick my device I would be able to figure it out by trial and error, but since it does and I don't have that many devices with experiment with, I will unfortunately need to ask a lot of detailed questions

kind regards,

   Mikael

[Alice_Yang]

Hello  Mikael,

Could you please tell me what function do you want to development with PUF? 

 PUF can generate, store, and reconstruct key, usually the KEY used with PRINCE , AES modules, so want to know how do you want to use PUF, I will refer to your application give a description about above question. 

BR

Alice

[m_eiman]

Hi Alice,

What's we want to do is this:

• Pair the MCU with a SAM using a randomly generated key, and store the key for this as securely as possible in the MCU
• Probably use PRINCE to have transparently encrypted flash

Since the SAM key is essential to be able to use the SAM, we want to store it in a secure way such that it's very hard to extract it from the device and also very hard to erase by mistake or bug. For the latter reason we don't want to store it with the other application settings in "normal" flash, since a bug that somehow corrupts the key would essentially brick the device.

The PUF seems like a perfect way to solve these requirements, as long as we can store the AC and key(s) in the PFR.

In addition to this, we would also like to avoid requiring the use of blhost.exe during production of the devices, since we'd rather not use a Windows machine for this. Also some customers are very particular about the generation and storage of important keys, and would prefer to have access to all source code related to handling and generating keys. I believe that the source for blhost.exe isn't available?

kind regards,

   Mikael

[Alice_Yang]

Hello m_eiman,

Thanks for your sharing,  first of all, recommend you run the code under AN12324.

https://www.nxp.com/docs/en/application-note-software/AN12324SW.zip  

Even though the AN describe using PUF with blhost, while the project is using API, you can check the code. You can run the code, BUT, be careful, save the KC into RAM. After you run the project, it will prinft some information to terminal, you can see the options. I also can send you a simple steps by private message. After you run the project, I think you will know how to use PUF.

BR

Alice

[m_eiman]

Hi @Alice_Yang,

That example doesn't store the AC to PFR from application code though, correct?

This is what I would like to accomplish: to not need to rely on blhost.exe to store the AC.

kind regards,

   Mikael

[m_eiman]

I've read the reply in this post:

https://community.nxp.com/t5/LPC-Microcontrollers/LPC55S69-PUF-Start-activation-code-aperture/m-p/11...

It says that it should be possible to use the FFR_KeystoreWrite() function to store the AC, but without details of the contents of the buffer.

Section 7.2.6.2 of UM11126 contains a table with some details of the contents, but says nothing about what's required to be present. And the reserved bytes, should they be written as 0x00?

AN12324 has this to say:

"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 interpreted the text to mean that if the AC or any of the used keys (depending on other flags could be SBKEK, PRINCE1-3) are invalid it'll stop booting. But perhaps some (or all?) of the keys need to be present regardless of if they're actually used or not. If they are required, does this mean all of them or just certain keys?

In the ISP example in section 3.3 of AN12324 only the UserKEK and PRINCE keys are stored or generated, but perhaps the SBKEK and UDS are added automatically by e.g. the write_key_nonvolatile command?