2385927_en-US

Yes

Importing a Wrapped Key Blob into ELS Using NXP_DIE_KEK_SK on RW612

Introduction

When provisioning secrets into an RW612 device, one common requirement is to securely load cryptographic keys without ever exposing the plaintext key material to application software.

The EdgeLock Secure Subsystem (ELS) provides a secure mechanism for accomplishing this by allowing a wrapped key blob to be imported directly into an ELS key slot. The wrapping key is derived from device-unique root material inside the secure enclave.

This article demonstrates how to:

Derive the die-specific NXP_DIE_KEK_SK
Import and unwrap the blob using ELS
Store the resulting key in an ELS keyslot
Remove temporary key material after provisioning

The imported key never exists in plaintext in application memory, significantly reducing the attack surface compared to software-based key management.

Understanding the Key Hierarchy

Before looking at the implementation, it is useful to understand the different keys involved.

NXP_DIE_MK_SK(NXP_DIE_INT_MK_SK)

This is the 256-bit die master key derived from UDF and PUF using the KEYPROV operation.

Characteristics:

Die unique
Not exportable
Used as a root-of-trust
Occupies key slot 0 on RW612

The key is loaded via dedicated secret key bus from PUF into ELS and XOR with a UDF derived key using KEYPROV, where it is used as a main key for further derivation of all remaining keys used by ROM. Applications never directly access the key material.

NXP_DIE_KEK_SK

This 256-bit key is derived from the master key using CKDF. It used for the wrapping of RFC3394 blobs stored in the OTP fuse region.

Purpose:

Acts as a Key Encryption Key (KEK)
Used only for wrapping or unwrapping other keys
Can be generated dynamically when needed

In this example the KEK is stored temporarily in key slot 5.

Imported Key

The final key imported from the wrapped blob depends on how the blob was originally generated using the HSM provisioning flow (for example, via HSM_STORE_KEY and later loaded with loadkeyblob).

The imported key may represent a customer-defined security asset such as:

Customer master key (CUST_CKDFK_FLAG)
HKDF master key (CUST_HKDFK_FLAG)
HMAC key (CUST_HMACK_FLAG)
CMAC key (CUST_CMACK_FLAG)
AES key (CUST_AESK_FLAG)
Key unwrap-only key (CUST_KUOK_FLAG)

Regardless of the key type, the import process remains the same. The key material is never exposed to application software during this process. Once imported, the key can be used directly by ELS for the cryptographic operations associated with its intended purpose, while remaining protected within the secure subsystem.

Prerequisites

FRDM-RW612
Key blob wrapped using RFC3394 format using HSM_STORE_KEY
Key blob programmed to OTP fuses using LoadKeyBlob command.

Required Headers:

#include "mcux_els.h"
#include "mcuxClEls.h"
#include "mcux_pkc.h"
#include "fsl_romapi_otp.h"

Step 1 – Derive NXP_DIE_KEK_SK

The wrapped blob is protected using a Key Encryption Key (KEK).

On RW612, the KEK can be derived from the device master key (NXP_DIE_MK_SK) using the official recipe constants.

The derivation operation uses masterKeyIdx = 0; which corresponds to NXP_DIE_MK_SK and produces a new key in the target slot.

Example:

static const uint8_t derivation_data[12] =
{
    0x94, 0xbe, 0x03, 0xac,
    0x8b, 0x59, 0x32, 0x45,
    0x11, 0x7f, 0xf8, 0x3f
};

mcuxClEls_Ckdf_Sp800108_Async(
        masterKeyIdx,
        target_slot,
        targetKeyProperties,
        derivation_data);

Wait for completion:

mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR);

Verify that the derived key slot becomes active before proceeding.

Step 2 – Retrieve the Wrapped Blob

The example reads the blob directly from OTP memory.

otp_fuse_read(starting_fuse_index + i, &fuse_word);

Each fuse word contains four bytes.

These words are assembled into a contiguous buffer:

blob_data[i * 4 + 0] = (fuse_word >> 0)  & 0xFF;
blob_data[i * 4 + 1] = (fuse_word >> 8)  & 0xFF;
blob_data[i * 4 + 2] = (fuse_word >> 16) & 0xFF;
blob_data[i * 4 + 3] = (fuse_word >> 24) & 0xFF;

The resulting buffer contains the RFC3394 wrapped key.

Step 3 – Import and Unwrap the Blob

Once the KEK exists and the blob has been retrieved, the import operation can begin.

Configure ELS for RFC3394 import:

mcuxClEls_KeyImportOption_t options;

options.word.value = 0;
options.bits.kfmt =
        MCUXCLELS_KEYIMPORT_KFMT_RFC3394;

Perform the import:

mcuxClEls_KeyImport_Async(
        options,
        blob_data,
        blob_length,
        kek_slot,
        target_slot);

Parameters:

Parameter	Purpose
blob_data	Wrapped key blob
blob_length	Blob size
kek_slot	Slot containing NXP_DIE_KEK_SK
target_slot	Destination keyslot

Wait for completion:

mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR);

If successful, ELS unwraps the blob internally and places the resulting key into the destination key slot.

No plaintext key material is exposed to software.

Step 4 – Clean Up Temporary KEK

After the blob has been imported, delete the temporary KEK:

mcuxClEls_KeyDelete_Async(kek_slot);

mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR);

This leaves only the imported key resident inside ELS.

Next Steps

At this point, the wrapped key blob has been successfully imported into the target ELS key slot, and the temporary NXP_DIE_KEK_SK has been removed. The imported key is now available for use by ELS-protected cryptographic operations without exposing the underlying key material to application software.

The next step is to validate the imported key by performing the operation it was provisioned for. Depending on the key type, this may include:

AES encryption or decryption operations
HMAC generation or verification
CMAC generation or verification
HKDF-based key derivation
Importing or unwrapping additional key material
Secure firmware or data encryption workflows

A successful cryptographic operation confirms that:

The blob was read correctly from storage.
The NXP_DIE_KEK_SK derivation completed successfully.
The RFC3394 unwrap operation succeeded.
The key was installed into the intended ELS keyslot with the expected properties.

For production deployments, this import mechanism provides a secure method for provisioning customer keys generated with the HSM tooling while ensuring that plaintext key material never leaves the ELS security boundary.