Overview
Technical Background
TrustZone technology divides the system into a Secure world and a Non-secure world. The secure firmware (image3) runs in the Secure world and hosts the core security functions of the system. If the secure firmware is stored in Flash in plaintext, code in the Non-secure world could read and analyze its contents, thereby compromising the TrustZone security isolation mechanism.
RDP (Read Protection) technology protects the TrustZone secure firmware through encrypted storage, ensuring that the secure code exists only in ciphertext form in Flash. This prevents the Non-secure world from obtaining the plaintext, thereby preserving the TrustZone security isolation boundary.
How It Works
RDP uses the AES-256 algorithm to encrypt and protect the secure firmware. The entire process is divided into two phases: the compilation phase and the runtime phase.
Compilation Phase: The SDK post-processing script uses the user-provided key to perform AES-256 encryption on the secure firmware, generating an encrypted firmware image. The encrypted firmware is then programmed into Flash in ciphertext form.
Runtime Phase: During system boot, the hardware engine reads the key from OTP and decrypts the ciphertext firmware in Flash. The entire decryption process is handled automatically by hardware. The key is stored in the OTP secure area with read and write protection, preventing unauthorized access or tampering.
Depending on whether the IC supports Flash address security isolation, RDP provides different firmware execution methods:
Flash address security isolation is not supported. The encrypted firmware is decrypted using a symmetric hardware encryption engine. During system boot, the firmware is fully decrypted and loaded into secure RAM, then executed by the CPU.
Decryption flow: The RDP key in OTP is automatically loaded by hardware into the IPSEC-S decryption engine. The internal secure DMA reads the encrypted firmware from Flash in blocks, the hardware engine decrypts and transfers it to secure RAM, and the CPU jumps to secure RAM for execution.
Flash address security isolation is not supported. The encrypted firmware is decrypted using a symmetric hardware encryption engine. During system boot, the firmware is fully decrypted and loaded into secure RAM, then executed by the CPU.
Decryption flow: The RDP key in OTP is automatically loaded by hardware into the IPSEC-S decryption engine. The internal secure DMA reads the encrypted firmware from Flash in blocks, the hardware engine decrypts and transfers it to secure RAM, and the CPU jumps to secure RAM for execution.
Flash address security isolation is not supported. The encrypted firmware is decrypted using a symmetric hardware encryption engine. During system boot, the firmware is fully decrypted and loaded into secure RAM, then executed by the CPU.
Decryption flow: The RDP key in OTP is automatically loaded by hardware into the IPSEC-S decryption engine. The internal secure DMA reads the encrypted firmware from Flash in blocks, the hardware engine decrypts and transfers it to secure RAM, and the CPU jumps to secure RAM for execution.
Flash address security isolation is supported. The encrypted firmware uses the RSIP hardware engine . In addition to loading firmware into RAM for execution, it also supports XIP (eXecute In Place) mode, which enables real-time decryption and execution directly from Flash without loading the entire firmware into RAM.
Decryption flow: The logical address of the secure firmware is first configured as a secure region through Flash MPC. The RDP key in OTP is automatically loaded by hardware into the RSIP engine. Two execution modes are supported:
XIP execution: When the CPU runs secure code from Flash in the Secure world, RSIP automatically decrypts the firmware into plaintext and returns it to the CPU, without loading the firmware into RAM. This is suitable for scenarios with large firmware and limited RAM space.
RAM execution: Software reads the ciphertext firmware from Flash into secure RAM through RSIP, and the read process automatically decrypts it into plaintext. The CPU then runs the secure firmware in RAM. This is suitable for scenarios requiring higher execution performance.
Overall Usage Flow
The RDP usage flow consists of three phases: development, production, and runtime:
Tip
MbedTLS is compiled into Image3 by default. Developers can refer to the RDP secure service examples.
