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 · Accepted solution]

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]

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.

[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]

So this means that if someone dumps the SRAM1 while a firmware update is being decrypted by the secure boot, the key will be somewhere in that dump ? Or it is more complicated than that ?

[Fred]

If you enable the Firewall on the SRAM1, then the Firewall will prevent this dump.

But, as long as RDP-Level2 is not enabled, SRAM1 is accessible and this offers an attack surface.

As you know, the Firewall is a dynamic protection that must be activated at startup so an attacker might connect before this gets activated.

If you look at the X-CUBE-SBSFU user manual:

Caution - RDP level 1 is not proposed for the following reasons:

1. Secure boot / Root of Trust (single entry point and immutable code) cannot be ensured, because Option bytes (WRP) can be modified in RDP L1.

2. Device internal Flash can be fully reprogrammed (after Flash mass erasure via RDP L0 regression) with a new firmware without any security.

3. Secrets in RAM protected by the firewall can be accessed by attaching the debugger via the JTAG hardware interface on a system reset.

In case JTAG hardware interface access is not possible at customer product, and in case the customer uses a trusted and reliable user application code, then the above highlighted risks are not valid

[BEnge.1]

Oh indeed it makes sense now, if a system reset is performed right after the secrets are loaded in RAM and the attacker connects a debugger just after the reset, the firewall is not yet active so the secrets are readable. Thanks for the explanation!