RDP Level
The TOE is certified in RDP level 2 with an OEM2 password. The OEM2 password gives the flexibility in a
first step to perform RDP regression from level 2 to level 1, then to perform RDP regression from level 1 to
level 0 (provoking a Flash memory mass erasure) in a second step. It must be noticed that at the RDP level
1 intermediate state, the TOE is not anymore in the certified configuration whereas the security assets are still
present in Flash memory (personalized data area). The integrator has the privilege and responsibility to provide
its OEM2 password (64 bits) when the RDP level is still 0. The OEM2 password can be provisioned using
the STM32CubeProgrammer CLI command. To provision 0xFACEB00C 0xDEADBABE OEM2 password example
value, the STM32CubeProgrammer CLI command is:
./STM32_Programmer_CLI -c port=SWD mode=UR --hardRst -lockRDP2 0xFACEB00C 0xDEADBABE
In case the OEM2 password is not defined, then RDP level 2 is a final state, it is not possible to perform any RDP
regression. To use the certified configuration, the integrator must set the RDP to Level 2. The usage or not of the
OEM2 password is also part of the certified configuration.
Number of images
The TOE is certified in 2 images configuration. In this configuration, there are two distinct firmware images
for the secure and non‑secure applications, so that the firmware images are smaller, and the secure
and non‑secure images can be managed by two distinct entities. This configuration is achieved thanks to
MCUBOOT_IMAGE_NUMBER defined in Linker\flash_layout.h file.
#define MCUBOOT_IMAGE_NUMBER 2 /* 1: S and NS application binaries are assembled in one
single image.
2: Two separated images for S and NS application binaries.
*/
It is possible to configure the number of images to one single image where the secure and non‑secure
applications are assembled so that the boot time is reduced. The laboratory has assessed the security of
both single and separate images. However, to use the certified configuration, SPE and NSPE images must be
separated.
Slot mode
The TOE is certified in primary and secondary slots configuration. In this configuration, for each image, there is a
primary slot for firmware image execution and a secondary slot for firmware image download in the Flash memory
layout. This configuration allows performing over‑the‑air firmware image updates, as the download of an image in
a secondary slot can be performed by firmware image executing in the primary slot. To get this configuration, the
define MCUBOOT_PRIMARY_ONLY line must be commented in Linker\flash_layout.h file.
/* #define MCUBOOT_PRIMARY_ONLY */ /* Defined: No secondary (download) slot(s), only primary
slot(s) for each image.
Undefined: Primary and secondary slot(s) for each
image. */
It is possible to configure the slot mode to a primary only slot, for which the slot area size can be maximized,
but over‑the‑air firmware update is not possible, as it is impossible to download the image in a slot where the
application is executing. The laboratory has assessed the security of primary‑only slot configuration and primary
and secondary slots configuration. However, to use the certified configuration, the integrator must use both
primary and secondary slots configuration.
UM2852
Operational guidance for the integrator role
UM2852 - Rev 1
page 10/27
To Next Page
Loading...
Need help?
General
