wolfSSL now offloads cryptography to the Silicon Labs EFR32 Series 2 Secure Element through wolfCrypt crypto callbacks. Define WOLFSSL_SILABS_CRYPTOCB, and your application code does not change.
This covers wolfCrypt and TLS together. Because operations route by device id rather than by a compile time hook, the same offload serves a direct wolfCrypt API call and a TLS connection. TLS 1.2 and TLS 1.3 are both supported, along with DTLS, and no separate configuration is needed for any of them.
What it does
- Routes AES (ECB, CBC, CTR, GCM, CCM), AES-CMAC, ChaCha20-Poly1305, SHA-2, ECDSA, ECDH, HKDF, PBKDF2 and the hardware TRNG to the Secure Element.
- Offloads the TLS record layer and the handshake, so bulk AES-GCM or ChaCha20-Poly1305 records, the ECDHE key exchange, the ECDSA signature and the HKDF key schedule all run on the Secure Element.
- Falls back to software automatically for anything the Secure Element cannot do. There is no all-or-nothing build choice, and you can offload a subset by enabling individual engines.
- Supports wrapped keys and built-in key slots on Secure Vault High parts. The Secure Element performs the operation and the key material is never visible to your application.
- Adds ChaCha20-Poly1305 and PBKDF2 to the wolfCrypt crypto callback framework itself, so any callback device can use them.
Measured results
Measured on an EFR32FG25B222F1920IM56 with Secure Vault High, wolfSSL 5.9.2. The benchmark runs every algorithm twice and labels the rows, so each pair comes from one run on one part. The software columns are two builds: plain C, and the same project with wolfSSL’s Cortex-M Thumb2 assembly turned on.
| Algorithm | Software (C) | Software (Thumb2 asm) | Secure Element | SE vs C |
|---|---|---|---|---|
| AES-256-GCM-enc | 260 KiB/s | 502 KiB/s | 2.38 MiB/s | 9.4x |
| AES-CCM-enc | 426 KiB/s | 460 KiB/s | 2.20 MiB/s | 5.3x |
| AES-256-ECB-enc | 638 KiB/s | 711 KiB/s | 2.70 MiB/s | 4.3x |
| AES-256-CTR | 625 KiB/s | 705 KiB/s | 2.63 MiB/s | 4.3x |
| AES-256-CBC-enc | 627 KiB/s | 710 KiB/s | 2.58 MiB/s | 4.2x |
| AES-256-CMAC | 593 KiB/s | 640 KiB/s | 2.40 MiB/s | 4.1x |
| ECDSA 256 verify | 41.9 ops/s | 41.9 ops/s | 163.8 ops/s | 3.9x |
| SHA-256 | 1.23 MiB/s | 1.99 MiB/s | 3.67 MiB/s | 3.0x |
| ECDHE 256 agree | 65.4 ops/s | 65.4 ops/s | 179.8 ops/s | 2.7x |
| ECDSA 256 sign | 67.8 ops/s | 67.8 ops/s | 173.4 ops/s | 2.6x |
| HMAC-SHA-256 | 1.22 MiB/s | 1.97 MiB/s | 3.04 MiB/s | 2.5x |
The Secure Element stays ahead of optimized assembly. The ECC rows are flat between the two software columns because both builds already use wolfSSL’s SP Cortex-M assembly. The full table, including the rows where the Secure Element is slower, is in the port README.
Tested on hardware
The example project runs the full wolfCrypt test suite on the Secure Element and passes, which checks every offloaded algorithm against its known answer vectors.
It also runs a TLS 1.3 client and server against each other on the device, with both peers routed to the Secure Element, for three cipher suites:
- TLS13-AES128-GCM-SHA256
- TLS13-AES256-GCM-SHA384
- TLS13-CHACHA20-POLY1305-SHA256
All three complete the handshake and pass application data through the record layer. That covers ground the known answer vectors cannot, because record buffers land at arbitrary offsets and one cipher object is reused across many chained records.
The example builds headlessly with slc-cli and GNU Arm, with no GUI required, on the kit that produced the numbers above. It is up as PR #627.
Full details are in the PR #11267.
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