cpu/nrf9160dk Arm TrustZone-M support by janthies · Pull Request #22387 · RIOT-OS/RIOT

janthies · 2026-06-16T14:27:45Z

Contribution description

This PR adds an ARM TrustZone-M TEE (Trusted Execution Environment) as the backend for PSA Crypto

Cryptographic operations using PSA Crypto are funneled to the TEE so that cryptographic material like keys can stay hidden from the non secure world / application.

Parts of RIOT involved:

sys/psa_crypto — sealed-key location/type, a custom-random hook, AES-ECB
support, and location/algorithm dispatch to the cryptoservice backend.
pkg/cryptoservice, pkg/riot-tee, pkg/tf-m — the secure-world CryptoService,
the RIOT-TEE secure image, and the Trusted Firmware-M / cc3xx driver sources.
cpu/nrf9160, cpu/nrf5x_common, cpu/cortexm_common — non-secure peripheral
selection via a new NRF_TRUSTZONE_NONSECURE compile macro, and TrustZone-M
build support.
boards/nrf9160dk-ns — new board target for the non-secure image.
tests/sys/psa_riot_tee — unit tests exercising the TEE-backed PSA operations.

The initial implementation was done by Lena Boeckmann back in 2024. Lenas masters thesis explains a lot of the architectural work: https://inet.haw-hamburg.de/thesis/completed/ma_lena_boeckmann.pdf/view. I've picked up the stale work in early 2026 and have fixed "some details".

Some open issues are that the CryptoService API (PSA Crypto API backend) (authored by Lars Pfau) hasn't yet been merged into RIOT. As a workaround for now (with agreement from Thomas Schmidt and Lars), I'm providing a temporary version of CryptoService on my GitHub.

The idea was to check in whether this is actually something belonging into riot and to gauge how much more work needs to be poured into this.

Testing procedure

I have an nrf9160-DK board. Running the tests/sys/psa_riot_tee test results in 5 Tests passed. The tests cover key import / sign/verify, sealed key generation + sign/verify, AES-128 CBC/ECV round trips and SHA-256

Issues/PRs references

None

Declaration of AI-Tools / LLMs usage:

I've used claude code
I'm not aware of any AI usage in the commits by Lena Boeckmann.
I myself have used Claude (Opus 4.6 - 4.8) sparingly in the commits in march. Mostly as a sparing partner / for more quickly understanding the architecute.
Before opening the pull request i've let Claude Code (max effort) check the commits for any glaring problems. That's how the commits from 16th June 2026 have come up. Those commits were created in agent mode.

riot-ci · 2026-06-16T14:29:37Z

Murdock results

❌ FAILED

c35dbea treewide: use SPDX license headers for nRF9160 TEE files

Artifacts

AnnsAnns

Hello, thank you for your first PR to RIOT, we always welcome new people (esp. if they PR 2 years of work cough)

Please try to rebase your branch onto the newest RIOT as right now this will not pass Murdock (and I am guessing a lot has happened over that time).

crasbe

Thank you for the PR, @AnnsAnns asked us to give a review.

First there are some code style aspects.

crasbe · 2026-06-16T15:08:56Z

+/*
+ * Copyright (C) 2021 Mesotic SAS
+ *
+ * This file is subject to the terms and conditions of the GNU Lesser
+ * General Public License v2.1. See the file LICENSE in the top level
+ * directory for more details.
+ */


Suggested change

/*

* Copyright (C) 2021 Mesotic SAS

*

* This file is subject to the terms and conditions of the GNU Lesser

* General Public License v2.1. See the file LICENSE in the top level

* directory for more details.

*/

/*

* SPDX-FileCopyrightText: 2021 Mesotic SAS

* SPDX-License-Identifier: LGPL-2.1-only

*/

The copyright headers should have the SPDX format, see #21515 for more information.

Please adapt the other newly added files too.

Done c35dbea

crasbe · 2026-06-16T15:10:03Z

+#ifndef BOARD_H
+#define BOARD_H


We replaced the classic headerguards with #pragma once that is between the Copyright header and the Doxygen header, see #21335.

Please adapt all newly added header files yourself.

crasbe · 2026-06-16T15:12:47Z

+ * @{
+ */
+#ifndef RTT_DEV
+#define RTT_DEV             (0)                 /**< NRF_RTC0_S */


Suggested change

#define RTT_DEV (0) /**< NRF_RTC0_S */

# define RTT_DEV (0) /**< NRF_RTC0_S */

The preprocessor commands between #ifndef and #endif should have indentation, see https://guides.riot-os.org/c_tutorials/coding_conventions/#indentation-of-preprocessor-directives for more information.

Please adapt all the newly added files. Added code to existing files that do not have the indentation yet should "fit in". That means that if it's a self contained block, it should have indentation but if it's code added to a big #if-#else if-#endif structure, the indentation can be omitted.

crasbe · 2026-06-16T15:13:28Z

We switched from the doc.txt format to doc.md. Please check #21220 for more information.

crasbe · 2026-06-16T15:14:15Z

+```
+    make BOARD=nrf9160dk -C examples/hello-world term
+```


Suggested change

```

make BOARD=nrf9160dk -C examples/hello-world term

```

```shell

make BOARD=nrf9160dk-ns -C examples/hello-world term

```

Code blocks with backticks do not need indentation. You can also specify the language for syntax highlighting.

Also, the board should probably be nrf9160dk-ns.

crasbe · 2026-06-16T15:40:18Z

Suggested change

TEST_ASSERT_PSA_SUCCESS(psa_sign_hash(privkey_id, ECC_ALG, hash, sizeof(hash),

signature, sizeof(signature), &sig_length));

/* verify on original message with internal hashing operation */

TEST_ASSERT_PSA_SUCCESS(psa_verify_message(pubkey_id, ECC_ALG, msg, sizeof(msg),

signature, sig_length));

d26d442

wrapped three more lines

crasbe · 2026-06-16T15:40:28Z

This file is missing the copyright and Doxygen headers.

crasbe · 2026-06-16T15:40:41Z

Please adapt the long lines accordingly.

crasbe · 2026-06-16T15:40:46Z

This file is missing the copyright and Doxygen headers.

crasbe · 2026-06-16T15:41:56Z

Suggested change

#define TEST_ASSERT_PSA_SUCCESS(func_) TEST_ASSERT_MESSAGE(func_ == PSA_SUCCESS, #func_ " failed");

That would bring it to 100 characters total.

crasbe · 2026-06-19T13:52:39Z

To be honest I wonder if it even makes sense to create a separate nrf9160dk-ns board. The differences between nrf9160dk and nrf9160dk-ns are miniscule and could easily be handled by some #ifdefs.

Also I wondered if the NRF_TRUSTZONE_NONSECURE flag couldn't be a feature or pseudomodule instead, something like periph_trustzone_m.

Then the modules can extend FEATURES_OPTIONAL or FEATURES_REQUIRED in their Makefiles to make use of the Trust Zone support.

crasbe · 2026-06-19T15:21:44Z

Also I wondered if the NRF_TRUSTZONE_NONSECURE flag couldn't be a feature or pseudomodule instead, something like periph_trustzone_m.

Then the modules can extend FEATURES_OPTIONAL or FEATURES_REQUIRED in their Makefiles to make use of the Trust Zone support.

Oh, there is already a trustzone_m feature defined. I also guess that TrustZone is not really a peripheral either.

janthies · 2026-07-16T07:38:00Z

To be honest I wonder if it even makes sense to create a separate nrf9160dk-ns board. The differences between nrf9160dk and nrf9160dk-ns are miniscule and could easily be handled by some #ifdefs.

Also I wondered if the NRF_TRUSTZONE_NONSECURE flag couldn't be a feature or pseudomodule instead, something like periph_trustzone_m.

Then the modules can extend FEATURES_OPTIONAL or FEATURES_REQUIRED in their Makefiles to make use of the Trust Zone support.

I'm not sure if using trustzone_m is such a good idea because it's information whether a cpu supports trustzone, not whether a specific build is with a secure firmware and should thus be offset in memory. So, iiuc, the question is feature or pseudomodule?
Also, riotboot is already supported by the nrf9160. I guess this is the same mechanism and we should just copy it / draw inspiration from it?
I guess the duplication is already showing its weaknesses as the nrf9160dk-ns also inherited the riotboot feature from the original board which I doubt would work right now. So yeah, bringing them back together would probably be a smart idea

crasbe · 2026-07-16T10:53:16Z

I'm not sure if using trustzone_m is such a good idea because it's information whether a cpu supports trustzone, not whether a specific build is with a secure firmware and should thus be offset in memory. So, iiuc, the question is feature or pseudomodule?

The feature mechanism works like that: A CPU/board adds peripherals or "features" to the FEATURES_PROVIDED variable. That is usually stuff like RTC, SPI, I2C, RNG, ...
This just lists the features that are there to use, but it does not mean they are actually used.

Then usually a module will specify which features it requires to work with the FEATURES_REQUIRED variable. For example, a sensor driver might require periph_i2c. The feature resolution then checks if the CPU has that feature and if any other features are in conflict with it.

The application would typically specify add a module or pseudomodule to USEMODULE, but it is also possible to add FEATURES_REQUIRED to the application Makefile if you want to work directly with a peripheral.

Since your code doesn't really have the intermediate module/driver, it would be possible to define a PSEUDOMODULE and add a conditional to the $(RIOTBASE)/Makefile.dep to add the FEATURES_REQUIRED += trustzone_m to the list when the according PSEUDOMODULE is loaded.

ifneq (,$(filter trustzone_m,$(USEMODULE)))
  FEATURES_REQUIRED += trustzone_m
endif

It should be possible to add that to cpu/nrf9160/Makefile.dep too, which would be cleaner, but I haven't tried it out yet.

Perhaps there are better names than two times trustzone_m, idk.

crasbe · 2026-07-16T13:29:12Z

It should be possible to add that to cpu/nrf9160/Makefile.dep too, which would be cleaner, but I haven't tried it out yet.

Yes, that works.

Einhornhool added 30 commits June 12, 2024 18:01

cpu/nrf*: add conditional secure register access

b12026e

boards/nrf9160dk: add ns entry functions and config

5b9ac03

boards: Add nrf9160dk-ns platform

b9339fe

fixup! cpu/nrf*: add conditional secure register access

c6b9c30

core/lib: make thread_sleep dependent on CORE_THREAD

5bafb3f

Add riot-secure application

e504f6c

examples/blinky: Update blinky to use ns entry functions

af00ee6

pkg/nrfx: disable cast-align compiler warning

3a810db

Remove traces of in-RIOT secure firmware

1105b74

makefiles: add riot-tee flash target

c107bb2

pkg: Add riot-tee as package

921018c

boards/nrf9160dk-ns: Add riot-tee includes

e3c3a67

fixup! Remove traces of in-RIOT secure firmware

54d153d

examples/blinky: Update blinky example

11b593a

pkg/nrfx: update nrfx version

761f10b

boards/nrf9160dk-ns: Remove nsc_libs.o from archives

fd61c0c

pkg/riot-tee: Update Makefile for CMake

0a0bd8c

boards/nrf9160dk-ns: Use NS Timer

ea2920e

cpu/nrf9160dk: define NRF_FICR_NS

81ccf26

pkg/riot-tee: Add PSA wrappers

2d5aec7

sys/psa_crypto: Add riot-tee as backend

4c8d7a6

examples/blinky: Use riot-tee

2b36c44

examples/psa_crypto: Use riot-tee

d20634e

cpu/cortexm_common: Enable threading in non-secure mode

250f93a

pkg/riot-tee: Update includes

b8b9961

sys/psa_crypto: Add custom random call

c5f0224

pkg/riot-tee: Add random wrapper

4f806b9

cpu: clean up

4563315

examples/psa_crypto: disable ed25519

3bc311d

sys/psa_crypto: Add modules for TEE ECDSA

dc4735c

github-actions Bot added Area: boards Area: Board ports Area: cpu Area: CPU/MCU ports Area: sys Area: System Area: examples Area: Example Applications Area: Kconfig Area: Kconfig integration labels Jun 16, 2026

AnnsAnns added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jun 16, 2026

janthies changed the title ~~Feature/riot sw~~ Arm TrustZone-M support for nrf9160dk Jun 16, 2026

janthies changed the title ~~Arm TrustZone-M support for nrf9160dk~~ cpu/nrf9160dk Arm TrustZone-M support Jun 16, 2026

AnnsAnns requested changes Jun 16, 2026

View reviewed changes

AnnsAnns reviewed Jun 16, 2026

View reviewed changes

Comment thread examples/blinky/main.c

crasbe added the State: needs rebase State: The codebase was changed since the creation of the PR, making a rebase necessary label Jun 16, 2026

crasbe reviewed Jun 16, 2026

View reviewed changes

crasbe added the Type: new feature The issue requests / The PR implemements a new feature for RIOT label Jun 16, 2026

treewide: use SPDX license headers for nRF9160 TEE files

c35dbea

crasbe removed the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jun 18, 2026

AnnsAnns added the AI: Helped PR/Issue uses AI sparingly, e.g. code inline assistant, debugging with AI, etc. label Jul 6, 2026

crasbe added the State: waiting for author State: Action by the author of the PR is required label Jul 9, 2026

janths added 4 commits July 15, 2026 16:18

treewide: use #pragma once in newly added headers

a975cd3

treewide: indent preprocessor directives in added code

7128c96

boards/nrf9160dk-ns: convert doc.txt to doc.md

0114c77

tests/sys/psa_riot_tee: wrap long lines in sealed key test

d26d442

crasbe removed the State: waiting for author State: Action by the author of the PR is required label Jul 15, 2026

janthies closed this Jul 16, 2026

janthies reopened this Jul 16, 2026

	#define RTT_DEV (0) /*< NRF_RTC0_S /
	# define RTT_DEV (0) /*< NRF_RTC0_S /

-```
-    make BOARD=nrf9160dk -C examples/hello-world term
-```
+```shell
+make BOARD=nrf9160dk-ns -C examples/hello-world term
+```

+    TEST_ASSERT_PSA_SUCCESS(psa_sign_hash(privkey_id, ECC_ALG, hash, sizeof(hash),
+                                          signature, sizeof(signature), &sig_length));
+    /* verify on original message with internal hashing operation */
+    TEST_ASSERT_PSA_SUCCESS(psa_verify_message(pubkey_id, ECC_ALG, msg, sizeof(msg),
+                                               signature, sig_length));


	#define TEST_ASSERT_PSA_SUCCESS(func_) TEST_ASSERT_MESSAGE(func_ == PSA_SUCCESS, #func_ " failed");

Uh oh!

Conversation

janthies commented Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution description

Testing procedure

Issues/PRs references

Declaration of AI-Tools / LLMs usage:

Uh oh!

riot-ci commented Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Murdock results

Artifacts

Uh oh!

AnnsAnns left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

crasbe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

crasbe commented Jun 19, 2026

Uh oh!

crasbe commented Jun 19, 2026

Uh oh!

janthies commented Jul 16, 2026

Uh oh!

crasbe commented Jul 16, 2026

Uh oh!

crasbe commented Jul 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

janthies commented Jun 16, 2026 •

edited

Loading

riot-ci commented Jun 16, 2026 •

edited

Loading