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?

[Turbo J]

AES ECB is a strict requirement for BTLE radio operation and thus cannot be restricted to the secure firmware.

Your best bet is to mess with the TF-M config until it no longer tries to access the ECB peripherial at all.

You would still have the ARM trustzone stuff in hardware that AFAIK does not depend on the ECB00 peripherial at all, but it may be slower than just running AES in software. Documentation should be on ARM.com website.