Hi Alice,
thanks for your reply and the provided resources.
I understood that there are different PRINCE regions for LPC55 family devices from the documentation, however it's not yet clear to me how PRINCE and secure boot work together. I've seen the corresponding drop-down menu in the Secure Provisioning Tool (see below), but can't come up with a mental model on my own. Which data is used during image validation during secure boot, just the regions that are initially programmed or the entire on-chip memory?
And maybe more specific to my current problem:
- Once secure boot is enabled, would any modification to the underlying memory invalidate secure boot signatures automatically due to hashes no longer matching?
- Could this be circumvented by having spacial separation within the memory? For instance, having static content in one PRINCE region (e.g. 0 below) and dynamic data in another (e.g. 1 below)?
For additional context/motivation, we would like to store a device-specific serial number onto every device within the dynamic data region which is not yet known during firmware/image creation. We want to still have the benefits of secure boot but don't want to loose the possibility to store some bytes of data. Or are these use cases not compatible and would we have to rely on some external memory IC here?
Thanks,
Johannes
Hi @Alice_Yang,
thanks for your reply, this information is already really helpful!
Appreciate your assistance on providing suggestions based on our use-case/requirements. I've tried to roughly visualize and describe what we're trying to achieve in the following overview and a memory layout (we can of course adjust if that makes things easier technically):
Item 1 contains our business logic that gets built from the source code into a regular binary file. After compliation and linking, we take the resulting hexfile and append some static data (Item 2: characteristic maps, lookup tables, etc. that we need for our application) in a post-build step which results in a combined .hex-file of code and static information. This is the artifact that we want to have a secure boot image over, that gets signed and verified during device startup.
In Item/Region 3 we want to be able to store a bit of dynamic data that is device specific and cannot be part of the device-generic artifact above. Our production workflow would program the artifact above onto every unit and subsequently execute the application. Once running, we use a serial protocol to provide unit specific information like a serial number, lot number, etc. that is retrieved during production over UART and persist them in non-volatile memory. This information is not modified afterwards. In the end, units are then packaged and shipped.
Once deployed in the field, we would also like to persist some usage time information into the same dynamic region during runtime (just some usage time tracking etc. in a ring buffer, nothing special). We take different memory sections to not interfere with the information provided during production.
1. Do you have any specific recommendations we should take into account for this?
2. Would something like this make sense for the PRINCE configuration?
3. I've looked at the SDK example for PRINCE en-/decryption you referred to - in which circumstances do we need to include functions like 'PRINCE_FlashProgramWithChecker'? Could we also leave region 2 in the configuration disabled if we don't need encryption and avoid this additional complexity?
Thanks a lot in advance,
Johannes
Hello @johannes_ferch
Yes, PRINCE can be configured to encrypt different memory regions.
A PRINCE demo is available in the SDK—please refer to it for implementation details.
Detail please refer to: UM -> "44.17 PRINCE real-time encryption or decryption details".
For secure boot using the SEC tool, you can refer to the thread below.
Thank you.
BR
Alice
