Overview
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)
Driver Architecture:
The ECC hardware encryption engine is a security chip module dedicated to digital signature algorithms, implementing cryptographic operations directly through hardware circuits. It adopts physical protection mechanisms to ensure key security and can improve computational efficiency compared to software solutions.
The ECC software is responsible for parsing upper-layer protocols and command scheduling, while the hardware layer completes core encryption computation tasks through specially designed circuits. The software layer architecture is shown in the following diagram:
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)
Driver Architecture:
The ECC hardware encryption engine is a security chip module dedicated to digital signature algorithms, implementing cryptographic operations directly through hardware circuits. It adopts physical protection mechanisms to ensure key security and can improve computational efficiency compared to software solutions.
The ECC software is responsible for parsing upper-layer protocols and command scheduling, while the hardware layer completes core encryption computation tasks through specially designed circuits. The software layer architecture is shown in the following diagram:
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)
Driver Architecture:
The ECC hardware encryption engine is a security chip module dedicated to digital signature algorithms, implementing cryptographic operations directly through hardware circuits. It adopts physical protection mechanisms to ensure key security and can improve computational efficiency compared to software solutions.
The ECC software is responsible for parsing upper-layer protocols and command scheduling, while the hardware layer completes core encryption computation tasks through specially designed circuits. The software layer architecture is shown in the following diagram:
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)
Driver Architecture:
The ECC/RSA hardware encryption engine is a secure chip module dedicated to digital signature algorithms, implementing cryptographic operations directly through hardware circuits. It employs physical protection mechanisms to ensure key security and can improve computational efficiency compared to software solutions.
The ECC/RSA software is responsible for parsing upper-layer protocols and command scheduling, while the hardware layer completes core encryption computation tasks through specially designed circuits. The software layer architecture is shown in the following diagram:
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.
Asymmetric Encryption:
Supports various signature algorithms, such as RSA-SSA, 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)
Driver Architecture:
The ECC/RSA hardware encryption engine is a secure chip module dedicated to digital signature algorithms, implementing cryptographic operations directly through hardware circuits. It employs physical protection mechanisms to ensure key security and can improve computational efficiency compared to software solutions.
The ECC/RSA software is responsible for parsing upper-layer protocols and command scheduling, while the hardware layer completes core encryption computation tasks through specially designed circuits. The software layer architecture is shown in the following diagram:
Security Architecture:
The PKE engine supports TrustZone technology, capable of identifying whether the current CPU access is in Secure or Non-secure state. The PKE engine is equipped with a hardware mutex lock. Before each operation, the CPU needs to acquire the hardware mutex lock; otherwise, it cannot access the hardware registers. The mutex lock has two valid bits: if reading the mutex lock returns zero, then the lock is successfully acquired. When acquiring the lock, the hardware records whether the current access is Secure or Non-secure: 2’b01 for Secure lock, 2’b10 for Non-secure lock, write 0 to release the lock.
When the engine is locked in Secure mode, it blocks all Non-secure accesses. Only after the Secure CPU releases the lock can Non-secure access reacquire the lock. However, when the engine is locked in Non-secure mode, the Secure CPU can forcibly release the engine’s Non-secure lock status and reset the engine by configuring the Secure-only preemption register (PKE_MUTEX_OVERWRITE), thus preempting the use of the engine. Each time the engine releases the lock, all hardware and register states are cleared to ensure information is not leaked.
ECDSA OTP Keys
The ECDSA engine can download private keys in two ways:
Users pass the private key to the API, which then writes it into the ECDSA register.
ECDSA automatically downloads the ECDSA OTP key.
The OTP physical mapping can store two private keys for ECDSA use, which can only be accessed through ECDSA triggering and cannot be tampered with or read. The prerequisite is that the private keys need to be pre-burned into the OTP physical mapping.
OTP Key |
Address |
Size |
Default Value |
Description |
|---|---|---|---|---|
ECDSA_PRI_KEY1 |
Physical mapping 0x280 |
32 bytes |
0xFF each byte |
If OTPKEY=1, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY2 |
Physical mapping 0x2A0 |
32 bytes |
0xFF each byte |
If OTPKEY=2, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY1_Read_Protection |
Physical mapping 0x366[2] |
1 bit |
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 bit |
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 bit |
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 bit |
1 |
0: Enable ECDSA Key2 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key2 write protection |
The ECDSA engine can download private keys in two ways:
Users pass the private key to the API, which then writes it into the ECDSA register.
ECDSA automatically downloads the ECDSA OTP key.
The OTP physical mapping can store two private keys for ECDSA use, which can only be accessed through ECDSA triggering and cannot be tampered with or read. The prerequisite is that the private keys need to be pre-burned into the OTP physical mapping.
OTP Key |
Address |
Size |
Default Value |
Description |
|---|---|---|---|---|
ECDSA_PRI_KEY1 |
Physical mapping 0x280 |
32 bytes |
0xFF each byte |
If OTPKEY=1, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY2 |
Physical mapping 0x2A0 |
32 bytes |
0xFF each byte |
If OTPKEY=2, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY1_Read_Protection |
Physical mapping 0x366[2] |
1 bit |
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 bit |
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 bit |
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 bit |
1 |
0: Enable ECDSA Key2 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key2 write protection |
The ECDSA engine can download private keys in two ways:
Users pass the private key to the API, which then writes it into the ECDSA register.
ECDSA automatically downloads the ECDSA OTP key.
The OTP physical mapping can store two private keys for ECDSA use, which can only be accessed through ECDSA triggering and cannot be tampered with or read. The prerequisite is that the private keys need to be pre-burned into the OTP physical mapping.
OTP Key |
Address |
Size |
Default Value |
Description |
|---|---|---|---|---|
ECDSA_PRI_KEY1 |
Physical mapping 0x280 |
32 bytes |
0xFF each byte |
If OTPKEY=1, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY2 |
Physical mapping 0x2A0 |
32 bytes |
0xFF each byte |
If OTPKEY=2, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY1_Read_Protection |
Physical mapping 0x366[2] |
1 bit |
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 bit |
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 bit |
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 bit |
1 |
0: Enable ECDSA Key2 write protection, prohibit hackers from writing key to all 0s 1: Disable ECDSA Key2 write protection |
The ECDSA engine can download private keys in two ways:
Users pass the private key to the API, which then writes it into the ECDSA register.
ECDSA automatically downloads the ECDSA OTP key.
The OTP physical mapping can store two private keys for ECDSA use, which can only be accessed through ECDSA triggering and cannot be tampered with or read. The prerequisite is that the private keys need to be pre-burned into the OTP physical mapping.
OTP Key |
Address |
Size |
Default Value |
Description |
|---|---|---|---|---|
ECDSA_PRI_KEY1 |
Physical mapping 0x280 |
32 bytes |
0xFF for each byte |
If OTPKEY=1, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY2 |
Physical mapping 0x2A0 |
32 bytes |
0xFF for each byte |
If OTPKEY=2, load this key to ECDSA engine as private key |
ECDSA_PRI_KEY1_Read_Protection |
Physical mapping 0x366[2] |
1 bit |
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 bit |
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 bit |
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 bit |
1 |
0: Enable ECDSA Key2 write protection, prohibit hackers from writing the key to all 0s 1: Disable ECDSA Key2 write protection |
The PKE’s OTP key only supports ECDSA public key generation/signing. By default, the OTP Key can only be accessed in Secure mode. In Secure state, the pke_ecdsa_share_hw_key API can be called to set the OTP key to either shared or non-shared status.
PKE Key ID |
Key Type |
Length (bits) | OTP Address | Key Usage Permission |
Shared IP |
||
|---|---|---|---|---|---|
0 |
OTP |
256 |
0x280 |
Secure (default) / Non-secure |
PKE only |
1 |
OTP |
256 |
0x2A0 |
Secure (default) / Non-secure |
PKE only |
Usage
Hardware interface characteristics: Only supports Slave mode, connected to the CPU via APB bus.
Operation process:
CPU first acquires the mutex
Writes algorithm parameters to the engine storage unit
Sets the control register to select the operation mode
Enables the engine to start calculation
Polls the status register to monitor progress
Upon detecting the end flag
Reads the calculation result from the storage unit
Releases the mutex
Exception handling mechanism
Error identification
Status register contains error flag bits
Immediately terminates the process when an error is detected during polling
Error feedback
API returns predefined error codes (non-zero values)
Returns status code 0 for normal completion
API
Realtek provides low-level APIs, users do not need to concern themselves with specific register operation methods and processes. Additionally, for better adaptability, Realtek has integrated the hardware acceleration engine into the MbedTLS API. MbedTLS ECDSA API only supports Software keys. When using OTP keys, low-level APIs are required. Due to hardware limitations, Realtek has disabled MbedTLS support for the SECP521R1 curve. The following commonly used curve parameters are currently built into the ROM:
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