STM32H5 simple security settings

[JimJW]

Hi,
I have a question about choosing some fairly basic security settings for an STM32H5.

We are developing a system that uses both G4 and H5 micros. We have developed a largely common bootloader that receives a signed encrypted application over variously USB, UART, or CAN, and flashes it to internal memory. This is working on the G4 and H5.

For the G4, we understand that if we select "Level 1" read protection, the bootloader will still be able to erase and re-flash a new application but a user will not be able to gain access to the code (bootloader, application, or data in CC RAM). Further, the G4 can be reverted to Level 0 if required, but this will erase the proprietary code.

Ideally, we would like the same security behaviour on the H5. I have been reading about the bewildering selection of security settings with privileged and secure settings for individual peripherals but I feel this is more complicated than we require. Our bootloader already prevents someone installing malicious code so I believe we just need a means of locking out the JTAG port to prevent someone reading the bootloader or decrypted application from flash. Ideally we would like this security setting to be reversible but with a full chip erase, as on the G4.

I would be grateful for any advice on suitable security setting.

Thanks

[TDK]

Here is what you're looking for:

How to enable RDP-like product state flash protect... - STMicroelectronics Community

 

You'll notice it's quite long and involved, unlike on the G4 where it would be a few sentences. If you don't want the complexity or need the additional security options, the H5 may not be the right choice.

[JimJW]

Hi,
I posted a couple of follow up questions below - I don't know if you would normally see that because I had already checked "Accepted Solution" on the first answer.

Thanks

[TDK]

Unfortunately, I'm not an expert in this area. Since your original question was answered, it may be better to post the more specific questions in a new thread, if they're not already answered in the linked thread.

[JimJW]

Thanks for that link @TDK  - it seems to do what we want. I have a couple of follow-up questions:

1) Since the regression to open performs a full chips erase, am I right in thinking that we can use a common and not secure password? i.e. Revealing the password does not allow access to the firmware.

2) Can I perform all of the steps listed, from my bootloader firmware? As far as I can see, the changes to product state just require a write to write to an option byte. I have yet to find the part of the reference manual that describes how to write the password file but looking through the scripts in the git repo mentioned seems to suggest that something is written to "address_password=0x8FFF000". (Just noticed - that address looks like H503 only, and for the H563 it looks like 0x0FFD 0100)