Hello Nordic team,
I am evaluating a TrustZone design on nRF54L15.
Intended security boundary
- Secure
- CRACEN and ECB00
- RRAMC, credential/PIN storage
- CTAP/FIDO core - Non-Secure
- BLE application / GATT frontend
- Untrusted protocol parsing
Observed behavior
I first tried running MPSL/SDC, RADIO-related resources, and GATT in the
Non-Secure image while keeping the CTAP core and ECB00 Secure.
The Non-Secure image reaches MPSL initialization, then faults on a direct
ECB00 access:
CFSR: 0x00008200 BFAR: 0x40047004 Access: ECB00 TASKS_STARTECB
I also wrapped the public
`mpsl_ecb_block_encrypt_extended()` API and forwarded it through a bounded NSC
gateway to a Secure CRACEN AES-ECB service.
- The Secure service and AES-ECB known-answer test succeeded.
- However, MPSL later accessed ECB00 directly during its private initialization
path and faulted before BLE GATT started.
Questions
1. Is there a supported configuration where MPSL/SDC, RADIO, ECB00,
timing, IRQ, and DMA remain Secure, while a BLE application or GATT frontend
runs Non-Secure?
2. If so, is there a documented IPC, NSC, or other integration boundary for:
- initialization
- callbacks
- IRQ ownership
- DMA buffers
- GATT traffic
3. If not, is the experimental nRF54L Non-Secure SDC mode expected to
require ECB00 to be Non-Secure as well?
4. Is there an official MPSL variant, source-level rebuild path, or supported
crypto-backend injection point that can redirect all ECB use, including
private MPSL initialization, to a Secure service?
I am not looking for a binary patch or an undocumented workaround. I would like
to understand the supported security boundary and decide whether this design
should remain pending.
Thank you.
