Symmetric Encryption Engine

AES Engine

The AES engine encrypts or decrypts data according to the Advanced Encryption Standard (AES) defined by NIST, supporting automatic message padding. It supports both software register keys and hardware OTP keys. Hardware encryption/decryption reduces software overhead, lowers CPU and memory resource consumption, and operates faster and more securely than software implementations.

AES Algorithm Support

Supported key sizes: AES-128, AES-192, AES-256

  • Supported encryption/decryption modes:

    • ECB (Electronic Codebook)

    • CBC (Cipher Block Chaining)

    • OFB (Output Feedback)

    • CFB (Cipher Feedback)

    • CTR (Counter)

    • GCM (Galois/Counter)

AES Keys

The AES engine features an independent key management unit. This unit supports both software keys and hardware OTP keys.

The hardware encryption engine provides two key loading methods:

  • Software transfer: Keys are dynamically passed in by the application (software accessible)

  • OTP automatic loading: Keys are pre-burned into the OTP physical storage area (not accessible by software, only accessible by the encryption engine, preventing tampering or reading)

The OTP physical storage area supports storing 6 sets of keys, which need to be burned through the efuse command.

Engine Type

Security

Key Index

OTP Key

AES

Secure

0

S_IPSEC_Key1

AES

Secure

1

S_IPSEC_Key2

AES

Secure

2

RSIP_AES_Key1

AES

Secure

3

RSIP_AES_Key2

AES

Non-secure

0

NS_IPSEC_Key1

AES

Non-secure

1

NS_IPSEC_Key2

AES

Non-secure

2

RSIP_AES_Key1

AES

Non-secure

3

RSIP_AES_Key2

The detailed functions of OTP keys are shown below:

OTP Key Name

Address

Size bits

Default Value

Description

S_IPSEC_Key1 (RDP)

Logical map 0x200

256

0xFF

When OTPKey_init function is enabled, the secure

encryption engine will automatically load this key for HMAC or AES algorithm

S_IPSEC_Key2

(Secure boot HMAC)

Logical map 0x220

256

0xFF

RSIP_AES_Key1

Logical map 0x2c0

256

0xFF

When OTPKey_init function is enabled, non-secure AES

engine and secure AES engine will automatically load this key for AES algorithm

RSIP_AES_Key2

Logical map 0x2e0

256

0xFF

S_IPSEC_Key1_Read_Protection

Physical map 0x365[3]

1

1

0: Enable S_IPSEC_Key1 read protection, prohibit key from being read

1: Disable S_IPSEC_Key1 read protection

S_IPSEC_Key1_Write_Protection

Physical map 0x365[4]

1

1

0: Enable S_IPSEC_Key1 write protection, prohibit key from being written to all 0s by hackers

1: Disable S_IPSEC_Key1 write protection

S_IPSEC_Key2_Read_Protection

Physical map 0x365[5]

1

1

0: Enable S_IPSEC_Key2 read protection, prohibit key from being read

1: Disable S_IPSEC_Key2 read protection

S_IPSEC_Key2_Write_Protection

Physical map 0x365[6]

1

1

0: Enable S_IPSEC_Key2 write protection, prohibit key from being written to all 0s by hackers

1: Disable S_IPSEC_Key2 write protection

RSIP_AES_Key1_Read_Protection

Physical map 0x366[7]

1

1

0: Enable RSIP_AES_Key1 read protection, prohibit key from being read

1: Disable RSIP_AES_Key1 read protection

RSIP_AES_Key1_Write_Protection

Physical map 0x367[0]

1

1

0: Enable RSIP_AES_Key1 write protection, prohibit key from being written to all 0s by hackers

1: Disable RSIP_AES_Key1 write protection

RSIP_AES_Key2_Read_Protection

Physical map 0x367[1]

1

1

0: Enable RSIP_AES_Key2 read protection, prohibit key from being read

1: Disable RSIP_AES_Key2 read protection

RSIP_AES_Key2_Write_Protection

Physical map 0x367[2]

1

1

0: Enable RSIP_AES_Key2 write protection, prohibit key from being written to all 0s by hackers

1: Disable RSIP_AES_Key2 write protection

AES Engine Security

The AES architecture achieves efficient encryption processing while ensuring security through hardware-level isolation and intelligent arbitration:

  • Two independent register sets:

    • Secure address space: 0x5XXX_XXXX, mapped to secure-dedicated registers

    • Non-secure address space: 0x4XXX_XXXX, mapped to non-secure-dedicated registers

  • Arbitration mechanism when both secure and non-secure domains request the encryption engine simultaneously:

    • Basic policy: Round-robin scheduling + FIFO status priority (full FIFO has priority)

    • Atomicity guarantee: Must complete an entire round of encryption operation (LS=1) before switching engine control

  • Interrupt mechanism:

    • Physical isolation design: Secure and non-secure interrupts are connected to different interrupt numbers

    • Error isolation reporting: Bus errors trigger both interrupts simultaneously, but need to be cleared independently

    • Special setting: Interrupt security attributes only support automatic hardware switching

AES Engine Usage Modes

DMA Mode

../../_images/crypto_legacy_block_diag_aes.svg

The AES engine uses DMA to move data between memory and fifo, and encrypts/decrypts data during the transfer process. DMA mode has high encryption/decryption efficiency for large amounts of data. However, DMA mode requires that the address and length of the data are aligned to the cache line length (32 bytes), otherwise there will be cache line data mismatch issues. If the address and length are not aligned, the serial port log will print a warning message. The driver has already handled the cache clean operation for the source address and cache invalidate operation for the destination address, so users do not need to clean the cache again outside the API.

AES API

Realtek provides ROM APIs, eliminating the need for users to manage specific register operations and processes. For enhanced applicability, the AES hardware acceleration engine has been integrated into MbedTLS. Due to hardware/software limitations, Realtek has not implemented hardware acceleration for MbedTLS’s CMAC/AES-GCM algorithms. Users can directly invoke ROM APIs during CMAC/AES-GCM operations for superior performance. Note that MbedTLS APIs only support software keys; ROM APIs must be used when employing OTP keys.

HMAC Engine

The HMAC engine is a hardware accelerator for computing HMAC and SHA2, supporting automatic message padding. The HMAC algorithm supports both software register keys and hardware OTP keys.

HMAC Algorithm Support

General Hash Functions:

  • SHA2-224

  • SHA2-256

  • SHA2-384

  • SHA2-512

HMAC (Hash-based Message Authentication Code):

  • HMAC_SHA2-224

  • HMAC_SHA2-256

  • HMAC_SHA2-384

  • HMAC_SHA2-512

HMAC Keys

The HMAC engine features an independent key management unit supporting both software keys and hardware OTP keys.

The hardware encryption engine provides two key loading methods:

  • Software transfer: Keys are dynamically passed in by the application (software accessible)

  • OTP automatic loading: Keys are pre-burned into the OTP physical storage area (not accessible by software, only accessible by the encryption engine, preventing tampering or reading)

The OTP physical storage area supports storing 6 sets of keys, which need to be burned through the efuse command.

Engine Type

Security

Key Index

OTP Key

SHA HMAC

Secure

0

S_IPSEC_Key1

SHA HMAC

Secure

1

S_IPSEC_Key2

SHA HMAC

Non-secure

0

NS_IPSEC_Key1

SHA HMAC

Non-secure

1

NS_IPSEC_Key2

The detailed functions of OTP keys are shown below:

OTP Key Name

Address

Size bits

Default Value

Description

S_IPSEC_Key1 (RDP)

Logical map 0x200

256

0xFF

When OTPKey_init function is enabled, the secure encryption engine will automatically load this key

for HMAC or AES algorithm

S_IPSEC_Key2

(Secure boot HMAC)

Logical map 0x220

256

0xFF

NS_IPSEC_Key1

Logical map 0x240

256

0xFF

When OTPKey_init function is enabled, the non-secure encryption engine will automatically load this key

for HMAC algorithm

NS_IPSEC_Key2

Logical map 0x260

256

0xFF

S_IPSEC_Key1_Read_Protection

Physical map 0x365[3]

1

1

0: Enable S_IPSEC_Key1 read protection, prohibit key from being read

1: Disable S_IPSEC_Key1 read protection

S_IPSEC_Key1_Write_Protection

Physical map 0x365[4]

1

1

0: Enable S_IPSEC_Key1 write protection, prohibit key from being written to all 0s by hackers

1: Disable S_IPSEC_Key1 write protection

S_IPSEC_Key2_Read_Protection

Physical map 0x365[5]

1

1

0: Enable S_IPSEC_Key2 read protection, prohibit key from being read

1: Disable S_IPSEC_Key2 read protection

S_IPSEC_Key2_Write_Protection

Physical map 0x365[6]

1

1

0: Enable S_IPSEC_Key2 write protection, prohibit key from being written to all 0s by hackers

1: Disable S_IPSEC_Key2 write protection

NS_IPSEC_Key1_Read_Protection

Physical map 0x365[7]

1

1

0: Enable NS_IPSEC_Key1 read protection, prohibit key from being read

1: Disable NS_IPSEC_Key1 read protection

NS_IPSEC_Key1_Write_Protection

Physical map 0x366[0]

1

1

0: Enable NS_IPSEC_Key1 write protection, prohibit key from being written to all 0s by hackers

1: Disable NS_IPSEC_Key1 write protection

NS_IPSEC_Key2_Read_Protection

Physical map 0x366[1]

1

1

0: Enable NS_IPSEC_Key2 read protection, prohibit key from being read

1: Disable NS_IPSEC_Key2 read protection

NS_IPSEC_Key2_Write_Protection

Physical map 0x366[2]

1

1

0: Enable NS_IPSEC_Key2 write protection, prohibit key from being written to all 0s by hackers

1: Disable NS_IPSEC_Key2 write protection

HMAC Engine Security

The HASH architecture achieves efficient encryption processing while ensuring security through hardware-level isolation and intelligent arbitration:

  • Two independent register sets:

    • Secure address space: 0x5XXX_XXXX, mapped to secure-dedicated registers

    • Non-secure address space: 0x4XXX_XXXX, mapped to non-secure-dedicated registers

  • Arbitration mechanism when both secure and non-secure domains request the encryption engine simultaneously:

    • Basic policy: Round-robin scheduling + FIFO status priority (full FIFO has priority)

    • Atomicity guarantee: Must complete an entire round of encryption operation (LS=1) before switching engine control

  • Interrupt mechanism:

    • Physical isolation design: Secure and non-secure interrupts are connected to different interrupt numbers

    • Error isolation reporting: Bus errors trigger both interrupts simultaneously, but need to be cleared independently

    • Special setting: Interrupt security attributes only support automatic hardware switching

HMAC Engine Usage Modes

DMA Mode

../../_images/crypto_legacy_block_diag_hmac.svg

The HASH engine uses DMA to move data between memory and fifo, and uses HMAC to encrypt/decrypt data during the transfer process. DMA mode has high encryption/decryption efficiency for large amounts of data. However, DMA mode requires that the address and length of the data are aligned to the cache line length (32 bytes), otherwise there will be cache line data mismatch issues. If the address and length are not aligned, the serial port log will print a warning message. The driver has already handled the cache clean operation for the source address and cache invalidate operation for the destination address, so users do not need to clean the cache again outside the API.

HMAC API

Realtek provides low-level HMAC APIs, freeing users from managing specific register operations and processes. For broader applicability, the SHA2 hardware acceleration engine has been integrated into MbedTLS SHA2-Hash/HMAC APIs. Other hash algorithms (e.g., SHA1/MD5) lack hardware acceleration. MbedTLS APIs only support software keys and require low-level APIs for OTP key usage. Additionally, MbedTLS APIs do not support DMA copy mode.

Crypto Key Byte Order

The Crypto Engine key byte order is consistent with MbedTLS data structures, both adopting little-endian byte order. The following example uses a 256-bit key to illustrate the correct byte order for converting from a readable hexadecimal string to an array and programming it into OTP.

Example Key

Original key (hexadecimal large number representation):

0x0123456789abcdef0123456789abcdef00112233445566778899aabbccddeeff

Key Array Definition

When passing the key as a byte array to the hardware API in a program, it must be arranged in little-endian order. Example array for 32 bytes:

/* 256-bit key, little-endian byte order */
uint8_t key1[32] = {
   0xff, 0xee, 0xdd, 0xcc, 0xbb, 0xaa, 0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x00,
   0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01
};

OTP Key Programming Flow

The following example uses NS_SHA_key2: First generate a little-endian ordered key, then use the AT+OTP=RRAW serial programming command to write to OTP physical address 0x260 (length 0x20, 32 bytes):

AT+OTP=WRAW,0x260,0x20,ffeeddccbbaa99887766554433221100efcdab8967452301efcdab8967452301

In mass production, after the key is written, key read protection and write protection must be enabled according to the OTP table descriptions to prevent OTP keys from being tampered with or leaked.

Note

  • The above example uses a 32-byte NS_SHA_key2 key; actual address and length should be adjusted according to actual needs.

  • Note that after OTP programming and system reset, the OTP key can be loaded into the engine.

  • This byte order rule applies to all IC models.

OTP Key Content Mapping

The actual content in the OTP physical address section after writing the above command:

OTP Content (0x260 ~ 0x27F)

Address

b0

b1

b2

b3

b4

b5

b6

b7

b8

b9

b10

b11

b12

b13

b14

b15

0x260

ff

ee

dd

cc

bb

aa

99

88

77

66

55

44

33

22

11

00

0x270

ef

cd

ab

89

67

45

23

01

ef

cd

ab

89

67

45

23

01