NXP S32K3 Hardware Security Engine (HSE) support using wolfSSL
wolfSSL now supports hardware-accelerated cryptography on the NXP S32K3 family using the on-chip Hardware Security Engine (HSE). The HSE is a secure coprocessor integrated into NXP’s automotive S32K3 microcontrollers.
The Hardware Security Engine (HSE)
The HSE runs its own firmware on a dedicated core and communicates with the application core over a Messaging Unit (MU). It is responsible for performing cryptographic operations, managing a protected key store, and enforcing access policies on those keys. Because the keys are held inside the HSE and referenced by handle rather than by value, sensitive material such as long-term private keys and SHE keys are never exposed to application memory.
Supported HSE Algorithms:
Random number generation:
- Hardware TRNG
Hashing:
-
SHA-256 Symmetric encryption:
- AES-CBC with 256-bit keys
- AES-GCM with 256-bit keys
Message authentication:
- AES-CMAC with 128, 192, and 256-bit keys
Asymmetric:
- RSA sign and verify on 2048-bit and 4096-bit
- ECDSA sign and verify on P-256 and P-521
SHE (Secure Hardware Extension) Support:
The port exposes the SHE interface through a set of wc_SHE_* APIs. SHE defines a standardized key layout and a secure key-update protocol used widely in automotive applications. The port supports loading and updating SHE keys using the M1 through M5 memory-update protocol with M4 and M5 verification, applying SHE key-usage and protection flags such as CMAC usage and write protection, AES and CMAC operations using SHE-managed keys, and reading the device identity. SHE keys live inside the HSE key store and are operated on by handle, so the application never sees the raw key bytes.
Secure Key Storage with the HSE Key Store:
A central benefit of the HSE is its protected key store. Keys are organized into NVM and RAM key catalogs, then provisioned into specific groups and slots. Once a key is in the store, wolfCrypt refers to it through a key identifier rather than a buffer of key material. In the port, the hardware-backed paths use the wolfCrypt _Id initialization APIs, which tell wolfSSL to operate on a stored key instead of a software key in RAM. This keeps private keys inside the HSE for their entire lifetime. You can provision a key once, then sign, verify, encrypt, or compute a MAC with it indefinitely without ever loading it into application memory.
Multi-Threaded and Parallel Operation:
The port is built for concurrent use under an RTOS. By default it drives two Messaging Units in parallel, MU0 and MU1, each an independent request and response channel to the HSE. One thread can run AES-CBC on MU0 while another runs SHA-256 on MU1, so unrelated operations overlap instead of serializing through a single path. Each MU also exposes a pool of channels, where a channel is one in-flight HSE request, so multiple requests can be outstanding on the same MU at once. Responses are delivered by interrupt, and a requesting task yields to the scheduler while it waits, which keeps the core available to other work.
Benchmarks:
The HSE is first and foremost a security module. The reason to use it is hardware-isolated key storage and cryptographic execution, where private keys and secrets live inside the engine and are referenced by handle rather than ever appearing in application memory. Raw throughput is a secondary concern. The HSE Port accelerates a specific subset of operations: AES-256 in CBC and GCM, SHA-256, AES-CMAC, RSA, and ECC. The charts below cover only the HSE-accelerated operations. These numbers were captured with the wolfCrypt benchmark on an S32K344 (Cortex-M7 @ 48 MHz) using 1024-byte blocks.
Public key operations (HSE-accelerated):
AES:
Hashing and message authentication:
