Secure Element Offload via Crypto Callbacks in wolfSSL
Modern embedded and security-critical systems increasingly rely on Secure Elements, TPMs, and hardware cryptographic accelerators to protect private keys. In wolfSSL, asymmetric keys such as ECC private keys can already reside entirely inside hardware using Crypto Callbacks.
Until now, however, TLS 1.3 AES-GCM session keys were still created and expanded in host memory.
That gap is now closed.
A recent update merged into wolfSSL master adds full AES-GCM SetKey offload support through the Crypto Callback framework, enabling TLS 1.3 symmetric session keys to remain inside hardware.
The Problem
After the TLS 1.3 handshake completes:
- Ephemeral key exchange derives symmetric session secrets
- AES-GCM keys are generated for record-layer encryption
- AES key expansion occurs in RAM
- GHASH tables are computed in software
- Encrypt/decrypt operations reference host memory
Even when Secure Elements protect private keys during handshake, the symmetric session keys used for record encryption were still exposed in application memory.
For high-assurance systems, this creates real concerns:
- Session keys visible in RAM during runtime
- Potential exposure through memory disclosure vulnerabilities
- Increased attack surface
- Compliance challenges in hardware-isolated designs
In short:
ECC keys could live in hardware.
AES session keys could not.
The Solution
wolfSSL now supports AES SetKey Crypto Callback offload.
When enabled:
- wolfSSL invokes your Crypto Callback during AES SetKey
- The TLS session key can be imported directly into your Secure Element
- The host copy can be immediately zeroized
- An opaque device handle (aes->devCtx) is retained
- Software key expansion and GHASH table generation are skipped
- All AES-GCM encrypt/decrypt operations are routed through CryptoCB
This mirrors the existing ECC offload model — but now applies to symmetric session keys as well.
Importantly:
There is no behavior change unless the feature is explicitly enabled.
Backward compatibility is fully preserved.
The Benefits
- Session Keys Never Reside in RAM
TLS 1.3 AES-GCM keys can remain entirely inside hardware.
This reduces:- Memory exposure risks
- Forensic extraction opportunities
- Software-based side-channel surface
- End-to-End Hardware-Enforced Key Isolation
Security policies enforced by your Secure Element can now apply to:- Private handshake keys
- TLS session keys
- Record-layer encryption
This enables a fully hardware-backed TLS implementation — not just hardware-backed handshake.
- Minimal Integration Overhead
To enable the feature:- Build with WOLF_CRYPTO_CB_AES_SETKEY
- Implement AES SetKey import in your Crypto Callback
- Implement AES-GCM encrypt/decrypt operations using your device key
wolfSSL automatically:
- Skips software key setup
- Routes operations through the device
- Preserves standard TLS 1.3 behavior
No application-layer TLS changes are required.
- Built for High-Assurance and Embedded Deployments
This feature is especially valuable in:- Secure boot and trusted execution environments
- Automotive systems
- Aerospace and defense platforms
- Industrial IoT
- Payment and reg
- ulated systems
It reinforces wolfSSL’s focus on constrained, performance-sensitive, and security-critical deployments.
Closing the Symmetric Gap
With AES-GCM offload support now merged into master, wolfSSL enables:
- Hardware-backed ECC
- Hardware-backed TLS 1.3 symmetric encryption
- Full Crypto Callback extensibility
Secure Elements can now protect the entire TLS cryptographic lifecycle — not just the handshake.
For integration guidance, key lifetime considerations, or device-specific optimization strategies, the wolfSSL team is ready to help.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now