Request for documented CRACEN/PK microcode interface for a clean-room open-source implementation on nRF54L

[Lolren]

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, and PK.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? 

• 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?