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

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

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

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

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

[SPati.7]

@Fred​  Thanks for detailed explanation.

From the above PCROP or MPU or WRP is not preferred option to achieve Secure Communication because of Keys Storage mechanism, am i right Fred ??

So, STSAFE is better solution to store certificates or Private Keys needed for TLS communication as of now. is this true ??

Here, i have one doubt on STSAFE usage, even to access STSAFE for the Keys stored, STM need to interface with STSAFE over I2C communication, to communicate securely, we are storing MAC & CIPHER pair of keys on both STSAFE and STM as well.

So what is the best way to store Mac & Cipher keys on STM side ?? PCROP Memory or WRP Memory ?? Which one is best ??

[SPati.7]

From the above source, it is clear that Secure User Memory configuration applied from FLASH BASE (0x08000000) to First Sector End (0x0801FFFF). is this correct @Fred​  ??

Then why SE_KEY_REGION is to be PCROP protected again as mentioned below ??

/* 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. */

When performing Signing Verification, is Secure Boot read this Key and kept in RAM ?? for that we are applying PCROP on top of Secure Memory ??

But if Secure Boot copies Key in RAM, here is the leak it self right ??

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