Key Derivation Process

To ensure application-layer keys, credentials, and other confidential or sensitive data can only be accessed by specific devices under defined states, Realtek Ameba series SoCs support unique binding through KDF. To prevent re-derivation of previously used keys, only trusted code can access all source data.

HUK derivation occurs in two phases:

• Boot ROM phase (blue section on left side of diagram) implemented by Realtek.

• Bootloader phase (gray section on right side) implemented by customers according to application requirements.

During Boot ROM phase key derivation, HUK is protected by the following measures against leakage:

• Reading HUK in RMA state returns all FF values, preventing RMA software from accessing customer-defined HUK. Effectively protects derived keys from leakage in RMA state.

• When customer-derived keys are compromised, data associated with these keys becomes vulnerable. Customers can update huk_epoch in manifest.json5 to re-derive new keys and migrate data using the new keys.

• HUK is only accessible during Secure CPU Boot ROM phase and cannot be read in subsequent phases.

All KDF inputs except HUK are known. If HUK is obtained at any stage, the entire key derivation process can be replicated, exposing all temporary keys. Therefore, HUK access must be prevented in subsequent phases.

At the end of the key derivation in the Secure CPU Boot ROM, the software writes the Sticky register bit to 1 to set the HUK to an unreadable state, preventing subsequent stages from reading the HUK. This Sticky bit can only be written to 1 and cannot be cleared to 0. It is only reset when the system resets or wakes from deep sleep.

HUK OTP

Secure CPU Boot ROM determines HUK derivation enablement through the HUK_DERIV_EN bit (physical address 0x369[2]) in physical OTP.

• Default state: SoC disables HUK derivation. The Sticky register bit is not written during boot, allowing immediate key readback after production programming to verify correctness.

  Recommendation: After confirming successful HUK programming, write 0 to HUK_DERIV_EN OTP bit.

• After enabling: When HUK derivation is enabled and SoC is reset, software writes the Sticky register bit during Boot ROM phase, making original HUK unreadable after Secure CPU Boot ROM exits.

Name	OTP Address	Size (bits)	Description
HUK	0x310~0x31F	128	Random seed written during device manufacturing, used for deriving all other keys and identifiers during the boot phase
HUK_W_Forbidden_EN	0x364[7]	1	Once burned, HUK cannot be modified
HUK_DERIV_EN	0x369[2]	1	HUK derivation enable

HUK Derivation Method

1. Configure huk_epoch in {SDK}\component\soc\amebaxxx\project\manifest.json5:

   img_id: 0,
   img_ver_major: 1,
   img_ver_minor: 1,
   huk_epoch: 1,
   

   Maximum length of 4 bytes for huk_epoch. Users can update huk_epoch to re-derive new keys as needed.

2. Program HUK-related OTP bits:

   Note

   CONFIG_ATCMD_SECURE must be enabled in menuconfig before using AT+SEC commands. Path: CONFIG SHELL → Enable ATCMD SECURE (disabled by default).

   1. Generate random seed and program:

      AT+SEC=HUK_KEY,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      

      The command automatically reads back and verifies the OTP after writing. If verification fails, an error message is returned. If HUK is correctly programmed, lock HUK write protection to prevent modification:

      AT+SEC=HUK_LOCK
      

   2. Enable HUK derivation:

      AT+SEC=HUK_EN
      

      Note: After enabling HUK derivation, no application software can read HUK.

3. Reset the device.

4. Obtain Boot ROM phase derived keys:

   Keys derived through Realtek KDF during Boot ROM phase can only be accessed via the DerivedKey array in trusted code. For security, all KDF-related data remains inaccessible to untrusted code. Users only need to declare a 16-byte external array in secure code (Secure CPU Bootloader or Image3):

   extern uint_8 DerivedKey[16];
   

5. Implement Bootloader phase key derivation:

   Customers can implement custom KDF or use Realtek-provided BOOT_ROM_KeyDeriveFunc to derive application keys in Secure CPU Bootloader. Use the DerivedKey from previous step as secret input. For example, one way to implement this derivation is to first combine the secret input with a specific label or context, and then processing the combined data with a hash algorithm (e.g., SHA2) to generate the application key. Hash algorithms provide security by not exposing the secret.