PSA Crypto: The P is for Portability · Daniel Mangum

Arm&rsquo;s Platform Security Architecture<br>(PSA) was<br>released in<br>2017,<br>but it was two years until the first beta release of the PSA Cryptography<br>API<br>in 2019, and another year until the 1.0 specification in 2020. Aimed at securing<br>connected devices and originally targeting only Arm-based systems, PSA has<br>evolved with the donation of the PSA Certified<br>program to GlobalPlatform in<br>2025,<br>allowing non-Arm devices, such as popular RISC-V microcontrollers<br>(MCUs), to achieve<br>certification. Arm still provides resources to assist in the certification<br>process, such as developing the specifications for PSA Certified<br>APIs, which include the Crypto<br>API, Secure Storage<br>API, Attestation<br>API, Firmware Update<br>API, and Status Code<br>API.

The distinction between resources targeting Arm platforms and those that are<br>generally applicable can be confusing, but for the most part, the PSA Certfied<br>APIs are platform-agnostic, while Arm provides additional resources that extend<br>beyond specification and into implementation of the APIs using their hardware<br>IP. For example, Trusted Firmware M<br>(TF-M)<br>is a reference implementation of PSA, which relies on the boundary between the<br>Secure Processing Environment (SPE) and Non-Secure Processing Environment (NSPE)<br>on Arm Cortex-M platforms. Armv8-M provides this hardware-level isolation via<br>the Cortex-M Security Extension (CMSE), more commonly referred to as<br>TrustZone.

I have previously written about Arm Cortex-M hardware security states<br>here.

The PSA APIs create a consistent programming interface for which many<br>implementations may exist. At my day job at Golioth (now<br>part of Canonical), we have been tracking the adoption<br>of the PSA Crypto API over the past few years. Because we typically develop<br>embedded software that enables connectivity and targets a wide variety of<br>hardware and platforms, we are intimately familiar with the security capabilites<br>of different processor architectures, microcontrollers, and RTOS&rsquo;s. However,<br>ensuring that we are taking advantage of not just the security features, but<br>also the available cryptographic acceleration, has been painful. On highly<br>constrained devices, performance is an integral component of security . Slow or<br>power hungry cryptographic operations can be enough to sink a product that needs<br>to operate for an extended period of time on a small battery. In the worst case<br>scenario, product makers punt on security because of the complexity it<br>introduces into the system.

MbedTLS v4.0.0 and TF-PSA-Crypto

Link to heading

If you work on connected embedded systems, you have almost certainly either been<br>migrating your own firmware to leverage PSA APIs, or been watching closely as<br>libraries you depend on, such as MbedTLS<br>have been rearchitected to target PSA APIs or offer implementations. In October<br>of 2025, the v4.0.0<br>release<br>officially split out the PSA Crypto API implementation of MbedTLS into<br>TF-PSA-Crypto.

MbedTLS, a library that traditionally has offered TLS / DTLS support, X.509<br>certificate utilities, and various cryptographic primitives, has been<br>incorporating the PSA Crypto API since the v2.15.0<br>release in<br>2018. The recent step of splitting out the PSA Crypto implementation imposes non-trivial migration work<br>on consumers of MbedTLS, but it also takes an important step towards enabling<br>them to standardize on the API.

While MbedTLS has supported alternative drivers in the<br>past<br>to allow for hardware acceleration and proprietary cryptography libaries, the<br>new TF-PSA-Crypto library offers a much cleaner mechanism, where both<br>transparent and opaque<br>drivers<br>can be implemented. Transparent drivers require the passing of plaintext keys,<br>making them suitable for pure software and hardware accelerated cryptographic<br>operations, while opaque drivers operate on keys stored in secure locations,<br>such as a physically separate secure element or an integrated secure enclave.<br>Driver capabilities can be declared using a JSON<br>syntax,<br>then the necessary wrappers can be auto-generated to call into the driver<br>implemenations. For example, the test opaque<br>driver<br>is specified in the following JSON file.

"prefix": "mbedtls_test",<br>"type": "opaque",<br>"location": "0x7fffff",<br>"mbedtls/h_condition": "defined(PSA_CRYPTO_DRIVER_TEST)",<br>"headers": ["test/drivers/test_driver.h"],<br>"capabilities": [<br>"_comment": "The Mbed TLS opaque driver supports import key/export key/export_public key",<br>"mbedtls/c_condition": "defined(PSA_CRYPTO_DRIVER_TEST)",<br>"entry_points": ["import_key", "export_key", "export_public_key"]<br>},<br>"_comment": "The Mbed TLS opaque driver supports copy key/ get builtin key",<br>"mbedtls/c_condition": "defined(PSA_CRYPTO_DRIVER_TEST)",<br>"entry_points": ["copy_key", "get_builtin_key"],<br>"names": {"copy_key":"mbedtls_test_opaque_copy_key", "get_builtin_key":"mbedtls_test_opaque_get_builtin_key"}

There are template header<br>files<br>that use Jinja to automatically<br>incorporate the driver entry points in the wrapper calls.

static...