Complete Guide to STM32 Encryption: From Hardware to Software

In embedded development, protecting code security is an eternal topic. Whether it’s to prevent competitors from copying or to avoid malicious tampering of products, encryption is an indispensable part. As a widely used MCU, STM32 offers a variety of encryption solutions. This article will comprehensively analyze the encryption strategies of STM32, from hardware to software, helping you create a “golden shield” for your firmware.

1. Hardware Encryption: STM32’s “Iron Wall”

1. Read Protection (RDP)

STM32 provides a read protection feature (Read Out Protection, RDP). By setting the RDP level, it can effectively prevent external tools from reading Flash content.

• Level 1: Prevents external tools from reading Flash, but allows access to the debugging interface.

• Level 2: Completely disables the debugging interface and Flash reading, locking the chip entirely.

Applicable Scenarios: Production stage, ensuring that product firmware is not illegally read.

Note: Level 2 lock cannot be restored, ensure firmware stability before enabling.

2. Advanced Hardware Encryption

The STM32 high-end series (such as STM32F4xxx) also provides more hardware encryption features:

• PDR Register: Supports three levels of encryption, and after Level 2 locking, the chip cannot be reprogrammed via external tools.

• Hash Encryption Module: Can be used to verify firmware integrity or generate keys.

Advantages: Hardware-level encryption, efficient performance, suitable for high-security requirement scenarios.

2. Software Encryption: STM32’s “Intelligent Defense Line”

1. UID-Based Encryption

Each STM32 chip has a unique 96-bit UID (Unique Device ID), which can be used as the basis for encryption.

• Implementation Method:

1. Verify UID in the program, if matched, run; otherwise, enter error logic.

2. Use UID to generate AES keys, encrypt critical code or data.

Obfuscation Measures: When UID verification fails, simulate normal operation to extend the attacker’s analysis time.

Advantages: Low cost, relies on inherent chip characteristics, flexibly adapts to different security needs.

2. AES Encryption

Protect APP code through AES encryption, with the BOOT program responsible for decryption, ensuring that only legitimate firmware can run.

• Implementation Process:

1. Use UID to generate AES keys, encrypt APP firmware.

2. The BOOT program decrypts the APP and verifies its legitimacy.

3. During programming, first write the BOOT and set read protection, then write the encrypted APP.

Advantages: Ensures APP code security, supports remote upgrades, customers can safely download encrypted firmware.

3. Extreme Protection: Program Self-Destruction and IC Camouflage

1. Program Self-Destruction

By detecting abnormal conditions (such as changes in debugging interface levels), trigger the program self-destruction mechanism to overwrite critical Flash areas.

• Implementation Method:

1. Detect JTAG/SWD pin levels; if abnormal, trigger self-destruction.

2. Use Flash programming interface to overwrite critical code areas.

Applicable Scenarios: High-security requirement scenarios, as a last line of defense.

2. IC Camouflage

By hiding or faking IC model and peripheral component parameters, increase the difficulty of reverse engineering.

• Implementation Method:

1. Polish the chip surface and reprint incorrect model numbers.

2. Mark incorrect resistor and capacitor values on the PCB, add redundant components.

Advantages: Significantly increases the difficulty of reverse engineering, low-cost implementation of hardware-level protection.

4. Comprehensive Solution: Multi-Layer Protection Strategy

1. Basic Layer:

• Enable read protection (RDP Level 1) + disable debugging interface.

• Verify UID at program startup; if failed, enter obfuscation mode.

Enhanced Layer:

• Use UID to encrypt critical code segments (like AES-CTR), decrypt and execute at runtime.

• Code obfuscation + anti-debugging detection (like checking debug registers).

Advanced Layer:

• External security chip for bidirectional authentication.

• Use STM32 hardware encryption modules (like HAL library’s AES/TRNG)

5. Production Process Optimization

1. Custom Programming Tools: Develop scripts to automatically read UID, generate keys, and update firmware.

2. Secure Storage: Store UID hash values in a separate Flash sector to avoid accidental overwriting.

3. Testing and Verification: Conduct regular security tests to assess protection effectiveness and adjust strategies.

Whether protecting intellectual property or ensuring product security, encryption is an indispensable part. I hope this article can provide valuable references for your STM32 encryption design, helping you create a “golden shield” for your firmware!

Follow me for more technical insights!