Provisioning PSK at Manufacturing

RE: Provisioning PSK at Manufacturing

hugzy123 — Tue, 22 Jul 2025 08:13:55 GMT

Thanks for the detailed explanation. This looks like it could fit our needs, I'll investigate the TF-M provisioning approach you've outlined.

RE: Provisioning PSK at Manufacturing

Susheel Nuguru — Tue, 22 Jul 2025 06:48:57 GMT

I am not an expert in this but think of your device’s KMU slots like a locked safe that you load up during manufacturing. When you run the TF-M provisioning image, it puts your Pre-Shared Key into that safe, and as long as you only flash your application code afterward without doing a full chip erase, everything inside the safe stays right where it belongs. Means, you can update your app as often as you like and the KMU will still hold your key properly.

Behind the scenes, TF-M’s psa_import_key() call doesn’t just scribble your key onto flash; it tucks it away in Internal Trusted Storage (ITS) and then scrambles it with a Master Key Encryption Key (MKEK) that lives in the KMU. From your application’s point of view, it simply asks “Hey TF-M, give me handle #42” using psa_open_key(), and TF-M hands back a ticket to use the key without ever exposing your raw secret to the non-secure world. You get persistence across resets and firmware updates, plus hardware-backed confidentiality, all in one neat package.

So at manufacturing you flash the provisioning image, feed it your PSK over UART or J-Link, let it import and encrypt your key behind TF-M, and then switch over to your regular firmware. From there on out, your app just opens the key handle whenever it needs to generate tokens or signatures, no MPU hacks, no UICR gymnastics, and no chance of accidentally wiping out that crucial secret. Your PSK stays secure yet always available for your authentication flows.

RE: Provisioning PSK at Manufacturing

hugzy123 — Wed, 16 Jul 2025 09:24:57 GMT

Hi Susheel,

Thanks for your reply.

If I understand correctly you're saying to implement something like provisioning image example and use a secure channel e.g UART connected to PC to receive the keys and then store the keys using the PSA crypto library. This provisioning image would be flashed before my application binary at manufacturing.

Won't the KMU be overwritten when I flash the application binary after the TF-M provisioning image?

When calling psa_import_key, is the key stored in persistent storage?

RE: Provisioning PSK at Manufacturing

Susheel Nuguru — Wed, 16 Jul 2025 06:00:55 GMT

Hi Benjamin,

The only supportable way to factory-provision per-device PSKs on nRF53 + TF-M is to use the TF-M provisioning image (psa_import_key over a secure channel) and then access them at runtime via the PSA Crypto API. All other hacks/workarounds like UICR, raw KMU writes from NS are either blocked by the MPU or leave you without a PSA handle. If you truely must use the KMU directly (which we do not recommend) then you still need a secure shim that calls psa_set_key_policy() and psa_import_key into that slot. Bypassing the TF-M provisioning image just moves the complexity into your own secure code.

RE: Provisioning PSK at Manufacturing

hugzy123 — Thu, 10 Jul 2025 09:13:16 GMT

Hi Andreas,

I did look at HUK but thought it was unsuitable for our functionality - the PSK needs to fed into the device from an external PC (via Jlink) and also saved in our cloud for future device verification.

Are we able to write directly to the KMU from the PC and read in application code?

I've tried adapting the persistent key usage sample to "open" an existing key instead of generating new and writing the key using memwr commands in nrfjprog but psa_open_key fails.

Thanks,

RE: Provisioning PSK at Manufacturing

AHaug — Wed, 09 Jul 2025 12:49:04 GMT

Hello,

For NCS v2.5.3, the secure and recommended method is to use the TF-M provisioning image to inject PSKs and other secrets into secure storage at manufacturing time, disable dummy provisioning, and use the PSA Crypto API for all key access. This ensures that PSKs are never exposed outside the secure environment and are protected throughout the device lifecycle. This should set the HUK properly.

If you need step-by-step details, refer to the TF-M provisioning documentation and the TF-M: Provisioning image sample.

Kind regards,
Andreas