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

[Jocelyn RICARD]

Hello @SPati.7​ ,

you can see that in SBSFU this technique of hiding key in a PCROP instruction is used.

This technique is useful to protect from direct read from flash. So, for instance from a simple memory dump.

To be able to use this data encoded in PCROP, you will call the function created to this purpose that will extract the key in RAM.

So, any code knowing the address to call inside PCROP area can extract the key.

You will find the tool usage in the prebuild.sh of the SECodeBin project in SBSFU.

It uses the tool prepareimage

Best regards

Jocelyn

[SPati.7]

Thanks @Jocelyn RICARD​  and @Fred​  for quick reply.

But this answer lead me to some open questions.

1. Are we protecting complete SBSFU application with help of Secure Memory feature, where once it is executed, it will be disabled until, next RESET ??
2. From the SBSFU examples, i found that Secure user memory starts from 0x08008A00 to 0x08020000, where SBSFU application stores. So this is protected with help of SECURE USER MEMOERY Feature by defining SEC_AREA_START1 & SEC_AREA_END1 ??
3. But from below memory map, not all regions are protected with Secure User Memory feature :

#define ROM_START              0x08000000

#define VECTOR_SIZE             0x400

/* SE Code region protected by MPU isolation */

#define SE_CODE_REGION_ROM_START      (ROM_START + VECTOR_SIZE)

#define SE_CALLGATE_REGION_ROM_START    (SE_CODE_REGION_ROM_START + 0x8) 

#define SE_CALLGATE_REGION_ROM_END     (SE_CODE_REGION_ROM_START + 0x1FF)

/* SE key region protected by MPU isolation */ PCROP Protection

#define SE_KEY_REGION_ROM_START       (SE_CALLGATE_REGION_ROM_END + 0x1)

#define SE_KEY_REGION_ROM_END        (SE_KEY_REGION_ROM_START+ 0x2FF) /* H7: The minimum PCROP area that can be set is 16 Flash words, that is 512 bytes. */

/* SE Startup */

#define SE_STARTUP_REGION_ROM_START     (SE_KEY_REGION_ROM_END + 0x1)

#define SE_CODE_NOKEY_REGION_ROM_START   (SE_STARTUP_REGION_ROM_START + 0x100)

/* Aligned SE End at the end of the 1st 32Kbytes of flash, MPU protection isolation constraints */

#define SE_CODE_REGION_ROM_END       0x08007FFF

/* SE IF ROM: used to locate Secure Engine interface code out of MPU isolation   */

#define SE_IF_REGION_ROM_START       (ROM_START + 0x8000)

#define SE_IF_REGION_ROM_END        (SE_IF_REGION_ROM_START + 0x9FF)

/* Secure memory activation code - initialization area */

#define SB_HDP_REGION_ROM_START       (SE_IF_REGION_ROM_END + 0x1)

#define SB_HDP_REGION_ROM_END        (SB_HDP_REGION_ROM_START + 0xFF)

/* SBSFU Code region */ Secure User Memory Protection 

#define SB_REGION_ROM_START         (SB_HDP_REGION_ROM_END + 0x1)

/* Aligned SBSFU end at the end of the 1st 128Kbytes of FLASH, MPU protection constraints */

#define SB_REGION_ROM_END          0x0801FFFF

From the above, We are applying protections for SE_KEY_REGION and SBSFU Code Region only. No protection is needed for remaining regions which is part of SBSFU ??

Can you please help me here to understand better on protections ??

[Fred]

You can check this code:

SFU_LL_SECU_SetProtectionSecUser

Where you can see:

  aSecureAreas[0].sizeInBytes = SFU_SEC_USER_MEM_SIZE;

  aSecureAreas[0].startAddress = SFU_SEC_USER_MEM_START_FROM_OB;

With:

#define SFU_SEC_USER_MEM_START_FROM_OB ((uint32_t)((FLASH_BASE>>8U)<<8U))

#define SFU_SEC_USER_MEM_SIZE (SFU_SEC_MEM_AREA_ADDR_END - FLASH_BASE + 1U)

And:

#define SFU_SEC_MEM_AREA_ADDR_END SFU_ROM_ADDR_END

#define SFU_ROM_ADDR_END     ((uint32_t) SB_REGION_ROM_END)    /* SBSFU end Address (covering all the SBSFU

                                     executable code) */

Which is:

define exported symbol __ICFEDIT_SB_region_ROM_end__       = 0x0801FFFF;

[Fred]

PCROP is already used to protect the SBSFU keys.

You can see that the scripts prepare the file se_key.s stored in "STM32CubeExpansion_SBSFU_V2.6.0\Projects\NUCLEO-H753ZI\Applications\2_Images\2_Images_SECoreBin\EWARM".

The script is in Secure Engine middleware: translate_key.py

You may update it to store your own assets (extending the protected FLASH too).

But, the question is : do you need to update these assets later on ?

The PCROP is a read and write protection of an IP-code in the Flash memory. The PCROP is applied to protect the proprietary code from a possible modification or read out by the end user code, the debugger tools or the RAM Trojan code.

So, whatever is protected by PCROP cannot be updated.

[SPati.7]

@Fred​  Thanks for Reply.

Do you mean, we can extend PCROP area to add more than one Key ??

If it is, can we access this in Application mode, where wolfSSL TLS communication need key details to establish secure communication ??

Also, only one PCROP per Bank can be defined right ??

[Fred]

PCROP is configured like this:

  /*

   * Warning: on H7 the minimum PCROP size (512 bytes) is bigger than L4 => adjust the memory mapping accordingly

   */

  psFlashOptionBytes->Banks = SFU_PROTECT_PCROP_AREA;              /* Bank1 */

  psFlashOptionBytes->PCROPConfig = OB_PCROP_RDP_ERASE;             /* erase PCROP when doing a

                                           RDP-level regression (1->0) */

  psFlashOptionBytes->PCROPStartAddr = SFU_PROTECT_PCROP_ADDR_START;

  psFlashOptionBytes->PCROPEndAddr = SFU_PROTECT_PCROP_ADDR_END;

You may decide to increase this area to store more assets.

#define SFU_PROTECT_PCROP_ADDR_START  ((uint32_t)SFU_KEYS_ROM_ADDR_START)    /*!< PCROP Start Address (included) */

#define SFU_PROTECT_PCROP_ADDR_END   ((uint32_t)SFU_KEYS_ROM_ADDR_END)     /*!< PCROP End Address*/

You may increase it:

/* SE key region protected by MPU isolation */

define exported symbol __ICFEDIT_SE_Key_region_ROM_start__    = __ICFEDIT_SE_CallGate_Region_ROM_End__ + 1;

define exported symbol __ICFEDIT_SE_Key_region_ROM_end__     = __ICFEDIT_SE_Key_region_ROM_start__ + 0x2FF; /* H7: The minimum PCROP area that can be set is 16 Flash words, that is 512 bytes. */

/* SE Startup                */

define exported symbol __ICFEDIT_SE_Startup_region_ROM_start__  = __ICFEDIT_SE_Key_region_ROM_end__ + 1;

At the cost of a bigger SBSFU area.

But, be aware of 2 limitations:

1. this area is used with se_key.s

se_key.s ==> section .SE_Key_Data:CODE

CoreBin linker file ==> place in SE_Key_ROM_region {readonly section .SE_Key_Data };

So you have to update it if you want to take into account your own files or you have to place your code in se_key.s

The idea is to provide functions loading the key in protected SRAM.

2. This area is protected by the Secure User memory so it is not accessible from your application.

Hence, I guess the best option if you want to leverage the PCROP protection is to define another PCROP section in the other bank, accessible by your application.

But, PCROP will only prevent a malicious code from dumping your key from the FLASH.

To use your keys, you will need to place it in RAM (even for a short period of time).

So the question is: do you need to protect this RAM ?

You can add an MPU protection but it is not so easy.

 For the certificates, I think this is public assets where only the integrity matters.

Can't you just protect them with WRP to make sure they are not modified ?

For the private keys, you need:

• integrity
• authenticity
• confidentiality

This is more complex to achieve and requires isolation.

Here the MPU can come into picture but it is not perfect (DMA and other masters can bypass the MPU settings).

This is where STSAFE-A can help.

You may:

• store your private keys in STSAFE-A
• delegate the signing to STSAFE-A at TLS handshake stage
• keep the TLS session key in the STM32 to avoid going through STSAFE-A for each and every message

Another benefit you can get is that the provisioning of your private key in the STSAFE-A could be handled at factory stage.

So, I think you need to decide which security level you need.

If you can accept that the private key is exposed when it is present in RAM, then PCROP may be an option.

But a malicious code could invoke the PCROPed code to place the key in RAM, then extract it. You would be protected mainly against direct dump from the FLASH by the malicious code.

Another option may be to put in the PCROP:

• the key
• the function (signing?) using it

Then you would only invoke this PCROPed service to sign something and never put the key in RAM.

But, this means that you need to do this change in your crypto code.

@Jocelyn RICARD​ : what do you think ?

[Fred]

What you gain with STSAFE-A110 is:

• a secure element storing your assets
• the provisioning handled at factory stage

What you need to put in place is indeed an I2C secure communication channel with a MAC key and Cipher key.

Of course, it means you need to handle the diversification of these keys (unless you want the same pair for all devices ? Probably not great).

In the STSAFE-A110 you have the concepts of slots and zones.

You can store the private key in a dedicated slot and store your certificates in zones with permissions.

So, I need to check with an STSAFE-A110 expert but maybe it is possible to say that some elements must never go out of the STSAFE-A110, even if you have the proper MAC/Cipher keys.

If this is confirmed, then at least you are sure that your private keys won't leak even if someone steals the MAC and cipher keys to spoof the STM32.

Still, the MAC/Cipher keys must be protected on STM32 side to avoid that somebody "replaces" the STM32 in the communication.

So, we still have a problem here of protecting these keys: probably the code dealing with I2C secure channel and assets could be put under PCROP.

These are only raw ideas.

Please let me check with the STSAFE-A110 experts.

Also, it means that in the TLS handshake, you must be able to redirect the signing operation to STSAFE-A110.

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