Asymmetric Crypto Engine
Introduction
The Asymmetric Crypto Engine (PKE) is a dedicated hardware acceleration unit within the SoC for handling public-key cryptographic operations. Compared with software implementations, the hardware acceleration engine can significantly improve the execution efficiency of asymmetric cryptographic algorithms while protecting key security through a physical isolation mechanism, playing an important role in IoT security systems.
Application Background
In IoT device security scenarios, asymmetric cryptographic algorithms are widely used in critical security processes such as digital signatures, key exchange, and identity authentication. However, such algorithms involve a large number of complex mathematical operations (e.g., large-number modular exponentiation and elliptic curve point multiplication). If implemented entirely in software, they consume significant CPU resources with low execution efficiency. The Asymmetric Crypto Engine implements these core operations through dedicated hardware circuits, greatly improving operation speed while ensuring security.
Working Principle
The Asymmetric Crypto Engine connects to the CPU through the APB bus and internally contains dedicated computation units and storage units. When the application layer needs to perform an asymmetric cryptographic operation, the CPU writes the operation parameters into the engine’s registers and memory area, configures the control register to start the operation, and the engine hardware automatically completes the core cryptographic operation and returns the result. The entire process is transparent to the upper-layer application, and the user can complete the operation through APIs.
Security Features
The Asymmetric Crypto Engine fully considers security protection requirements in its architecture design:
Physical isolation: The engine’s internal storage unit is isolated from the system bus, preventing keys from being stolen by bus sniffing attacks.
OTP key support: Supports pre-burning private keys into the OTP (One Time Programmable) region. The OTP key is directly connected to the engine and cannot be read or tampered with externally.
Side-channel attack protection: Some chip models support DPA (Differential Power Analysis), SPA (Simple Power Analysis), and Timing Attack protection.
TrustZone support: Some chip models support ARM TrustZone technology and can automatically identify the CPU’s secure/non-secure access state.
Advantages
Compared with a pure software implementation, the Asymmetric Crypto Engine offers the following advantages:
High performance: Hardware acceleration significantly shortens operation time and reduces CPU usage.
Low power consumption: Dedicated hardware circuits consume less power than running software algorithms on a general-purpose CPU.
High security: The physical isolation mechanism and OTP key storage effectively prevent key leakage.
Ease of use: Provides well-encapsulated API interfaces, so users do not need to be concerned with low-level hardware details.
Functional Architecture
The following lists the functional specifications of the Asymmetric Crypto Engine by chip series, including the basic functions.
Not supported.
Basic Functions:
Key Generation:
Generate public and private keys using the mathematical properties of elliptic curves.
Digital Signature:
Supported signature algorithm: ECDSA
ECC operation curve support:
Prime field curves: 192-256 bits
Montgomery Curves: Curve25519
Key Exchange: Supports ECDH.
OTP Key Port (only for ECDSA public key generation/signing)
Physically irreversible writing
Physical architecture isolation (OTP key directly connected to ECC engine, preventing bus sniffing attacks)
Basic Functions:
Key Generation:
Generate public and private keys using the mathematical properties of elliptic curves.
Digital Signature:
Supported signature algorithm: ECDSA
ECC operation curve support:
Prime field curves: 192-256 bits
Montgomery Curves: Curve25519
Key Exchange: Supports ECDH.
OTP Key Port (only for ECDSA public key generation/signing)
Physically irreversible writing
Physical architecture isolation (OTP key directly connected to ECC engine, preventing bus sniffing attacks)
Basic Functions:
Key Generation:
Generate public and private keys using the mathematical properties of elliptic curves.
Digital Signature:
Supported signature algorithm: ECDSA
ECC operation curve support:
Prime field curves: 192-256 bits
Montgomery Curves: Curve25519
Key Exchange: Supports ECDH.
OTP Key Port (only for ECDSA public key generation/signing)
Physically irreversible writing
Physical architecture isolation (OTP key directly connected to ECC engine, preventing bus sniffing attacks)
Basic Functions:
Key Generation:
Generate public and private keys using the mathematical properties of elliptic curves.
Digital Signature:
Supported signature algorithm: ECDSA
ECC operation curve support:
Prime field curves: 192-256 bits
Montgomery Curves: Curve25519
Key Exchange: Supports ECDH.
OTP Key Port (only for ECDSA public key generation/signing)
Physically irreversible writing
Physical architecture isolation (OTP key directly connected to ECC engine, preventing bus sniffing attacks)
Basic Functions:
Key Generation:
ECC key generation: Utilizes the mathematical properties of elliptic curves to generate public and private keys.
Digital Signature:
Supported signature algorithms: ECDSA, EdDSA, and RSA
ECC operation curve support:
Prime field curves: 192~256 bits
Montgomery curves: Curve25519
Edwards curves: Ed25519
RSA 256~3072 bits encryption and decryption
Key Exchange: Supports ECDH.
OTP Key Port (only for ECDSA public key generation/signing)
Physically irreversible writing
Physical architecture isolation (OTP key directly connected to ECC engine, preventing bus sniffing attacks)
The engine supports protection against DPA, SPA, and Timing Attacks. The engine algorithm has been certified by NIST CAVP.
Basic Functions:
Key Generation:
RSA key generation: Includes prime number screening and generation of corresponding public and private key pairs.
ECC key generation: Utilizes the mathematical properties of elliptic curves to generate public and private keys, offering higher key efficiency compared to RSA.
Digital Signature:
Supports various signature algorithms, such as RSA, ECDSA, and EdDSA.
ECC operation curve support:
Prime field curves: 112~512 bits (including SM2)
Binary field curves: 113~512 bits
Montgomery curves: 128~512 bits (including X25519, X448)
Edwards curves: 128~512 bits (including Ed25519, Ed448)
RSA 256~4096 bits encryption and decryption
RSA, ECC key exchange
OTP key (only for ECDSA public key generation/signing)
Security Architecture:
The Asymmetric Crypto Engine supports TrustZone technology and can automatically identify whether the CPU access is in Secure or Non-secure state. It incorporates a hardware mutex lock mechanism, meaning the CPU must first obtain this mutex lock before each operation; otherwise, it cannot access the hardware registers.
When the Secure CPU holds the lock, all Non-secure access is blocked. Only after the Secure CPU releases the lock can the Non-secure CPU regain access. Conversely, if a Non-secure CPU holds the lock, the Secure CPU can configure a dedicated preemption register to forcibly release the Non-secure lock and reset the engine, thereby immediately gaining control of the engine.
Additionally, each time the lock is released, the engine automatically clears sensitive information from the hardware and register states, ensuring no information leakage occurs.
The engine supports protection against DPA, SPA, and Timing Attacks. The engine algorithm has been certified by NIST CAVP.
Basic Functions:
Key Generation:
RSA key generation: Includes prime number screening and generation of corresponding public and private key pairs.
ECC key generation: Utilizes the mathematical properties of elliptic curves to generate public and private keys, offering higher key efficiency compared to RSA.
Digital Signature:
Supports various signature algorithms, such as RSA, ECDSA, and EdDSA.
ECC operation curve support:
Prime field curves: 112~512 bits (including SM2)
Binary field curves: 113~512 bits
Montgomery curves: 128~512 bits (including X25519, X448)
Edwards curves: 128~512 bits (including Ed25519, Ed448)
RSA 256~4096 bits encryption and decryption
RSA, ECC key exchange
OTP key (only for ECDSA public key generation/signing)
Security Architecture:
The Asymmetric Crypto Engine supports TrustZone technology and can automatically identify whether the CPU access is in Secure or Non-secure state. It incorporates a hardware mutex lock mechanism, meaning the CPU must first obtain this mutex lock before each operation; otherwise, it cannot access the hardware registers.
When the Secure CPU holds the lock, all Non-secure access is blocked. Only after the Secure CPU releases the lock can the Non-secure CPU regain access. Conversely, if a Non-secure CPU holds the lock, the Secure CPU can configure a dedicated preemption register to forcibly release the Non-secure lock and reset the engine, thereby immediately gaining control of the engine.
Additionally, each time the lock is released, the engine automatically clears sensitive information from the hardware and register states, ensuring no information leakage occurs.
OTP Keys
In addition to software keys, the engine also supports pre-burning private keys into the OTP region. The OTP key is directly connected to the engine through a physical isolation mechanism and cannot be read or tampered with externally. It is the recommended solution for protecting core private keys in production environments.
Not supported.
The Asymmetric Crypto Engine’s OTP key only supports ECDSA public key generation and signing. The OTP key is directly connected to the engine and uses a physical isolation mechanism to prevent the key from being stolen by bus sniffing attacks.
The engine can obtain the private key in two ways:
Software key: The user passes the private key to the API, which writes it into the engine register.
OTP key: The engine automatically reads the pre-burned private key from the OTP region.
The OTP region can store two private keys for ECDSA use, accessible only through engine triggering and cannot be read or tampered with externally. Before using an OTP key, the private key must first be burned to the specified OTP address.
OTP key configuration is as follows:
OTP Key |
Address |
Size bits |
Default Value |
Description |
|---|---|---|---|---|
ECDSA_PRI_KEY1 |
Physical mapping 0x280 |
256 |
0xFF |
If OTPKEY=1, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY2 |
Physical mapping 0x2A0 |
256 |
0xFF |
If OTPKEY=2, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY1_Read_Protection |
Physical mapping 0x366[2] |
1 |
1 |
0: Enable ECDSA Key1 read protection, prohibit key reading 1: Disable ECDSA Key1 read protection |
ECDSA_PRI_KEY1_Write_Protection |
Physical mapping 0x366[3] |
1 |
1 |
0: Enable ECDSA Key1 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key1 write protection |
ECDSA_PRI_KEY2_Read_Protection |
Physical mapping 0x366[4] |
1 |
1 |
0: Enable ECDSA Key2 read protection, prohibit key reading 1: Disable ECDSA Key2 read protection |
ECDSA_PRI_KEY2_Write_Protection |
Physical mapping 0x366[5] |
1 |
1 |
0: Enable ECDSA Key2 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key2 write protection |
The Asymmetric Crypto Engine’s OTP key only supports ECDSA public key generation and signing. The OTP key is directly connected to the engine and uses a physical isolation mechanism to prevent the key from being stolen by bus sniffing attacks.
The engine can obtain the private key in two ways:
Software key: The user passes the private key to the API, which writes it into the engine register.
OTP key: The engine automatically reads the pre-burned private key from the OTP region.
The OTP region can store two private keys for ECDSA use, accessible only through engine triggering and cannot be read or tampered with externally. Before using an OTP key, the private key must first be burned to the specified OTP address.
OTP key configuration is as follows:
OTP Key |
Address |
Size bits |
Default Value |
Description |
|---|---|---|---|---|
ECDSA_PRI_KEY1 |
Physical mapping 0x280 |
256 |
0xFF |
If OTPKEY=1, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY2 |
Physical mapping 0x2A0 |
256 |
0xFF |
If OTPKEY=2, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY1_Read_Protection |
Physical mapping 0x366[2] |
1 |
1 |
0: Enable ECDSA Key1 read protection, prohibit key reading 1: Disable ECDSA Key1 read protection |
ECDSA_PRI_KEY1_Write_Protection |
Physical mapping 0x366[3] |
1 |
1 |
0: Enable ECDSA Key1 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key1 write protection |
ECDSA_PRI_KEY2_Read_Protection |
Physical mapping 0x366[4] |
1 |
1 |
0: Enable ECDSA Key2 read protection, prohibit key reading 1: Disable ECDSA Key2 read protection |
ECDSA_PRI_KEY2_Write_Protection |
Physical mapping 0x366[5] |
1 |
1 |
0: Enable ECDSA Key2 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key2 write protection |
The Asymmetric Crypto Engine’s OTP key only supports ECDSA public key generation and signing. The OTP key is directly connected to the engine and uses a physical isolation mechanism to prevent the key from being stolen by bus sniffing attacks.
The engine can obtain the private key in two ways:
Software key: The user passes the private key to the API, which writes it into the engine register.
OTP key: The engine automatically reads the pre-burned private key from the OTP region.
The OTP region can store two private keys for ECDSA use, accessible only through engine triggering and cannot be read or tampered with externally. Before using an OTP key, the private key must first be burned to the specified OTP address.
OTP key configuration is as follows:
OTP Key |
Address |
Size bits |
Default Value |
Description |
|---|---|---|---|---|
ECDSA_PRI_KEY1 |
Physical mapping 0x280 |
256 |
0xFF |
If OTPKEY=1, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY2 |
Physical mapping 0x2A0 |
256 |
0xFF |
If OTPKEY=2, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY1_Read_Protection |
Physical mapping 0x366[2] |
1 |
1 |
0: Enable ECDSA Key1 read protection, prohibit key reading 1: Disable ECDSA Key1 read protection |
ECDSA_PRI_KEY1_Write_Protection |
Physical mapping 0x366[3] |
1 |
1 |
0: Enable ECDSA Key1 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key1 write protection |
ECDSA_PRI_KEY2_Read_Protection |
Physical mapping 0x366[4] |
1 |
1 |
0: Enable ECDSA Key2 read protection, prohibit key reading 1: Disable ECDSA Key2 read protection |
ECDSA_PRI_KEY2_Write_Protection |
Physical mapping 0x366[5] |
1 |
1 |
0: Enable ECDSA Key2 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key2 write protection |
The Asymmetric Crypto Engine’s OTP key only supports ECDSA public key generation and signing. The OTP key is directly connected to the engine and uses a physical isolation mechanism to prevent the key from being stolen by bus sniffing attacks.
The engine can obtain the private key in two ways:
Software key: The user passes the private key to the API, which writes it into the engine register.
OTP key: The engine automatically reads the pre-burned private key from the OTP region.
The OTP region can store two private keys for ECDSA use, accessible only through engine triggering and cannot be read or tampered with externally. Before using an OTP key, the private key must first be burned to the specified OTP address.
OTP key configuration is as follows:
OTP Key |
Address |
Size bits |
Default Value |
Description |
|---|---|---|---|---|
ECDSA_PRI_KEY1 |
Physical mapping 0x280 |
256 |
0xFF |
If OTPKEY=1, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY2 |
Physical mapping 0x2A0 |
256 |
0xFF |
If OTPKEY=2, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY1_Read_Protection |
Physical mapping 0x366[2] |
1 |
1 |
0: Enable ECDSA Key1 read protection, prohibit key reading 1: Disable ECDSA Key1 read protection |
ECDSA_PRI_KEY1_Write_Protection |
Physical mapping 0x366[3] |
1 |
1 |
0: Enable ECDSA Key1 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key1 write protection |
ECDSA_PRI_KEY2_Read_Protection |
Physical mapping 0x366[4] |
1 |
1 |
0: Enable ECDSA Key2 read protection, prohibit key reading 1: Disable ECDSA Key2 read protection |
ECDSA_PRI_KEY2_Write_Protection |
Physical mapping 0x366[5] |
1 |
1 |
0: Enable ECDSA Key2 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key2 write protection |
The Asymmetric Crypto Engine’s OTP key only supports ECDSA public key generation and signing. The OTP key is directly connected to the engine and uses a physical isolation mechanism to prevent the key from being stolen by bus sniffing attacks.
The engine can obtain the private key in two ways:
Software key: The user passes the private key to the API, which writes it into the engine register.
OTP key: The engine automatically reads the pre-burned private key from the OTP region.
The OTP region can store two private keys for ECDSA use, accessible only through engine triggering and cannot be read or tampered with externally. Before using an OTP key, the private key must first be burned to the specified OTP address.
OTP key configuration is as follows:
OTP Key |
Address |
Size bits |
Default Value |
Description |
|---|---|---|---|---|
ECDSA_PRI_KEY1 |
Physical mapping 0x280 |
256 |
0xFF |
If OTPKEY=1, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY2 |
Physical mapping 0x2A0 |
256 |
0xFF |
If OTPKEY=2, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY1_Read_Protection |
Physical mapping 0x366[2] |
1 |
1 |
0: Enable ECDSA Key1 read protection, prohibit key reading 1: Disable ECDSA Key1 read protection |
ECDSA_PRI_KEY1_Write_Protection |
Physical mapping 0x366[3] |
1 |
1 |
0: Enable ECDSA Key1 write protection, prohibit hackers from writing the key to all 0s 1: Disable ECDSA Key1 write protection |
ECDSA_PRI_KEY2_Read_Protection |
Physical mapping 0x366[4] |
1 |
1 |
0: Enable ECDSA Key2 read protection, prohibit key reading 1: Disable ECDSA Key2 read protection |
ECDSA_PRI_KEY2_Write_Protection |
Physical mapping 0x366[5] |
1 |
1 |
0: Enable ECDSA Key2 write protection, prohibit hackers from writing the key to all 0s 1: Disable ECDSA Key2 write protection |
The Asymmetric Crypto Engine’s OTP key only supports ECDSA public key generation and signing. The OTP key is directly connected to the engine and uses a physical isolation mechanism to prevent the key from being stolen by bus sniffing attacks.
The engine can obtain the private key in two ways:
Software key: The user passes the private key to the API, which writes it into the engine register.
OTP key: The engine automatically reads the pre-burned private key from the OTP region.
The OTP region can store two private keys, accessible only through engine triggering and cannot be read or tampered with externally. Before using an OTP key, the private key must first be burned to the specified OTP address.
By default, the OTP key can only be accessed by a Secure-state CPU. In Secure state, the pke_ecdsa_share_hw_key API can be called to configure the OTP key as shared or non-shared, allowing Non-secure CPU access.
OTP key configuration is as follows:
Key ID |
Key Type |
Length (bits) |
OTP Address |
Key Usage Permission |
|---|---|---|---|---|
0 |
OTP |
256 |
0x280 |
Secure (default) / Non-secure |
1 |
OTP |
256 |
0x2A0 |
Secure (default) / Non-secure |
The Asymmetric Crypto Engine’s OTP key only supports ECDSA public key generation and signing. The OTP key is directly connected to the engine and uses a physical isolation mechanism to prevent the key from being stolen by bus sniffing attacks.
The engine can obtain the private key in two ways:
Software key: The user passes the private key to the API, which writes it into the engine register.
OTP key: The engine automatically reads the pre-burned private key from the OTP region.
The OTP region can store two private keys, accessible only through engine triggering and cannot be read or tampered with externally. Before using an OTP key, the private key must first be burned to the specified OTP address.
By default, the OTP key can only be accessed by a Secure-state CPU. In Secure state, the pke_ecdsa_share_hw_key API can be called to configure the OTP key as shared or non-shared, allowing Non-secure CPU access.
OTP key configuration is as follows:
Key ID |
Key Type |
Length (bits) |
OTP Address |
Key Usage Permission |
|---|---|---|---|---|
0 |
OTP |
256 |
0x340 |
Secure (default) / Non-secure |
1 |
OTP |
256 |
0x360 |
Secure (default) / Non-secure |
Working Principle
The Asymmetric Crypto Engine connects to the CPU through the APB bus and operates in Slave mode. The engine internally contains computation units, storage units, and control registers. The CPU completes operation parameter configuration and result retrieval by reading and writing these registers.
To ensure concurrency safety in a multitasking environment, the engine has a built-in hardware mutex mechanism. When a Secure-state CPU holds the lock, all Non-secure accesses are blocked; if a Non-secure CPU holds the lock, the Secure CPU can forcibly acquire usage rights through a dedicated preemption register, ensuring priority for secure tasks.
Workflow
The standard operation flow of the engine is as follows:
Acquire the mutex: The CPU acquires the engine’s hardware mutex.
Write operation parameters: Write the algorithm parameters into the engine’s storage unit.
Configure operation mode: Set the control register to select the required operation mode.
Start the operation: Enable the engine to start the computation.
Monitor operation progress: Poll the status register to monitor operation progress.
Retrieve operation result: After detecting the completion flag bit, read the operation result from the storage unit.
Release the mutex: Release the mutex so that other tasks can use the engine.
Exception Handling
The engine provides the following exception handling mechanisms:
Error identification: The status register contains error flag bits; if an error is detected during polling, the process can be terminated immediately.
Error feedback: The API returns predefined error codes (a non-zero value indicates an error, and 0 indicates normal completion).
Usage
After introducing the engine’s working principle and flow, the following describes how to use the engine. The engine provides two usage methods: the low-level direct API and the MbedTLS integrated API.
Development Phase
During the development phase, users typically use software keys for functional verification and debugging:
Select the API type:
Use the low-level API to directly control the engine, which offers more comprehensive functionality but requires an understanding of the engine’s working principle.
Use the MbedTLS integrated API, which is more general but only supports software keys.
Configure the SDK:
Enable the Asymmetric Crypto Engine related options in SDK menuconfig.
Select the supported algorithm curves according to requirements.
Call the API:
Refer to the example code to call the corresponding API to complete key generation, signing, or verification operations.
Production Phase
During the production phase, OTP keys are recommended for higher security:
Generate the key pair:
Generate the public/private key pair during the development phase.
Save the public key for signature verification and the private key for OTP burning.
Burn the OTP key:
Burn the private key to the specified OTP address (see the OTP key table above).
Configure the key read protection/write protection bits.
Warning
The OTP (One Time Programmable) region can be written only once and cannot be erased or revoked. Carefully verify the address and data before executing the write command.
Use the low-level API:
The low-level API must be used when using OTP keys.
The MbedTLS API does not support OTP keys.
API
Whether using software keys or OTP keys, Realtek provides comprehensive API interfaces, so users do not need to be concerned with low-level register operation details.
Low-level API
The low-level API provides full control over the engine and supports both software keys and OTP keys:
Key generation API: Generates ECC or RSA key pairs.
Signing API: Uses the private key to digitally sign data.
Verification API: Uses the public key to verify signature validity.
Key exchange API: Performs ECDH key exchange.
OTP key configuration API: Configures the access permissions of OTP keys.
MbedTLS Integrated API
To improve compatibility, Realtek has integrated the hardware acceleration engine into the MbedTLS API. Users can use the standard MbedTLS ECDSA/ECDH API, with hardware acceleration automatically invoked underneath. The MbedTLS API only supports software keys, not OTP keys. Due to hardware limitations, MbedTLS support for the SECP521R1 curve has been disabled.
Supported Algorithms and Curves
The algorithm curves supported by each chip are listed below. Common curve parameters are pre-built into the ROM, so users do not need to provide them additionally:
Not supported.
SECP256R1
SECP224R1
SECP192R1
SECP256K1
SECP224K1
SECP192K1
BP256R1
CURVE25519
SECP256R1
SECP224R1
SECP192R1
SECP256K1
SECP224K1
SECP192K1
BP256R1
CURVE25519
SECP256R1
SECP224R1
SECP192R1
SECP256K1
SECP224K1
SECP192K1
BP256R1
CURVE25519
SECP256R1
SECP224R1
SECP192R1
SECP256K1
SECP224K1
SECP192K1
BP256R1
CURVE25519
SECP256R1
SECP224R1
SECP192R1
SECP256K1
SECP224K1
SECP192K1
BP256R1
CURVE25519
ED25519
SECP192R1
SECP224R1
SECP256R1
SECP384R1
BP256R1
BP384R1
BP512R1
CURVE25519
SECP192K1
SECP224K1
SECP256K1
CURVE448
ED25519
ED448
SECP192R1
SECP224R1
SECP256R1
SECP384R1
BP256R1
BP384R1
BP512R1
CURVE25519
SECP192K1
SECP224K1
SECP256K1
CURVE448
ED25519
ED448
