Protecting Keys, Debug Ports, and Device Identity

Follow each key to the place it is stored:

• The signing private key lives with the vendor, ideally in a hardware security module or at least a machine that does nothing else. It never goes into a device, a repository or a developer’s laptop. MCUboot ships a development key “widely distributed”, and its documentation says it “should never be used for production”; the same goes for TF-M’s default keys.
• The verification public key, or its hash, lives in the device. It is not secret, but it must be unchangeable (lesson 4).
• Symmetric keys (a MAC key, an image-decryption key, a key shared with a server) live in the device and must be secret. MCUboot’s encryption documentation puts the burden plainly: the manufacturer must ensure such a key is “not possible to extract”.

Design as if a determined attacker can read anything stored in a device they own. Then ask how many devices that one extraction exposes.

↑ This step uses the figure at the top of the page.

If a device must hold a symmetric secret, make it unique. A common way derives each device’s key from a master key and the device’s ID:

$$K_i = \mathrm{HMAC}(K_{\text{master}},\ \mathrm{ID}_i)$$

The device stores only $K_i$; the server stores only $K_{\text{master}}$ and recomputes $K_i$ when it needs it. Extracting $K_i$ compromises one device. The master key is now the crown jewel, kept where the signing key is kept. Signatures are better still where they fit: the device holds nothing that signs, so opening it yields nothing to forge with.

A serial number is an identifier: it says which device claims to be talking. Anyone who reads it can repeat it. The RP2040 has no on-chip ID at all; the pico-sdk’s pico_get_unique_board_id() returns the 64-bit ID of the external flash chip, useful to tell boards apart, but readable by any code and not a secret. The RP2350’s OTP separates a public 64-bit CHIPID from a private 128-bit per-device random number, RANDID.

An identity is proven, not stated: the device shows it holds a secret nobody else has, usually by signing a fresh challenge from the server with a per-device private key whose public half the server registered at manufacture. A device with a readable ID and no secret can be impersonated by anyone who has read the ID.

Inside the device, give each secret to as little code as possible:

• keep keys in memory that ordinary code cannot read: the RP2350 can lock OTP pages against Non-secure access, permanently, and TrustZone keeps Secure memory out of reach of Non-secure code;
• use keys through an API that never hands them out: a PSA Crypto key created without export permission is used by its ID (for example to verify a MAC) and its bytes never reach application code; MCUboot’s MCUBOOT_BUILTIN_KEY applies the same pattern to its (public) verification keys;
• compare MACs, hashes and passwords in constant time (lesson 2);
• never log, print or put keys in crash dumps.

A fleet of 10 000 devices; an attacker buys one and extracts its secrets.

• One shared HMAC key: the key verifies, and therefore forges, images for all 10 000.
• Per-device keys: for chip ID e6613852d34a2b19 and the demonstration master key in the figure, $K_i$ = HMAC-SHA-256(master, ID) begins b5acb064 2da62ea0. It forges images for exactly one device, the one already in the attacker’s hands.
• Signatures: the device holds a public key; nothing extracted can sign. 0 devices exposed.

Now suppose instead the vendor’s build server is breached. The shared key, the master key and the signing key each expose all 10 000 devices. Signatures recover best, provided the second signing key was held separately (offline or in a different HSM): devices provisioned with its hash (lesson 4) can revoke the stolen key and accept releases signed with the new one, without touching the hardware.