The RealTek RTL8735B (AmebaPro2) is an Arm Cortex-M33 AIoT SoC with a hardware crypto engine and, importantly, a per-device Hardware Unique Key (HUK) fused into the silicon. The HUK never leaves the chip and cannot be read by software. That makes it an ideal root from which to derive keys that are bound to one specific device: wrap a secret under a HUK-derived key on the device that will use it, and the wrapped blob is useless anywhere else.
We have added a wolfCrypt port that exposes exactly this through the standard wolfCrypt crypto-callback (CryptoCb) framework, so applications keep using the normal wolfCrypt APIs.
How it works
The port registers a CryptoCb device at a device id (WC_HUK_DEVID). When an object is initialized with that device id, its operations route to the RTL8735B HAL crypto engine instead of software. The key handling is the interesting part: the 256-bit value the application passes as the “key” is not used as the AES key directly. It is HKDF input, fed through a chain of HKDF derivations keyed by the HUK (a “key ladder”; see the diagram below). The seed first becomes a pseudo-random key in a secure slot (HKDF-Extract, keyed by the HUK), and then a device-bound working key in another secure slot (HKDF-Expand). AES then runs from that secure slot. The working key never appears in software memory, and the same seed always yields the same device-bound key, so encrypt/decrypt and MAC verification are deterministic on that device and meaningless on any other.
On top of that derived key, the port provides:
- AES in GCM, ECB, CBC and CTR (CBC/CTR are chained in software over single-block secure-key ECB operations, so the key stays in hardware).
- HMAC-SHA256 over the secure-key slot.
- The secure TRNG exposed as the wolfCrypt RNG seed source, so an application seeds its DRBG just by using the HUK device id.
- ECDSA P-256, bound to the HUK: the private scalar is sealed under a HUK-derived key and unwrapped only on its origin device, then signed on the hardware ECDSA engine. (An OTP-resident key variant keeps the scalar entirely out of software.)
Sealing keys to the device (authenticated wrapping)
The device-bound private scalar is sealed with AES-GCM under the HUK-derived key, not plain ECB. That is a deliberate choice. Because GCM is authenticated, a tampered, corrupted, or wrong-device blob fails at unwrap with an authentication error, instead of silently decrypting to a garbage key that only fails somewhere downstream. The wrap carries a nonce and a tag alongside the ciphertext, and the whole thing only unwraps on the silicon whose HUK produced the slot key.
Using the HUK in TLS
The most compelling use of a HUK is a TLS server identity bound to the silicon: the private key cannot be extracted and cloned onto another device. We validated exactly this with an in-memory TLS 1.2 ECDHE-ECDSA handshake on the RTL8735B, where the server certificate signature is produced on the HUK-backed engine, negotiating ECDHE-ECDSA-AES128-GCM-SHA256 and exchanging application data.
There is a subtlety worth calling out, because anyone offloading TLS to a secure element will hit it. The intuitive approach (putting the whole WOLFSSL_CTX on WC_HUK_DEVID) breaks the handshake. The HUK device treats a 32-byte key as an HKDF seed, but TLS legitimately uses 32-byte keys of its own. The P-256 ECDHE pre-master secret is 32 bytes, and TLS 1.2’s PRF computes master_secret = HMAC-SHA256(pre_master, …). Routing that PRF HMAC through the HUK derives the wrong master secret, and the handshake fails with VERIFY_MAC_ERROR.
The right approach is to route only the certificate signature to the HUK, using a PK sign callback (wolfSSL_CTX_SetEccSignCb), and leave the PRF, record encryption, and ECDHE key agreement in software. That is the correct pattern for offloading just server authentication to any secure element (not only this part), and it keeps the HUK doing exactly the one operation that must be device-bound.
What runs in hardware
The engine accelerates AES (256-bit, GCM and ECB), HMAC-SHA256, ECDSA P-256 sign and verify, and the TRNG. ECDHE key agreement and the TLS record layer run in software (the engine exposes no arbitrary-point scalar-multiply the port could drive), and on-device EC key generation is not offloaded (provision keys, or use the HUK-wrapped-scalar model). Being explicit about this matters: the value of the HUK here is device binding and offload of the operations that benefit, not accelerating every primitive.
Performance and footprint
On the RTL8735B “KM4” Cortex-M33 at 500 MHz, routing operations to the engine is a clear win where the engine has a native block path. Measured against the portable-C backend:
- AES-256-GCM: ~8.5x
- AES-256-ECB: ~6.3x
- HMAC-SHA256: ~4x
- ECDSA P-256 sign / verify: ~6.8x / ~9.4x
One honest caveat: AES-256-CBC and CTR are slower on the engine (roughly 2.3 vs 7 MiB/s), because the port chains them in software over single-block secure-key ECB calls, so per-block HAL overhead dominates. GCM and ECB are the real symmetric wins; for bulk CBC/CTR the software path (or the Cortex-M assembly backend) is faster.
The port is also small. It compiles to about 4.8 KB of code, 0 bytes of .data, and 128 bytes of .bss on-target. And because the engine can replace the software implementations, a crypto-callback-only build that drops software AES and ECC trims roughly 32 KB (about a quarter) off the application’s flash. On a stack-constrained RTOS task, WOLFSSL_SMALL_STACK moves the ECDSA sign scratch to the heap and shrinks that function’s stack frame from about 1.9 KB to under 100 bytes.
Availability
The port lives in wolfSSL under wolfcrypt/src/port/realtek/, enabled with WOLFSSL_RTL8735B_HUK and the crypto-callback framework. It ships with a host compile-and-self-test build for CI and is validated on RTL8735B silicon, with example applications (a HUK crypto demo and the HUK-in-TLS handshake above) in the wolfssl-examples repository. It is proposed upstream in wolfSSL PR #10677.
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