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.

[Vidar Berg]

Yes, ECB00 has to be configured as non-secure because it is required by the bluetooth stack as Turbo here also pointed out, so it is not possible to make this peripheral only accessible from the secure processing environment, at least not with the current implementation.

In my first answer, I simply assumed you wanted this split because you were planning to use ECB00 in your application code, which is why I suggested using the PSA API instead, was this assumption wrong?

[shiroutosan]

Thank you for clarifying. Yes, that assumption was different from my intention. I am not asking how to perform an application-level AES operation. My concern is the general TrustZone security boundary around cryptographic keys.

The intended model is:

• Secure: sensitive key material, protected storage, and cryptographic services.
• Non-Secure: communication frontends and potentially untrusted protocol processing.

I understand that the current Non-Secure MPSL/SDC implementation requires direct ECB00 access. However, I would like to distinguish between protecting application keys and also protecting Bluetooth key material from compromised Non-Secure software.

Could you clarify:

1. Which Bluetooth keys or key material must be accessible to Non-Secure software in the current configuration?
2. Is there a supported configuration that keeps this key material and its cryptographic processing Secure while exposing only a bounded communication interface to a Non-Secure frontend?
3. If not, is this a limitation of the current MPSL/SDC implementation, or an architectural requirement of the hardware?

The current instantiation table lists ECB00 as user-selectable, so I am rechecking my earlier SPU attribution results rather than assuming a hardware-fixed restriction.

I use Rust/Embassy rather than TF-M. I recognize that any Secure service boundary must preserve the controller’s timing, IRQ, and DMA requirements. I am asking about the supported isolation model, not assuming that wrapping the public ECB API can redirect MPSL’s internal accesses.

Thank you.

[Vidar Berg]

I see, thanks for the clarification. bt keys such as the long term key (LTK) are currently stored in non-secure memory. The bt core spec. also requires this key to be passed to the controller as a parameter over HCI, so I'm not sure it's feasible to make it available only in the secure domain. Also, the AES CCM peripheral that encrypts the connection must be accessible from the softdevice controller in the non-secure domain. So at least currently it is not possible to get the isolation the isolation you are asking for. I think your best option is to add security at the application layer as needed, and not rely on this isolation for the bt transport.

[shiroutosan]

Thank you for the clarification.

My understanding is that the requested isolation is not supported by the current MPSL/SDC and Bluetooth host/controller integration, rather than being inherently prohibited by the hardware. There is currently no supported configuration that provides this security boundary.

I also understand that application-layer security is a separate mitigation, not a replacement for isolating Bluetooth key material.

Please correct me if I have misunderstood. If this understanding is correct, my question has been answered, and this case can be closed.

[Vidar Berg]

Yes, I think your understanding is correct.