Memory crypto engine (MCE)

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.

Table 17. Features of the OTFDEC compared with the MCE
Feature	OTFDEC	MCE
Function	On-the-fly decryption	Encryption and decryption
Algorithm	AES-based stream + proprietary	AES stream, AES block, DPA resistant
Key management	128b key per region, TZ protection, write only	Similar, usually tied to OBK by the software logic
Latency	Maximum of 12 cycles	11 to 36 cycles (scalable security)
Security	Base level	Including tamper and secure boot integration
Integration	Associated with XSPI	Associated with memory subsystem, usable with FMC

(The MCE is included in STM32H7Rx/7Sx)

Guidelines

Secure systems can take advantage of many security supporting hardware feature. Some are useful for any system, and need little change in the application code to be activated and fully functional. It is the case of the RDP feature that prevents basic access to the flash memory by disabling the debug port. Other features must be selected depending on user application and the required security level.

This section helps defining the adapted set of security features, depending on the system use-cases. The use-cases are gathered in four main groups: manufacturing security (1), protection against external (2) and internal (3) threats, security maintenance (4), and other use-cases related to cryptography (5) (see the table below).

Table 18. Security use cases
1. Secure manufacturing: SFI
-	1.1 Complement existing manufacturing site security with utilization of SFI.
2.Device protection against external threats: RDP protection, life cycle protection, tamper detection, device monitoring
-	2.1 Device configuration (option bytes, not supposed to be modified ever)
	Use RDP level 2 or Closed (Locked) product state. This closes the device from any external access.
	2.2 Remove debug capability for the device.
	Use product life cycle or RDP level 2 for disabling the debug. Some devices allow usage of debug authentication (DA).
	2.3 Protect a device against a loss of external clock source (crystal).
	Enable clock security system (CSS).
	2.4 Detect a system-level intrusion.
	Use tamper detection capability.
	2.5 Protect a device from code injection.
	Use the RDP or product life cycle. Isolate communication port protocol with the MPU, firewall, or HDP. Limit communication port protocol access range. Use write protection on empty memory areas (flash memory and SRAM).
3. Code protection against internal threats: TrustZone, PCROP, MPU, firewall, and HDP
-	3.1 Protect the code against cloning.
	Use RDP level 2 against external access. Use PCROP on most sensitive parts of the code against internal read access. Use OTFDEC to secure code stored in the external memory.
	3.2 Protect secret data from other processes.
	Use firewall to protect both code and data. Use MPU to protect secret data area from being read. Use HDP in case data must only be used at reset. Use secure domain of TrustZone, if available.
	3.3 Protect code and data when not fully verified or trusted libraries are used.
	Use PCROP to protect user most sensitive code. Use firewall to protect user sensitive application (code, data, and execution). Use MPU and de-privilege the untrusted library. Use IWDG to avoid any deadlock. Use secure domain of TrustZone, if available.
4. Device security check and maintenance: integrity checks, SB, SFU
-	4.1 Check code integrity.
	Hash firmware code at reset and compare to expected value. Enable ECC on the flash memory and parity check on the SRAM.
	4.2 Security checks or embedded firmware authentication
	Implement SB application with cryptography. Protect SB application secret data (refer to previous sections). Guarantee unique boot entry on SB application: Use HDP if available. Disable boot pin selection by BOOT_LOCK or RDP.
	4.3 Securely update the firmware in the field.
	Implement a SFU application with cryptography. Apply relevant secure memory protection around the SFU secret data (refer to previous sections).
5. Communication and authentication: cryptography
-	5.1 Communicate securely.
	Use or implement secure communication stacks relying on cryptography for confidentiality and authentication (such as TLS for Ethernet).
	5.2 Use the ST AES/SHA cryptographic functions with STM32 devices.
	Use only official software implementation by ST with STM32 X-CUBE-CRYPTOLIB.
	5.3 Accelerate AES/SHA cryptographic functions.
	Use device with cryptographic hardware peripheral together with official STM32 X-CUBE-CRYPTOLIB. Use MCE or OTFDEC to access AES-ciphered code in the external memory without latency penalty.
	5.4 Generate random data.
	Use RNG embedded in the STM32 devices.
	5.5 Uniquely identify ST microcontrollers.
	Use STM32 96-bit unique ID.
	5.6 Authenticate a product device.
	Embed a shared encryption key in the device, and exchange encrypted message.
	5.7 Uniquely authenticate a device.
	Embed a device private key and its certificate in the device, and exchange encrypted message.
	5.8 Authenticate communication servers.
	Embed a shared encryption key in the device, and exchange encrypted message. Embed server public key in the device, and exchange encrypted message.
	5.9 Store keys securely.
	Use OBK where available. Use SAES and CCB to prevent exposing key. After usage, clean-up exposed key or intermediate data.

Conclusion

No system can be made secure by simply enabling security features in the hardware. Security must be rooted in the architecture of the complete solution.

The threats must be identified, the countermeasures correctly designed and implemented in synergy with other security features.

As security demands considerable resources, it is important to correctly evaluate the risks, and spend the resources efficiently, keeping in mind the cost of attack and the value of the protected asset.

The concept of root of trust is pivotal because it uses a more hierarchic and centralized approach, as opposed to attempting to apply security ad hoc.

With the STM32 microcontrollers, the embedded and IoT security is very cost-effective and robust.

Cryptography–Main concepts

Integrity, authentication, and confidentiality

The objectives of cryptography are threefold:

Confidentiality: protection of sensitive data against unauthorized read access
Authentication: ensuring the identity of the message sender
Integrity: detection of any message corruption during transmission

To meet these objectives, all secure data flows rely on more or less complex combinations of the below algorithms:

Secret key/symmetric cryptography
Public key/asymmetric cryptography
Hashing

These algorithms are described in this appendix.

Secret key algorithms

This family of algorithms ensures confidentiality by ciphering a clear plain text with a secret key shared between the transmitter and the receiver. This technique is referred to as symmetric cryptography because the same key is used for ciphering and deciphering.

The inherent weakness of these algorithms is the key sharing between both parties. It may not be an issue in secure environments (such as manufacturing plants), but when both parties are distant, the key transfer becomes a challenge.

Among all secret key algorithms, block-based algorithms are very common since they can be efficiently accelerated by hardware or software parallel implementations. Typical AES (advanced encryption standard) algorithms operate on clear blocks of 128 bits. They produce ciphered blocks of the same length using keys of 128, 192, or 256 bits. The different ways to chain consecutive blocks are called “mode of operations”. They include cipher block chaining (CBC), counter mode (CTR) and Galois counter mode (GCM).

Since these algorithms are deterministic, they always mix input data with a random value, known as nonce, used only for one session as initialization vector.

Public key algorithms (PKA)

This class of algorithms is based on a pair of keys. One key, the private one, is never exchanged with any remote system, while the other key, the public one, can be shared with any party. The relationship between both keys is asymmetric (asymmetric cryptography):

A message encrypted by the private key can be read by any party with the public key. This mechanism ensures a strong authentication of the sender since the private key has never been shared. Digital signatures are based on this mechanism.
Figure 16. Signature
A message encrypted by the public key can only be read by the private key owner.
Figure 17. PKA encryption

The main use of public key algorithms is authentication. It is also used to resolve the “key sharing” issue of symmetric cryptography. However, this comes at the cost of more complex operations, increased computation time and bigger memory footprint.

RSA and elliptic curve cryptography (ECC) are the most common asymmetric algorithms.

Hybrid cryptography

Common secure transfer protocols (such as Bluetooth and TLS) rely on both algorithm types. This scheme is known as hybrid cryptography:

Asymmetric cryptography is used first, in order to solve the symmetric key-sharing problem. A session key is exchanged by the public key owner to the private key owner.
Transfer confidentiality is then provided by a symmetric algorithm using the session key.