Can we store Private Keys or x.509 certificates on Flash using PCROP Protections ??

[SPati.7]

@Jocelyn RICARD​  We need secure storage to keep Private Keys and certificates for TLS communication on STM32H753.

To achieve this we found STSAFE-A110, but interfacing and to bring in this peripheral, it is time taking in terms of re-spin PCB design etc.

Instead of this, can we choose PCROP protection mechanism, like converting Data to Instructions with help of scripts and then store them under PCROP protections ??

is this solution looks feasible ??

[SPati.7]

@Fred​  As you suggested, if we want to store keys in PCROP, Can i do it on Bank2 PCROP dedicated for Application ??

But, i understand that, PCROP to work, we need SBSFU presence as well ?? are we able to read PCROP only in SBSFU context ??

My direction will be like this:

• Want to use Bank1 PCROP SBSFU area only for SBSFU implementation, as suggested in Examples.
• For application context, as i need to store Mac & Cipher public keys, may not be sensitive as Private, Can i use WRP or PCROP on Bank2 ?? If PCROP in picture, then is it possible to access PCROP, in application context ??
• Also, as you mentioned in above post like "the private key (stored in the appropriate key slot) can never be extracted from the STSAFE-A110, even if you have the valid pairing keys", on what basis we can say that ?? Why i am asking this is, if there is no harm of Mac & Cipher keys leakage, i can store them in WRP protected itself. Can you please help with these details ??

[Fred · Accepted solution]

PCROP is indeed available on both banks.

One PCROP area is used by SBSFU.

The other PCROP area can be used by your application, regardless of SBSFU.

You can configure the OBs with Cube Programmer to have this second PCROP area, then, when designing your software you will define an execute-only section that will contain what you want to protect from a FLASH dump.

Your application can fully access its own PCROP area without relying on SBSFU.

You will call your code "as usual".

But the constraint is that this code placed in PCROP area must rely on I-fetch only (execute-only code).

As I said, this PCROP protection will provide a FLASH dump protection but anybody can call this code (unless you restrict its access with MPU isolation).

So, an attacker might take control of your application and call this code to communicate with STSAFE-A110.

Here, you can raise the bar by using MPU isolation and make sure the code you do not trust in your application cannot call the PCROP-ed service.

About the private key, what I mean is that you may have a hierarchy of assets in term of criticity.

If this private key is your critical asset, then with STSAFE-A11à your are on the safe side, the key will never go out of the secure element.

Now, the pairing keys must be available on STM32 side so we also need to protect them (PCROP, WRP and MPU for instance).

In the worst case, if an attacker manages to circumvent the protection of the pairing keys then what can he do ?

He can communicate with STSAFE-A110.

Will he be able to extract the private key ? No.

Will he be able to ask STSAFE-A110 to use this private key to sign something: Yes.

So, if your pairing keys can be controlled by the attacker then he can spoof your device because he can use your private key to spoof your identity.

Nevertheless:

• if he tries to steal your device then he cannot reprogram the private key: blocked.
• If he tries to create a clone of your device, as he does not know the private key he is blocked too

So you gain 2 things:

• the attack is much more complex because it is not only dumping a FLASH or RAM area from the STM32
• even if the attack succeeds then he can do things with your actual device but he cannot create a clone

At least this is what I can think about it at the moment.

Of course, this deserves a real security analysis.

[SPati.7]

Thanks @Fred​ for detailed reply. Understood from STSAFE end no issues.

For SBSFU, i want to apply SECURE Mode + Secure Memory (sector 0) + PCROP (Key data) + WRP (sector 0) + RD LEVEL 2 + MPU (SBSFU - RAM), is this looks promising ??

[Fred]

With SBSFU we really follow the concept of layered security.

Therefore, the first thing I usually tell people to do is to make a diagram of their chain of protections.

With the vanilla X-CUBE-SBSFU we provide as example for H7, the chain of protections is like this:

So, this is what you can do to have a clear view of your security layers.

This is the SBSFU part, you need to do the same for your application.

Of course, this is not a security analysis, it is more a first step towards the security analysis.

Once you have this view, then it is time to check how this system protects your assets, then identify the threats, vulnerabilities and countermeasures.

[Fred]

Another input that may be helpful to assess your solution: https://www.st.com/resource/en/technical_note/tn1387-xcubesbsfu-security-evaluation-method-description-stmicroelectronics.pdf