Update keys used by the SBSFU

[BEnge.1]

Hello,

I am designing a firmware for an IoT that needs to be able to be updated securely. I decided to use the X-CUBE-SBSFU package. From a crypto point of view, the requirements are that:

• The firmware update needs to be confidential
• The firmware update needs to be authenticated

Therefore, I decided to use the SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256 crypto scheme.

So I will need to store on the IoT :

• One symetric key for AES128 (key 1)
• One public key for ECCDSA ((key 2)

According to the UM2262 user manual, those keys are stored in the secure enclave. This means that :

1. If I activate RDP lvl 2, those keys are immutable and can never be updated
2. If I activate RDP lvl 1, I can mass erase the flash and reflash a bootlader with new keys so I need physical access to the device for the update

Question 1: Are those 2 statements correct ?

Another possible scenario that I see is that:

1. I use the Key Management System Middleware
2. I modify the SBSFU so that the keys are stored in the section of the flash referred as "KMS Data" in the X-CUBE-SBSFU documentation.
3. As the KMS Data can be updated using the KMS secure update procedure, I will be able to update the keys remotley

Question 2: Is this something you would advice me to do ?

Question 3: In the example projects, the KMS secure update is used to update keys unrelated to the SBSFU (i.e. keys of the User applicaton), is this for a security reason that I am missing ?

A last scenario is :

1. I use the Key Management System Middleware
2. I use the STSAFE-A110 as the external token for the KMS
3. I modify the SBSFU so that the keys are stored on the STSAFE
4. I modify the KMS secure update procedure so that it becomes possible to update keys located on the STSAFE remotely

Question 4: From you point of view, are the extra security of the STSAFE making that scenario more valuable ?

Question 5: Why is there no example projects in which the keys 1 and 2 are stored on the STSAFE ? Is that a security issue ?

[Jocelyn RICARD]

Hello @BEnge.1​ 

Question1: You didn't specify the STM32 but I guess you are targeting a STM32L4. In that case, yes this is correct. On other chips, like STM32H7, using secure memory you can make JTAG access impossible in RDP1 also.

Question2: The principle of a secure boot is to rely on a root of trust. The root of trust in our case is the combination of 

1) generating and keeping the keys in a safe place

2) flashing your secure boot in a secure environment

3) setting write protection on secure boot and RDP2 so that secureboot cannot be changed

From this point you are sure that no one can update the firmware.

So, opening the ability to change the secureboot, and the keys will increase the risk. 

Question 3: It could be possible to use the KMS to update the symmetric key used for firmware encryption. KMS security is based on same mechanism as SBSFU with different key. So, you would rely on a public key for authentication and a symmetric key for confidentiality specific to KMS to provision new keys for SBSFU. Then the same question would arise concerning KMS keys ...

Question4: I guess your question is to compare with KMS not using STSAFE. In that case, yes, the use of STSAFE would improve the security. Now you need to know that STSAFE usage also require pairing keys to be stored in the device. These keys are used to have a secure communication with the STSAFE. 

Question5: SBSFU was originally made to run on a STM32 standalone. The addition of STSAFE is more related to the need for cloud credentials that can be previsioned in secure factory before assembly.

Now, the STSAFE example in SBSFU demonstrates the use of a chain of certificates for firmware authentication. But, firmware encryption key is kept in the STM32 flash...

Best regards

Jocelyn

[BEnge.1]

Thank you for your quick and comprehensive answer @Jocelyn RICARD​ .

Kindest regards,

Benjamin