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.
查看全文
