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 ??

[Fred]

In fact, there are different needs.

Secure User memory is here to prevent the user application from accessing the SBSFU code and assets. It can be seen as a "temporal isolation" : when the bootloader has finished its job then its area "disappears".

Now, when SBSFU runs, we also have a "regional isolation" between the secure part of the SBSFU (Secure Engine: dealing with the assets) and the non-secure part (for instance the loader using the UART must not access the assets as the UART might be used as an attack point).

Now, why PCROP ?

In fact the idea is to have some "mutual distrust", even in the secure enclave.

We trust the code in Secure Engine but, if unfortunately there is a flaw in this code allowing to dump the FLASH then the PCROP protects us.

It is really the idea of building a fortified solution with layered security.

SBSFU:

• Isolation is in charge of protecting the assets from the non-secure code
• PCROP adds an extra protection in case the secure code tries to dump the keys from FLASH

User Application:

• Temporal isolation where the SBSFU code and assets are "hidden"

But, PCROP must be used with code only (no D fetch allowed).

So, the PCROP-ed code loads the key in RAM.

Hence, there is a window of time where the key is in RAM.

But, only Secure Engine can use it.

As always, there might always be vulnerabilities but the intention is to make it very complex to exploit it.

[SPati.7]

@Jocelyn RICARD​  Your perspective on this Please ??

[Fred]

Looks like my reply has not been posted...sorry for this...

Basically STSAFE-A110 will bring you:

• a secure element to protect your assets
• a provisioning of your assets
• offloading the critical operations like signing with the private key

It has the constraint of having the I2C secure channel so a pair of MAC/Cipher keys.

You will need to diversify it per device.

Now, I need to check with an STSAFE-A110 expert but I think you can configure STSAFE-A110 so that your private key never goes out of the secure element, even if somebody steals the MAC/Cipher keys.

This is what you would gain.

But, if you do not protect the MAC/Cipher keys then somebody might spoof the STM32 and ask the STSAFE-A110 to do some operations.

Probably here you may put under PCROP the code dealing with STSAFE-A110 and storing the MAC/Cipher keys.

This way the keys would not be dumped from FLASH.

I will ask an STSAFE-A110 expert his view.

Let's say that we still have assets to protect on STM32 side: the MAC and Cipher keys.

But, your most important asset, the private key, would not be exposed to leakage.

[Fred]

It is really a matter of security level you want to achieve.

MPU-based isolation has some limits (applies only to the Cortex-M master + requires to deprivilege your application).

PCROP and WRP protect FLASH only.

So, STSAFE-A110 can bring many benefits:

• strong isolation from STM32 code
• secure element security level

Now, if the level of protection provided by MPU and PCROP/WRP is sufficient for you, for sure it can work. You just need to assess the limits of these mechanisms versus your security requirements.

[Fred]

Looks like I am facing issues to post...testing...

[SPati.7]

@Fred​  I am getting your posts, as you asked Jocelyn for confirmation, i have just added him to the discussion.

Thanks for your valuable replies.

[Fred]

Hello,

I discussed with the STSAFE-A110 experts.

So, this is what the STSFE-A110 can bring as additional benefits compared to an STM32H7-only solution:

• the provisioning of your private key is handled at factory stage, you receive the STSAFE-A110 with the assets already included in it
• 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

So, this means that we could protect the pairing key on the STM32H7 side to avoid STM32 spoofing that would allow an attacker to send commands to the STSAFE-A110.

But, if our security mechanisms are circumvented by the attacker, still he cannot extract your private key from the STSAFE-A110.

More information about STSAFE-A110 personalization can be found here:

STSAFE-A110 generic sample profile description - Application note

Again, I do not mean that STSAFE-A110 is mandatory, STM32H7 already brings a level of security, but with STSAFE-A110 you can go one step further if it is critical for you to protect the private key.

[Fred]

Another option could also be to:

1. store the pairing keys in Secure User Memory
2. At the end of the SBSFU process: load the pairing keys in RAM, configure the MPU
3. During the application lifecycle, only the privileged code can use the pairing keys

As you can see, many options are possible.

It also depends heavily on the attacks you want to thwart.

[SPati.7]

@Fred​ To provision STSAFE-A110, We won't share our private keys with ST. We want to provision STSAFE in our secure environment, is this allowed ??

STSAFE-A110, is the device used to store certificates, which is used to establish TLS communication, which means for example, wolfSSL will read these key details to initiate TLS handshake. Without keys, it is difficult.

Then what is the real use case of STSAFE ??

@Jocelyn RICARD​  can you help with the storage of Pairing Keys mechanism ??

[Fred]

I will forward your questions to our STSAFE-A110 experts but here are my 2 cents:

1. Provisioning => I assume there are several possibilities. Here I think the easier solution would be to get in touch with your ST local support team or sales.
2. STSAFE-A110 stores keys (key table) and data like certificates (data partition). Now wolfSSL does not necessarily need to know all these details. I do not know this lib but probably you can define hooks so that your code gets called ? For instance to do this kind of thing with mbedTLS I used the MBEDTLS_ECDSA_VERIFY_ALT possibility.
3. STSAFE is really a "smart safe". For IoT, a typical use-case is to prevent the cloning of your device. The attacker can buy the same STM32, he can maybe get your firmware but he will not be able to clone the STSAFE so all the assets are missing for him to spoof you.

If you want an example of STSAFE-A110 usage in an IoT use-case, you can have a look at this presentation:

https://www.youtube.com/watch?v=uMheyCl3vas&list=PLnMKNibPkDnF0oofZPLdyEnUg2BpfBS8p&index=1