Release Notes for STM32 Secure Engine
Copyright © 2017 STMicroelectronics
Purpose
STM32 Secure Engine middleware provides a protected environment to manage all critical data and operations (such as cryptography operations accessing firmware encryption key, and others).
Protected code and data are accessible through a single entry point (call gate mechanism) and it is therefore not possible to run or access any SE code or data without passing through it, otherwise a system reset is generated.
Depending on hardware two different mechanisms are provided :
- Firewall-based Secure Engine Isolation : The firewall is opened or closed using a specific “call gate” mechanism: a single entry point (placed at the 2nd word of the Code segment base address) must be used to open the gate and to execute the code protected by the firewall. If the protected code is accessed without passing through the call gate mechanism then a system reset is generated.
- MPU-based Secure Engine Isolation : The MPU-based Secure Engine isolation relies on the concept of privileged and unprivileged levels of software execution. The software must run in unprivileged level of execution by default (when SBSFU or the User Application is running), except for very specific actions like platform initialization or interrupt handling.
For more details, refer to UM2262, AppendixA : Getting started with X-CUBE-SBSFU expansion package
Update History
Main Changes
- Changes for compatibility with IAR V9.20.1
Known Limitations
None
Backward Compatibility
Compatibility with V2.5.2
Main Changes
Update LICENSE file for Key Management Services middleware (Software license agreement description)
For CKS_ENABLED feature (WB series): the initial state of the IPCC interrupts is now kept.
Known Limitations
None
Backward Compatibility
Compatibility with V2.5.1
Main Changes
- Create LICENSE file for Key Management Services middleware (Software license agreement description)
Known Limitations
None
Backward Compatibility
Compatibility with V2.5.0
Main Changes
STM32WB Series : Add specific CKS lock key service (cannot be called in BY-PASS mode)
Remove bootinfo structure and services
Locked objects are no more accessible by searches
Minor update with no functional impact
Known Limitations
None
Backward Compatibility
Break of compatibility with V2.4.1
Main Changes
Add service to enable and disable IRQ services
Modify prepareimage to allow merge of any elf and bin files
Known Limitations
None
Backward Compatibility
No Break of compatibility with V2.4.0
Main Changes
Fix for IT management with firewall.
Minor update with no functional impact.
Known Limitations
None
Backward Compatibility
None
Main Changes
Management of interruption during code execution inside the firewall is now supported for applications with high real time constraints. IRQ are no more disabled when entering into the isolated code environment, when IT_MANAGEMENT compilation switch is enable.
- Add multi-images support:
- A maximum of 3 active images and 3 download areas can be configured.
- Slot number parameter is added to the service SE_APPLI_GetActiveFwInfo().
- Control for read/write/erase operations are extended to the 3 active images headers.
- For each active image, authentication, decryption and integrity are controlled with specific keys.
- Add image state handling feature:
- State information are added in the firmware header: FWIMG_STATE_NEW, FWIMG_STATE_SELFTEST, FWIMG_STATE_INVALID, FWIMG_STATE_VALID, FWIMG_STATE_VALID_ALL.
- New services added: SE_IMG_GetActiveFwState(), SE_IMG_SetActiveFwState(), SE_APP_ValidateFw().
- Image state transitions:
- FWIMG_STATE_NEW -> FWIMG_STATE_SELFTEST : at the end of installation process.
- FWIMG_STATE_SELFTEST -> FWIMG_STATE_VALID : at first startup, the user application should call SE_APP_ValidateFw() to validate the new active image (if the self-tests are successful)
- FWIMG_STATE_SELFTEST -> FWIMG_STATE_INVALID : at reset all actives images in “self-test state” are rollbacked-up to their previous version if identified (else erased).
- FWIMG_STATE_SELFTEST -> FWIMG_STATE_VALID_ALL : the active image identified as MASTER will validate all new installed active images in a single operation.
- Update prepare image tools to support:
- New examples mapping configuration:
- Firmware header is located inside the internal flash between SBSFU binary and standalone loader binary in order to be protected by secure memory (HDP) : STM32H7B3I-DK 2_Images_ExtFlash example provided.
- Header is not contiguous with firmware image : this is required in multi-images configuration to group all headers inside the protected environment (B-L475E-IOT01A 2_Images_ExtFlash example provided). This is also required for image state handling to be able to keep write capability in the header during user application execution (B-L475E-IOT01A, B-L4S5I-IOT01A KMS and ST-SAFE examples provided)
- Header magic information becomes one of SFU1, SFU2 or SFU3 to identify the installation slot (slot active #1, slot active #2, slot active #3).
- Add image state information in the firmware image header.
- VALID/VALID/VALID tag is removed from image header. This tag is no more applicable since image state handling management.
- Header magic information becomes one of SFU1, SFU2 or SFU3 to identify the installation slot (slot active #1, slot active #2, slot active #3).
- For partial image generation, add alignment on SWAP_SIZE : a direct copy (no more gap to be added) can be implemented between the data received over the air and the write operations in the download area.
- For multi-images configuration, add append feature to be able to create a big binary made of SBSFU binary + 3 firmware images.
- Add certificates injection capability for KMS embedded keys configuration.
- New examples mapping configuration:
For CKS_ENABLED feature (P-NUCLEO-WB55.Nucleo): the lock of CM0 keys is now done during execution of SE_LOCK_RESTRICT_SERVICES just before jumping into user application.
Known Limitations
None
Backward Compatibility
Break of compatibility with V2.1.0
Main Changes
Management of header not contiguous with firmware for external flash : when slot0 is mapped in external flash, header of slot0 must be contiguous to SBSFU area, in order to be protected by secure memory
New Secure Engine service (SECBOOT_ECCDSA_WITH_AES128_CTR_SHA256) for initialization of OTFDEC with symmetric keys ; AES CTR cryptographic scheme is required for external flash with OTFDEC variant
- Update of prepareimage.py utility to support :
- partial image update
- generation of big binary for STM32H7B3I-DK board
- 1 binary for internal flash (SBSFU and Header)
- 1 binary for external flash (slot0)
- partial image update
Changes in management of exceptions for STM32 series supporting Flash ECC error (STM32L4, STM32G0, STM32G4, STM32H7 and STM32WB series) : fix on double ecc error management
Known Limitations
None
Backward Compatibility
Break of compatibility with V2.0.0
Main Changes
General improvements (software counter measures) against software attacks and against basic hardware faults injection
Secure Engine extended with Key Management Services, replacing former secure engine crypto services when KMS feature is enabled
Add SE_IMG_Erase API to be able to erase slot #0 header: mandatory for NUCLEO-L073RZ (specific behavior of STM32L0 flash interface : writing instructions during erasing sequence)
prepareimage.py utility updated to support :
- partial image update
- pairing keys, for communication with STSAFE-A100
Known Limitations
None
Backward Compatibility
Break of compatibility with V1.2.0
Main Changes
prepareimage/key/translate_key scripts improvements :
- Quicker execution timing.
- Support of big elf in order to be able to flash SBSFU+ UserApp from IDE : refer to AN5056 for more details.
- Adaptation for ARM V6M architecture (cortex MO+)
- Remove support of cipher text stealing : 16 bytes alignment ensure with linker command files during UserAppbuild process.
Add mapping_export.h for IAR and SW4STM32 tool chains to avoid mapping symbols inclusion into *.c files.
Add support of SE service calls from unprivileged part of application : SE_APP_GET_ACTIVE_FW_INFO.
Security controls added :
- Check the mapping of the data given as parameters toSecure Engine services (SE_BufferCheck_SBSFU() /SE_BufferCheck_in_se_ram()).
- Clean Secure Engine RAM data (SE_LL_CORE_Cleanup())when leaving SBSFU (SE_LockRestrictServices()).
Known Limitations
None
Main Changes
Multiple crypto scheme implemented under compilation switch (se_crypto_config.h) :
- SECBOOT_AES128_GCM_AES128_GCM_AES128_GCM: symmetric crypto.
- SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256(default config) : asymmetric crypto with encrypted (AES128-CBC)Firmware.
- SECBOOT_ECCDSA_WITHOUT_ENCRYPT_SHA256 : asymmetric crypto without firmware encryption.
Build process modification : scripts added in Utilities/KeysAndImages called during :
- SECoreBin build for key generation.
- UserApp build for firmware encryption.
- Windows executable version of the python scripts available : This is now the default tooling for pre/post build actions (so python not mandatory any more)
Secure Engine now using its own stack inside protected area
Files structure updated to provide more feature modularity and feature customization flexibility
Known Limitations
None
Main Changes
First release
Known Limitations
None