Information Security Hardware Features

Information Security Hardware Features

Overview

Ameba MCUs provide various underlying hardware security features that cover multiple security requirements including memory access protection, code/system isolation, boot entry restriction, cryptographic algorithm acceleration, identity recognition, and secure storage, such as:

Identity Recognition: HUK, OTP
Memory Access Protection/Software IP Protection: Write protection, debug interface control, boot code protection, Flash XIP decryption (RSIP)
Code/System Isolation: MPU, TrustZone, MPC, PPC
Boot Entry Restriction
Cryptographic Algorithm Hardware: AES, HASH, ECC, TRNG
Secure Storage

Combined with upper-layer software, chip hardware security features enable more application-level security functions such as secure boot, secure update, secure storage, secure communication, trusted execution environment, etc.

Identity Recognition

HUK (Hardware Unique Key)

HUK is a unique key generated by the chip manufacturer for each Ameba chip during production, with a length of 128 bits, used to derive runtime keys. The HUK is hardware-locked after the ROM stage ends and cannot be accessed again. Common uses of HUK include:

Generating a unique serial number for products equipped with the chip based on HUK through certain algorithms
Performing key derivation based on HUK
For more details, see HUK Derivation

OTP (One-Time Programmable) Area

OTP area is a special storage region within the chip that only supports one-time, irreversible programming to 0. The OTP area of Ameba chips is typically divided into multiple blocks, where security block read and write permissions can be controlled separately, and user-defined areas can have access permissions set (such as Secure CPU only access). Common uses of OTP include:

One-time writing of product identification information that cannot be changed after writing
One-time writing of immutable data, such as public key information used by secure boot to verify application legitimacy
Key protection: after disabling read/write permissions, the CPU cannot access, only designated IPs can access
Security feature configuration, such as enabling secure boot, enabling debug protection, etc.
For more details, see OTP Storage

Memory Protection & Software IP Protection

Internal Flash Write Protection

Ameba chips support write protection for internal Flash, protecting the content of specified internal Flash areas from accidental or malicious modification or erasure. Write protection areas can cover the entire Flash or only cover the starting or ending Page addresses, supporting flexible configuration.

Depending on the product series, internal Flash additionally supports Security Registers functionality of different sizes, allowing users to write trust root information such as public key information or certificates into these registers and lock them through the write protection mechanism, ensuring these critical data are not tampered with during device operation.

Debug Interface Access Control

To prevent firmware code from being illegally read through debug interfaces, Ameba series chips support configuring debug interface access control through OTP to restrict the use of debug functionality.

Password protection: After enabling, the correct password must be entered to access debug functionality
Dynamic authorization: After secure boot verification succeeds, debug permissions for specific domains are dynamically authorized, balancing security with development debugging flexibility (supported by newer series)
Permanent disable: Optional support for prohibiting debug port access to Secure resources while still allowing Non-Secure area debugging; or completely prohibiting any form of debug access
For more details, see SWD Protection

Boot Code Protection

All secure boot code of Ameba series chips is placed in ROM, cannot be modified or erased, and specified areas are locked to only allow instruction fetch operations while preventing data read access. Whether through debuggers or any code running on the chip, the content of protected areas (including instructions and data inside) cannot be read in the form of data access.

This mechanism fundamentally eliminates from the hardware level the risks of boot code being illegally read, reverse engineered, tampered with, or replaced, ensuring that the chip always executes the original manufacturer's trusted boot process after power-on. This prevents malicious programs from stealing keys, tampering with boot logic, or bypassing security checks, providing a solid trusted foundation for subsequent firmware signature verification, secure boot chain, and overall system security.

Flash Memory Data Protection (RSIP)

RSIP functionality is used to protect the confidentiality of code and data placed on Flash. Code and data can be AES encrypted beforehand and stored on Flash in ciphertext form, preventing security risks brought by storing data and code in plaintext on Flash. During system operation, ciphertext code and data on Flash are decrypted in real-time through the RSIP module. This decryption process is transparent to the CPU, requires no additional software participation, and supports direct execution of encrypted code on Flash. Flash can be divided into multiple regions, each using an independent key.

RSIP also supports MMU mapping, which can map the CPU's execution address to different physical addresses on Flash. Therefore, when performing OTA upgrades, there is no need to modify the CPU's execution address; new firmware can be directly written to different regions on Flash, greatly simplifying the OTA upgrade process and avoiding security risks associated with modifying the CPU's execution address during the upgrade.

For more details, see Flash XIP Decryption

Code/System Isolation

MPU (Memory Protection Unit)

MPU is a feature of Cortex-M cores that allows defining different Regions to set attributes and CPU access permissions for different address ranges, such as whether an address range allows execution, is read-only or read-write, allows privileged mode access or user mode access. Through reasonable configuration and use of MPU, isolation of system resources and code can be achieved. For example, the access permission of non-code address ranges can be set to non-executable; or a certain area of Flash can be set to only allow privileged mode read access, combined with code privileged and user mode switching, achieving the purpose of some code being able to access that resource while other code cannot directly access it.

For more details, see Memory Management and Cache

TrustZone

Ameba series chips are based on CM55 cores and all support Arm TrustZone technology, providing system-level security isolation capabilities. CPU operation distinguishes between secure and non-secure states, code and data stored on Flash and RAM are allocated to secure and non-secure areas, allowing CPU access in secure or non-secure states. Additionally, all peripherals in the system and Bus Masters outside the CPU can be assigned secure and non-secure attributes, meaning that the secure area manages not only code and data but can also contain key peripherals and their corresponding interrupts, etc. Based on the isolation functionality provided by TrustZone, a trusted execution environment can be implemented on MCU, with key code and operations placed within the trusted execution environment, avoiding attacks on system key resources due to potential vulnerabilities in application software.

For more details, see TrustZone Secure Processing Environment (SPE)

MPC and PPC Hardware Isolation Controllers

MPC (Memory Protection Controller) and PPC (Peripheral Protection Controller) are hardware isolation units of Ameba series chips, supporting protection of memory areas or peripherals marked as secure at the physical bus level. MPC can divide Flash and RAM memory areas into Secure/Non-Secure, while PPC controls peripheral access permissions. Memory areas protected by MPC can only be accessed in Secure state, and peripherals controlled by PPC can only be operated by code in Secure state.

Boot Entry Restriction

Unique Boot Entry

Ameba series chips enforce a single legitimate boot entry at the hardware level. After system power-on reset, only the CPU with TrustZone functionality is allowed to boot, at which time the entire system is in Secure state, and other CPUs cannot access any system resources. This ensures that secure boot code always runs during every boot, making the verification of the system and subsequent code by secure boot code impossible to bypass.

When Security functionality is enabled, any firmware executed by the boot CPU undergoes verification by secure boot code. Only firmware that passes verification can continue execution; otherwise, the system will be locked in secure boot code and cannot continue execution. This prevents malicious tampering with boot entry, hijacking boot process, executing unauthorized code, and other attack behaviors, ensuring the chip always follows the preset trusted boot path, providing an unbypassable hardware foundation for the secure boot chain.

For more details, see Secure Boot

Crypto Engine

Ameba series chips integrate complete hardware cryptographic units, including TRNG true random number generator, symmetric encryption/decryption engine, and asymmetric encryption engine, providing full-scenario hardware-level security computing support for devices.

The built-in TRNG module can generate random numbers that meet randomness requirements, serving as the basis for cryptographic operations, encrypted communication, etc. For more details, see TRNG
AES encryption engine supports AES-128/192/256 algorithms, providing high-performance hardware symmetric encryption/decryption capabilities, while supporting message authentication code and hash message authentication code algorithms. Newer series engine algorithms have passed NIST CAVP certification. HASH module supports SHA2 series hash algorithms and HMAC operations, capable of efficiently calculating hash values of data. For more details, see Symmetric Encryption Engine
Asymmetric encryption engine mainly provides cryptographic operation functions related to public key algorithms RSA/ECC, capable of independently completing complex cryptographic operations, thereby significantly improving the speed of public key algorithm-related cryptographic operations and releasing CPU computing resources. Newer series engine algorithms have passed NIST CAVP certification and possess side-channel attack defense capabilities. For more details, see Asymmetric Encryption Engine to view more supported algorithms and curves

Secure Storage

By enabling the key protection function in OTP, keys can be stored inside the encryption engine. During chip operation, the encryption engine can use the key for operations, but the CPU and other peripherals cannot directly access the key, thus implementing the secure storage function. Among them, RTL8721F can further configure some keys to only allow use of that key when the encryption engine is in Secure state, and cannot be used after jumping to the application.

Since all Ameba series support TrustZone, the system isolation features brought by TrustZone can be utilized to provide secure storage services based on TF-M software framework in software.

Development Resources

	SDK Download	Link
	FreeRTOS Security Guide	Link
	Contact Us	Link

Recommended ICs

Features	Filter	RTL8721Dx	RTL8720E	RTL8710E	RTL8726E	RTL8713E	RTL8730E	RTL8721F	RTL872xD	RTL8735B
AES Hardware Engine	Select
SHA Hardware Engine	Select
ECDSA/ECDH Hardware Engine	Select
EDDSA Hardware Engine	Select
RSA Hardware Engine	Select
Secure Boot	Select
Flash OTF Decryption	Select
Arm TrustZone	Select
OTP Secure Storage	Select
True Random Number Generator	Select
HUK Derivation Mechanism	Select
Authenticated Debug Access	Select