Embedded Security In Practice: Enabling Authenticated Debug on FRDM-MCXN947

Embedded Security In Practice is a hands-on series that takes an NXP FRDM-MCXN947 development board from its wide-open factory state to a production-hardened one, one concrete security control at a time. Each control closes a specific risk that the automotive threat model built earlier in the series identified for this device. The board ships with its Serial Wire Debug (SWD) port fully open: anyone with a cheap SWD probe and physical access can halt the processor and read or rewrite the entire firmware. This post adds authenticated debug: the per-device credential and gating policy that turn that open port into one the ROM opens only for a valid credential signed by this board’s root of trust, while keeping a controlled, credentialed path back in for legitimate repair. What follows: building that credential chain, staging the gating policy, and verifying on the live board that the credential is correctly built and bound to this device. Making the silicon enforce it is the series-end lifecycle step.

At the beginning of this series we conducted a Threat Analysis and Risk Assessment (TARA) which flagged an unauthenticated debug port as TS3 and scored it Risk 3. Milestone 3 (M3), this post, closes that attack path. It provisions a per-device Debug Authentication (DAT) credential chain backed by the root of trust we established in M2, writes a gating policy into Customer Manufacturing Programmable Area (CMPA), and verifies the chain against the device’s live challenge. The correct credential matches this board field by field, a credential with the wrong Universally Unique Identifier (UUID) is refused, and the debug domains and the In-System Programming (ISP) path are staged to require authentication once the lifecycle is locked.

S/F/O/P: Safety / Financial / Operational / Privacy, the impact categories from the M1 TARA.

TS3’s concrete attack path (AP2 from M1): physical SWD access with the part in DEVELOP (the factory-default lifecycle state), a probe connects with no authentication challenge, dumps the full flash, and can write modified firmware. The same ROM commands are also reachable over the ISP path on CAN or USB-HID.

The series roadmap

The security control: a debug credential chain + CC_SOCU gating

Authenticated debug is the mitigation for TS3. The SWD port stays physically present on the board; what changes is what the ROM requires before it opens the debug domains. In DEVELOP state any probe gets in. Once the staged policy is enforced at the series-end lifecycle advance, the ROM issues a random challenge, waits for a response carrying a signed credential bound to this board’s UUID, and opens the domains only if that credential passes every check. A bench probe with no credential gets nothing.

Two parts implement this. The first is the credential chain: a per-device credential signed by RoTK2, one of the four root-of-trust keys provisioned in M2, binding the debugger’s key, the board UUID, and the permitted debug domains to one device. The second is the CC_SOCU gating policy staged in CMPA, which tells the ROM which domains require DAT and which stay fixed-open.

The credential chain

The credential chain reuses M2’s root of trust. RoTK2 is the debug Certificate Authority (CA). M2 assigned that role when it provisioned the Root of Trust Key Hash (ROTKH): the RoTK_USAGE field at 0x0100_4054 sets bits 8:6 to 001, “usable as debug CA only” (Security Reference Manual (SRM) Table 193). No new keys are created in this post.

The Debug Credential Key (DCK) is a fresh ECDSA P-384 keypair the debugger holds. Its private half answers the ROM’s challenge; its public half is pinned in the credential.

The Debug Credential (DC) ties everything together: signed by RoTK2, it carries the four root public keys (so the ROM can verify the ROTKH it holds), the DCK public key, a domain bitmask specifying which debug ports to open, and this board’s UUID. That UUID binding is what makes the credential per-device: it authenticates this board and no other.

The whole scheme is anchored by the ROTKH burned in M2. RoTK2 is one of the four roots and signs the DC, so a DC is only trusted if it was signed by a key whose public half is inside that ROTKH set. The DC delegates to the DCK by pinning the DCK public key inside itself. The DCK private key then proves possession at runtime by signing the answer to the ROM’s challenge.

A minted DC and its DCK form a standing key to the debug port. You want these short-lived. A leaked or over-issued credential can open any board it was bound to, for as long as it stays in circulation. Two properties already limit the damage: per-device UUID binding caps exposure to one board, and the ROM’s 32-byte random challenge means each authentication is a fresh exchange, so a captured response cannot be replayed. Short-lived issuance caps the exposure window. The NXP credential format has no expiry field the ROM enforces, so keeping credentials short-lived is a discipline on the signing service, not something the silicon does for you.

Four D-names do the work here, and two differ by one letter. The DC is the credential itself; the DCK is the keypair that answers for it. The DAC is the ROM’s challenge; the DAR is the debugger’s reply. Credential and its key, challenge and its reply.

The ROM issues a Debug Authentication Challenge (DAC) carrying a 32-byte random vector, the device’s SoC class (SOCC), and the board UUID. The debugger returns a Debug Authentication Response (DAR) with the DC plus an ECDSA signature over the DC and the challenge, computed by the DCK private key. On a locked part, the ROM then runs four checks. One: hash the root public keys in the DC and compare against the ROTKH. Two: verify the DC signature with RoTK2. Three: verify the DCK signature over the challenge. Four: check the DC’s UUID against the device’s. All four must pass before it opens the requested domains. In DEVELOP the ROM skips this validation entirely; the proof is in Load and test. The protocol version is DAT 2.1: P-384 and Secure Hash Algorithm 384-bit (SHA-384), following the ENF_CNSA=LIMITED_0B01 setting from M2, which pins the algorithm suite.

CC_SOCU gating staged in CMPA

There’s no single debug enable on this chip; CC_SOCU gates access by domain. Invasive debug (halt the core, read/write memory and registers) and non-invasive debug (trace and profiling) have separate gates. So do the secure and non-secure worlds, the second CPU, the DSP, and the command channels (ISP, fault analysis, mass erase).

Two CMPA registers implement the policy: CC_SOCU_PIN at 0x0100_4040 and CC_SOCU_DFLT at 0x0100_4044 (SRM Tables 229/230). CC_SOCU_PIN decides whether a domain is controlled by debug authentication or pinned to a fixed state; CC_SOCU_DFLT supplies that fixed value. Each subdomain gets two bits: PIN=0/DFLT=0 means the domain is off at startup but openable through a valid DC (SPSDK calls this USE_DAP); PIN=1/DFLT=1 means always enabled (FIXED_STATE/ENABLED). A separate non-secure pair in the Customer Field Programmable Area (CFPA), CC_SOCU_PIN_NS / CC_SOCU_DFLT_NS, handles non-secure debug gating (SRM Tables 229/230; not exercised this session).

About ME_CMD_EN: I staged it fixed-open this session because mass erase is a credential-free recovery path while the board is still in DEVELOP. A side capture from this session (m3-recovery-characterization) confirms it: cmd erase (the Debug Mailbox Access Port (DM-AP) mass-erase command) wiped CMPA back to all-0xFF with the ROTKH gone. That is why gating ISP_CMD_EN behind DAT is safe in this configuration: if the DAT gate ever locks you out of ISP, mass erase still recovers the board by wiping the CMPA policy itself.

That said, leaving mass erase credential-free is the wrong default for a shipped part. A credential-free mass erase is a denial-of-service on a fielded Body Control Module (BCM): an attacker who triggers it wipes the CMPA config and ROTKH without any signing key. No firmware is exposed, but the device loses its provisioned configuration. Return Merchandise Authorization (RMA) goes through an authenticated erase: the RMA facility holds a valid DC and can wipe the device; a random attacker cannot. ME_CMD_EN fixed-open is a DEVELOP-state convenience, not the intended shipped default.

So in the committed end-state, ME_CMD_EN joins the gated set: mass erase also requires a credential, and RMA goes through an authenticated erase. Advancing to IN_FIELD (the sealed production lifecycle state) physically enforces the whole staged policy. The pfr read capture below confirms representative bits (DBGEN, ME_CMD_EN, UUID_CHECK); the rest follow the same PIN/DFLT staging.

Build the debug credential and stage the gating policy

All tools: Secure Provisioning SDK (SPSDK) 3.10.0, family mcxn947. This session the ROM enumerated on USB-HID (1fc9:014f); the debug mailbox needed an explicit probe serial (-s JABXJL3CFXOL0) because the ROM’s USB composite device made the probe list ambiguous.

# 1. Generate the DCK (P-384)
nxpcrypto key generate -k secp384r1 -e pem -o provisioning/keys/dck_prv.pem

# 2. Read UUID; byte-reverse each word (raw: 0xc7a10066 0x5fb8b457 0x797af28a 0xa6665108; dc.yaml uuid: 6600a1c7 57b4b85f 8af27a79 085166a6)
blhost -u 0x1fc9:0x014f get-property 18

# 3. Build the DC (signed by RoTK2, bound to the UUID)
#    edit dc.yaml: rot_id 2, signer=rotk2_prv.pem, dck=dck_prv.pub,
#    rot_meta=four rotk*.pub, uuid=6600a1c757b4b85f8af27a79085166a6, cc_socu 0x0FFF
nxpdebugmbox dat dc get-template -f mcxn947 -o provisioning/configs/m3/dc.yaml
nxpdebugmbox dat dc export -c provisioning/configs/m3/dc.yaml \
  -o build/m3/dc.bin --force

# 4. Stage the M3 CMPA (additive to M2); read back saves the staged CMPA to build/m3/cmpa_staged.bin
pfr write -f mcxn947 -u 0x1fc9:0x014f -t cmpa \
  -c provisioning/configs/m3/cmpa.yaml
pfr read  -f mcxn947 -u 0x1fc9:0x014f -t cmpa -o build/m3/cmpa_staged.bin

# 5. Authenticate against the board
#    edit dat_auth.yaml: certificate=build/m3/dc.bin, signer=dck_prv.pem
nxpdebugmbox -i mcu-link -s JABXJL3CFXOL0 dat auth \
  -c provisioning/configs/m3/dat_auth.yaml

Two gotchas. First: cmd get-dac (the raw DAC-read subcommand) fails with a size mismatch until the ROTKH is staged. The DAC is sized to the configured root-key algorithm, so the CMPA write must come first. Second: dat dc export without --force aborts silently if the output file exists. I ran the full auth flow several times on a stale DC before the unchanged file timestamp told the story.

Load and test

Credential verified against the live challenge

dat auth -v ran the full exchange; the transcript shows the device’s live DAC and the field-by-field verify:

INFO:spsdk.apps.nxpdebugmbox:Starting Debug Authentication
INFO:spsdk.apps.nxpdebugmbox:DAC:
Version                : Version 2.1
SOCC                   : 0x00000007
UUID                   : 6600A1C757B4B85F8AF27A79085166A6
CC_VU                  : 0
ROTID_rkh_revocation   : 00000000
ROTID_rkth_hash        : 163e8d7af530ef8fcc69650f863c68ea5cf1b78e987becff02e3c8866564ecb3ed916096c606090c64f7f48144799b61
CC_soc_pinned          : 00000000
CC_soc_default         : 00000000
Challenge              : 18a28911cdda22551c0e32496806480750a5dbb5de0694c571a0f85dd2096724
============================================= DAC versus DC (Succeeded) ==============================================
  Protocol version(Succeeded): Version 2.1
  SOCC(Succeeded): 00000007
  UUID(Succeeded): 6600a1c757b4b85f8af27a79085166a6
  RoT Hash(Succeeded): 163e8d7af530ef8fcc69650f863c68ea5cf1b78e987becff02e3c8866564ecb3ed916096c606090c64f7f48144799b61
Testing AHB access (Press Ctrl+C to stop)
Debug Authentication ends successfully.

The “Testing AHB access” line is the probe exercising the on-chip bus, and in DEVELOP it passes regardless of the credential (debug is open by design), so it proves nothing here. The substance is above it: the DAC the device issued, and the verifier matching the credential against it field by field.

The DAC versus DC table confirmed every field: protocol 2.1, SOCC 00000007 (the board’s SoC class; the SRM template says 0x04 but the board’s device DB entry and the live capture both show 0x07), RoT hash 163e8d7a...799b61 (the same ROTKH M2 provisioned), and the UUID. Note CC_soc_pinned = 0 in the DAC even though the CMPA has the gating staged: the CC_SOCU policy is inert in DEVELOP.

This capture proves the credential is well-formed and matches this device, verified host-side against the live DAC. It does not prove the silicon validated the credential; that is shown two subsections down.

Wrong-UUID refused

I rebuilt the DC with the UUID off by one nibble (...66a6 to ...66a7), same RoTK2 signature:

SPSDKAppError: Debug Mailbox authentication failed:
SPSDK: DAR verify failed:
 =============================================== DAC versus DC (Error) ================================================
This is verifier of Debug Authentication Challenge against Debug Credential
======================================================================================================================
  Protocol version(Succeeded): Version 2.1
  SOCC(Succeeded): 00000007
  UUID(Error): Different DAC and DC UUID. DAC: 6600a1c757b4b85f8af27a79085166a6 DC:
               6600a1c757b4b85f8af27a79085166a7
  RoT Hash(Succeeded):
                       163e8d7af530ef8fcc69650f863c68ea5cf1b78e987becff02e3c8866564ecb3ed916096c606090c64f7f48144799b61

The UUID check is the only failure.

The dat auth command runs a DAC-versus-DC verifier that compares the UUID in the device’s DAC against the UUID in the presented DC. That is software-level enforcement: in DEVELOP the silicon does not independently enforce UUID_CHECK; the hardware layer (bit 15 of CC_SOCU_PIN) activates at IN_FIELD, where the ROM itself refuses a mismatched DC before the DAR proceeds. What this capture proves is that a credential minted for this board does not authenticate a different one, even with an identical RoTK2 signature.

Fleet-key blast radius in practical terms: a leaked debug key that is not UUID-bound exposes every unit; per-device binding limits the damage to one board at the cost of one DC per device at point of service.

Gating staged

pfr read after the CMPA write returned both milestones in one page:

    DBGEN: USE_DAP          (CC_SOCU_PIN: require DAT to open)
    ME_CMD_EN: FIXED_STATE  (CC_SOCU_PIN: always-enabled fixed state)
    UUID_CHECK: ENABLED
    DBGEN: DISABLED         (CC_SOCU_DFLT: off at startup)
    ME_CMD_EN: ENABLED      (CC_SOCU_DFLT: enabled)
    SEC_BOOT_EN: ECDSA_SIGNED
  ROTKH: 163E8D7AF530EF8FCC69650F863C68EA...799B61

SEC_BOOT_EN=ECDSA_SIGNED and the ROTKH are M2’s. The debug domains at USE_DAP and UUID_CHECK enabled are M3’s.

DEVELOP leaves debug open

After provisioning, pyocd reset -t cortex_m returned exit code 0: the core is reachable with no credential. That is not a misconfiguration. SRM Table 231 documents it explicitly: in DEVELOP state (LC_STATE 0x03), DBGEN and NIDEN are enabled regardless of the CC_SOCU setting. To check whether DEVELOP honors CC_SOCU at all, I did a throwaway write forcing DBGEN/NIDEN off (FIXED_STATE/DISABLED). The probe still reached the core.

The ROM is not validating the credential in DEVELOP either. I rebuilt the DC with one flipped byte in its RoTK2 signature and ran the same dat auth. It ended exactly like the correct one:

Testing AHB access (Press Ctrl+C to stop)
Debug Authentication ends successfully.

So a “successful” dat auth in DEVELOP proves the mailbox exchange and the host-side field match, not silicon credential validation. That is what makes the corrupted-signature run the clean proof: DEVELOP does not enforce, and the real test of the control is the locked part. The policy is provisioned and ready; the enforcement is lifecycle-deferred.

The risk after the control

TS3 drops from Risk 3 (Medium feasibility, no control) to Risk 2 (Low feasibility, credential chain and per-device binding proven). The committed end-state requires a valid DC signed by RoTK2 and bound to this board’s UUID before a probe gets in; what M3 proves reversibly is that the chain and the per-device binding work. Risk 2 is my scoring call in M1’s framework, not a board measurement.

The residual closes at the series-end capstone. Advancing the lifecycle to IN_FIELD (LC_STATE 0x0F, fuse-based, strictly one-way per SRM) activates the staged CC_SOCU policy. At that point the full physical demonstration becomes possible: a probe blocked without a credential, dat auth opening a session only after the ROM itself validates the RoTK2 credential, a wrong-UUID credential refused by the silicon rather than the host verifier, and ME_CMD_EN gated so mass erase also requires authentication. The capstone commits M2’s deferred One-Time Programmable (OTP) burn at the same time. Same commit-once posture as M2’s deferred fuse burn: prove everything in DEVELOP, commit once at the end.

Staged now, committed at the series end

The staged CMPA is saved by the readback (build/m3/cmpa_staged.bin); the board stays reversible in DEVELOP until the series-end capstone commits everything at once. shadowregs (SPSDK’s tool for emulating OTP fuse values in volatile shadow registers) does not support mcxn947 in SPSDK 3.10.0 (version-pinned), so there is no reversible way to emulate a locked state.

The pattern holds across M2 and M3: configure and prove each control in a reversible state, then commit the one-way steps at the end. Per-device UUID binding applies the same principle to the credential itself: a leaked debug key is limited to one board, not the fleet.

What’s next

M4 addresses TS4: key material extracted from the device. The RoT private keys (RoTK2 for debug authentication, RoTK0/RoTK1 for boot signing) live on the provisioning host. They have never been on the board; the board holds only the public ROTKH in CMPA. M4 is about the other category of key material: device-unique secrets the device itself stores and uses, derived from the SRAM Physical Unclonable Function (PUF) and managed inside the EdgeLock Secure Enclave (ELS S50). The design goal is that the application core never sees those keys in the clear and they cannot be dumped from flash.

Further reading

• M1: FRDM-MCXN947 TARA and lifecycle plan: TS3 at Risk 3, attack path AP2, and the full milestone map.
• M2: FRDM-MCXN947 secure boot: RoTK2’s debug CA role set in M2’s RoTK_USAGE; the ROTKH M3 verifies against is M2’s provisioned value.
• Embedded Security In Practice (Part 1): why debug lockdown exists and what “keep debug, behind a credential” means for production.
• NXP MCX Nx4x Security Reference Manual, Rev 5 (2025-05-19): Tables 227-231 (CC_SOCU encoding, lifecycle gates), 193 (RoTK_USAGE), 234/236 (DAT protocol, DAC/DAR field definitions).
• SPSDK 3.10.0 documentation (nxpdebugmbox) (SPSDK docs, archived): DAT subcommand family, dat dc export, dat auth.
• NXP AN13037 (AN13037, archived): DAT protocol and CC_SOCU_PIN/DFLT encoding background; written for LPC55Sxx but MCX inherits the scheme.

Acronyms