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