Questions about PCROP, Firewall and RDP protections

[BEnge.1]

Hi,

I am using the the SecureBoot on a STM32L4 with the KMS, I have some questions related to the protections:

1. As I use the KMS, I read in the UM2262: "With KMS middleware integration, SBSFU keys are no more stored in a section under PCROP protection but inside the KMS code running in the secure enclave". So what is the effect of activating the SFU_PCROP_PROTECT_ENABLE in app_sfu.h ?
2. If I don't activate SFU_FWALL_PROTECT_ENABLE, can a malicious user application read the keys from the KMS code running in the secure enclave? If yes, does activating the firewall protection make the secrets from the KMS code running in the secure enclave un-readable by the User App ?
3. I read in UM2262 that using RDP L1 is not recommended because WRP can be reprogrammed. So if I understood correctly, a malicious attacker with physical access to the hardware could disable WRP and use a malicious User App to overwrite the keys in the flash. However how could that malicious app be installed as it won't be signed with the correct key (I make the assumption that the attacker does not have the key used to signed the User App)?

Thanks in advance,

Benjamin

[Fred]

Question 1: are you sure you took the proper project ?

STM32CubeExpansion_SBSFU_V2.6.0\Projects\B-L475E-IOT01A\Applications\2_Images_KMS\2_Images_SBSFU\SBSFU\App\app_sfu.h does not contain the PCROP compiler switch.

I agree that one typo remains at line 81:

/*#define SFU_TEST_PROTECTION*/    /*!< Auto-test of protections : WRP, PCROP, MPU, FWALL.

                      Automatically executed @startup */

==> no PCROP

Question 2: if you do not activate the Firewall, then you have no isolation of your Secure Engine component. This means that the application code can access any piece of code oft he secure engine for reading it or executing it.

By activating the Firewall you enable an isolation. this means your user application can only ask Secure Engine to run some services through the call gate mechanism.

You can see the possibilities in this UM: STM32L47xxx, STM32L48xxx, STM32L49xxx and STM32L4Axxx advanced Arm®-based 32-bit MCUs - Reference manual

Please check table 18 in section 4.3.4.

Question 3: RDP Level 1 means that your Option Bytes are not frozen and this also means your SRAM1 can still be read from a debugger for instance. This opens the door to some attacks.

For instance, if you cannot trust WRP then the attacker might alter the SBSFU code in FLASH so that the signature check is bypassed.

[BEnge.1]

@Fred​ Is there any possible way to forbid SRAM1 read access while using RDP Level 1?

[Fred]

Unfortunately not.

RDP Level 1 will protect SRAM2 and the Firewall applies to SRAM1.

[BEnge.1]

Thanks for the reply @Fred​.

I have got another question: If I understand correctly when applying RDP level 2, it means that the Secure Boot keys are frozen forever. Does this mean that if those keys are leaked, it is impossible to change them and all the devices using them become vulnerable without the possibility to update the keys?

[Fred]

In RDP Level 2, you should consider your device as "locked".

You cannot change the option bytes and you cannot change the FLASH content that is not managed by SBSFU.

So, yes, whatever is part of your SBSFU code is frozen (but this was already the case regardless of RDP level, because of WRP).

If you need a possibility to update the SBSFU keys, then you need to make them dynamic keys in KMS (or your own updatable area), but this is not what we provide as example.

Of course, you will need to assess the security level you need when designing such changes.