Last month we announced wolfSSL as a TLS provider for Zephyr’s secure sockets layer. That work covered the networking side of the stack. Today we are announcing the layer underneath it: our wolfPSA, a PSA Crypto provider, now has Zephyr support with wolfCrypt as a backed.
Why this matters
Zephyr exposes crypto to applications through the PSA Crypto API, and a growing part of the tree depends on it: the Bluetooth host and Mesh, TLS credential management, secure storage, and the samples/psa applications. Until now that API had exactly one implementation on Zephyr, the one shipped with mbedTLS. If you wanted wolfSSL’s cryptography, PSA was a wall.
Since Zephyr 4.3 the PSA provider is a pluggable choice (CONFIG_PSA_CRYPTO_PROVIDER_CUSTOM). wolfPSA now plugs into that seam. It implements the PSA Certified Crypto API 1.4 plus the PQC extension in C on top of wolfCrypt, so every PSA consumer in Zephyr keeps calling the same standard API while the actual cryptography comes from wolfCrypt. It is a genuine drop-in: Zephyr’s own PSA tests and samples run unmodified against wolfPSA, and a build with wolfPSA enabled links zero mbedTLS code.
What you get by swapping the provider:
- FIPS 140-3. wolfCrypt is the most widely deployed FIPS 140-3 validated cryptographic module in the embedded world, and the Zephyr module now carries a proper Kconfig FIPS version selector so you can point a build at your licensed FIPS bundle. Nothing else in the Zephyr PSA ecosystem offers a validated module today.
- Post-quantum. ML-KEM, ML-DSA, LMS/XMSS, and SHAKE are exposed through the standard PSA PQC extension.
- Hardware acceleration and offload. wolfCrypt’s hardware ports and its crypto callback layer let you route PSA operations to a secure element, an accelerator, or wolfHSM without touching application code.
- Commercial support and a mature, audited codebase, from the same team, under the same license options as the rest of wolfSSL. This is especially important for the upcoming requirements of the EU Cyber Resilience Act.
Turning it on
CONFIG_WOLFSSL=y CONFIG_PSA_CRYPTO=y CONFIG_PSA_CRYPTO_PROVIDER_CUSTOM=y CONFIG_ENTROPY_GENERATOR=y
That is the whole switch. wolfPSA follows whatever wolfCrypt configuration you already use, and the PSA_WANT_* surface it advertises is generated from that compiled configuration at build time. Turn crypto features off and both the PSA surface and the image shrink together, and an application asking for something you did not enable gets an honest compile-time miss rather than a runtime surprise.
Persistent keys work through Zephyr’s secure_storage subsystem over PSA ITS, exactly like the mbedTLS provider. Encryption at rest uses a wolfCrypt AES-256-GCM ITS transform, which is what keeps mbedTLS out of the image entirely.
Improvements to the wolfSSL Zephyr module
Supporting wolfPSA meant sharpening the wolfSSL Zephyr module itself, and those changes benefit every Zephyr user of wolfSSL:
- Native Zephyr threading. wolfCrypt now uses k_mutex, k_thread, and k_condvar directly instead of requiring CONFIG_POSIX_THREADS, so a multi-threaded build no longer drags in the POSIX subsystem.
- Proper DRBG seeding. The module seeds wolfCrypt’s Hash-DRBG from the platform entropy driver, and Zephyr’s sys_csrand_get() can be backed by wolfSSL or by wolfPSA.
- A reworked FIPS Kconfig selector and additional algorithm knobs, including the PQC families wolfPSA exposes.
The secure sockets patches from the previous post continue to live in the OSP repository, organized by Zephyr release. wolfPSA and the wolfSSL TLS stack can share a single image: wolfCrypt is built once and both layers use it.
Availability
wolfPSA on Zephyr requires Zephyr 4.3 or newer, and is tested on 4.3 and 4.4 in CI on native_sim as well as on physical Cortex-M hardware.
Got questions about wolfPSA, PSA Crypto, or Zephyr? Contact us at facts@wolfssl.com or +1 425 245 8247. And if you have not tried it yet, download wolfSSL and start building.
Download wolfSSL Now