Clock security system (CSS)

The CSS is designed to detect a failure of an external clock source (a crystal for example). A loss of clock source is intentional or not. In any case, the device must take appropriate actions to recover. The CSS triggers an interrupt to the core in such event.

If the external clock source drives the main system clock, the CSS switches the system to an internal clock source.

When to use the CSS

Some attacks target the MCU power supply to cause errors that lead to a failure of security countermeasures. A loss of power supply sometimes denotes an attempt to freeze the device state in order to access the internal memory content.

The STM32 devices embed a programmable voltage detector (PVD) that can detect a drop of power. The PVD allows the configuration of a minimum voltage threshold, below which an interrupt is generated, so that appropriate actions are implemented.

When to use the PVD

When to use ECC and parity check

The IDWG is a free running down counter that can be used to trigger a system reset when the counter reaches a given timeout value. The IDWG can be used to provide a solution in case of malfunctions or deadlock in running code. The IDWG is clocked by its own independent low-speed clock (LSI), so that it stays active even in the event of a main clock failure.

When to use the IWDG

Each STM32 device has a unique 96-bit identifier providing an individual reference for any device in any context. These bits can never be altered by the user.

The unique device identifier can be used for direct device authentication, or for instance to derive a unique key from a master OEM key.

As described in Secure applications, cryptography is essential to secure an embedded system. The cryptography enables confidentiality, integrity, and authentication of data or code. For efficiently supporting these functions, most STM32 series include products with hardware cryptography peripherals. These peripherals allow cryptographic computations (such as hashing or symmetric algorithms) to be accelerated. For devices with no such specific hardware acceleration, the STM32 cryptographic firmware library (CryptoLib) provides a software implementation of a large set of cryptographic algorithms.

The cryptography related features for each product can be identified via their root part number, specifically on the second number or letter after the series identifier. For example the STM32L486 and STM32H7B3 devices have crypto hardware while the STM32L476 and STM32H7A3 have to use software library to implement cryptography, and it can be known by their naming.

The ability to generate unpredictable numbers with appropriate statistical properties is essential for cryptographic security. Most STM32 MCUs feature a hardware-based peripheral based on a physical noise source. It can be used to feed a DRNG with a seed, or directly for random numbers, depending on device. Depending on the device, it can be used to seed a DRNG or to generate random numbers directly.

The AES is an industry-standard symmetric encryption and decryption algorithm.

The base peripheral improves AES efficiency by providing hardware support for various block and chaining modes, such as ECB, CBC, CTR, and GCM, as well as for different key lengths and DMA operation. Its main advantages are faster processing and lower power consumption. However, developers must still pay close attention to key management to maintain security.

When AES is used for encryption or decryption, access to the registers containing the key must be protected, and the key material must be erased after use. The MPU can be configured to restrict access to memory containing keys.

SAES provides a higher level of security, partly because its computation is obfuscated to resist more advanced side-channel attacks and partly because, when DHUK is used, the actual encryption key can be hidden so that it never appears in addressable memory in plain form. On applicable devices, SAES can also use keys directly from OBK.

This coprocessor provides acceleration of RSA, DH, and ECC operations over GF(p), based on the Montgomery method for fast modular multiplications. Built-in inward and outward transformations in the Montgomery domain are used to implement the operations required by asymmetric cryptographic algorithms.

The operands are loaded into dedicated memory, and the hardware performs the requested transformation. As with the symmetric cryptography accelerator, the main security concern is that the software must handle key storage and copying.

This feature can be used to wrap an RSA or ECC private key and perform an electronic signature or decryption with greater security, as the private key is not exposed to the CPU during use. As in SAES, DHUK is used for wrapping, and OBK is available for key storage. For more information, refer to AN6205.

This cryptographic peripheral produces a digest of data. Supported algorithms are MD5, SHA-1, SHA-2, and SHA-3. SHA-3 support is limited to the newest products.

The peripheral also supports DMA, which further offloads the CPU.

The STM32 X-CUBE-CRYPTOLIB software library runs on all STM32 devices. It is available for free download at www.st.com/en/product/x-cube-cryptolib. The version V4 is available with full firmware implementation, compiled for Cortex‑M0, Cortex‑M0+, Cortex‑M3, Cortex‑M33, Cortex‑M4, and Cortex‑M7.

The external memory content (code and data) cannot be protected with traditional read/write protections. The way to protect the content is to encrypt and decrypt it inside the device before using it.

One solution is to download the external memory content inside the SRAM, to decrypt it, to execute the code, and/or to use data. There are two drawbacks with this method: it introduces a delay that may not be acceptable, and it uses a large amount of SRAM, depending on the content.

The OTFDEC peripheral offers the possibility to decrypt the content directly with a low-latency penalty, and without the need for SRAM allocation. The OTFDEC decrypts the on-the-fly bus traffic based on the read-request address information. It is used with the Octo-SPI interface (see the figure below).

The OTFDEC uses the AES-128 CTR mode, with a 128-bit key to achieve a latency below 12 system bus cycles. Up to four independent and nonoverlapping encrypted regions can be defined (4-Kbyte granularity), each with its own key.

When to use the OTFDEC

The memory crypto engine feature replaces the OTFDEC in selected products, specifically those with limited internal memory and designed to use mainly external memory.

The differences are summarized in the following table.

(The MCE is included in STM32H7Rx/7Sx)