nRF54L15 TrustZone: supported MPSL/SDC placement with a Non-Secure BLE frontend?

[shiroutosan]

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.

[Vidar Berg]

Hello,

The MPSL/SDC restricts access to the ECB peripheral (Ref. https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrfxlib/mpsl/doc/mpsl.html) and it expects it to be directly accessible in the non-secure processing environment (i.e. not via a secure service). However, CRACEN is also providing AES ECB and this is already exposed via a secure service through the PSA API if you build TF-M with these crypto services enabled, so I would recommend using this instead.

Some additional documentation links for reference:

- https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/security/crypto/crypto_supported_features.html#cipher-modes 

- https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/security/tfm/tfm_services.html#crypto-service

Best regards,

Vidar

[shiroutosan]

Thank you, this clarifies the intended use of the TF-M PSA Crypto service.

To make sure I understand the boundary correctly, my intended design is:

•  Secure: CTAP/FIDO core, credential and PIN storage, CRACEN, and ECB00
•  Non-Secure: BLE GATT/FIDO frontend, MPSL/SDC, and the BLE controller runtime

The problem is not an application-level AES-ECB call that I can redirect to
PSA. In my test, the Non-Secure MPSL/SDC initialization itself accesses the
Non-Secure ECB00 alias directly (`0x40047004`, `TASKS_STARTECB`). This happens
inside the prebuilt MPSL implementation, before the GATT frontend starts.

I verified that a bounded NSC gateway to a Secure CRACEN AES-ECB service works
for an explicit application call. However, it cannot intercept or replace the
private direct ECB00 accesses made internally by MPSL/SDC.

Therefore, using the PSA Crypto service for application crypto does
not by itself permit this split: ECB00 remains Secure, while MPSL/SDC and the
BLE controller run Non-Secure.

Is this interpretation correct? If so, is there any supported MPSL/SDC
configuration or integration model for this boundary, or should this design
remain pending?