Hello Nordic engineers,
I maintain the lolren/nrf54-arduino-core project: a bare-metal Arduino core for nRF54 boards that deliberately avoids Zephyr and vendor RTOS dependencies. One current limitation is that secp256r1 ECC is software-only in my core because the nRF54L CRACEN PK path depends on Nordic-supplied microcode; as a result, Thread/Matter pairing is currently CPU-bound and significantly slower than it should be. I have been working from the public nRF54L15/L10/L05 datasheet and from the nRF Connect SDK CRACEN/KMU documentation and driver sources.
From the public documentation, my understanding is that on nRF54L15 / nRF54L10 / nRF54L05, CRACEN uses uploaded microcode for asymmetric operations, that the blob must be loaded into a special CRACEN RAM area after reset, and that Nordic’s current SDK copies a 5,120-byte ba414ep_ucode payload into a dedicated microcode address before calling sx_pk_init(). Public PK registers expose operand pointers, size fields, curve selection, endianness control, status/error reporting, and start/IRQ control, but the actual operation encoding and microcode contract are not documented publicly. A recent DevZone thread about PK.COMMAND.OPEADDR appears to confirm that this public documentation is incomplete for standalone bring-up.
I am not asking Nordic to open-source the existing proprietary microcode blob. I am asking whether Nordic can provide enough architectural and interface documentation to make a clean-room, open-source replacement feasible for the nRF54L CRACEN PK engine.
The specific questions I would appreciate help with are:
-
Microcode loader/interface contract
- What is the public, supported format of the CRACEN/PK microcode image, if any?
- Is the payload simply a raw instruction/data image copied to CRACEN RAM, or does it have a header, version field, checksum, or ABI/version handshake?
- What is the required memory layout, alignment, base address, size limit, and reset/power-cycle invalidation model for the uploaded image?
- Is there a documented way to detect “compatible microcode present” versus “missing/incompatible microcode”?
-
PK engine programming model
- What is the expected meaning/encoding of
PK.COMMAND.OPEADDR, and where is the complete operation map documented? - For each supported asymmetric primitive, what are the exact operand/result slot layouts expected by the PK engine or loaded microcode?
- Are there hidden or mandatory conventions for operand slots, auxiliary buffers, modulus staging, endianness, padding, or scratch space beyond what is visible in
PK.POINTERS,PK.COMMAND,PK.CONTROL, andPK.STATUS? - Are there example register sequences for at least P-256 ECDH, P-256 ECDSA verify, Ed25519 verify/sign, X25519, and any RSA operations that are expected to be supported on nRF54L?
- What is the expected meaning/encoding of
-
Security, timing, and side-channel expectations
- Which timing/side-channel properties are part of the required compatibility contract, versus properties of Nordic’s current internal implementation?
- Are there mandatory countermeasure settings or behaviours for PKE/IKG usage, given the documented protection against timing attacks/DPA and tamper-event handling?
- Should a compatible replacement reproduce the same
ERRORFLAGS,FAILPTR, zeroisation behaviour, and tamper behaviour, or is numeric correctness alone sufficient?
-
Validation and tooling
- Can Nordic provide a minimal set of authoritative test vectors and expected register/memory traces for one or two representative operations?
- Is there any recommended trace/debug tooling for CRACEN PK bring-up beyond the public nRF Connect SDK tooling and the standard debug stack?
- Are there existing public samples that exercise the PK path without going through the full PSA abstraction?
-
Licensing and redistribution
- Is a clean-room reimplementation of the externally visible CRACEN PK behaviour permitted, provided it does not copy Nordic’s distributed microcode blob or non-public sources?
- Are the instruction encoding, operation map, or other aspects of the microcode ABI considered confidential or third-party encumbered?
- If Nordic can document the interface, would redistribution of an independently implemented replacement for use on Nordic ICs be acceptable from Nordic’s perspective?
