wolfSSL 5.9.4: Major Upgrades for NXP SE050 and SE051 Secure Elements

If you use an NXP EdgeLock SE050 or SE051 secure element with wolfSSL, you’ll want to upgrade to 5.9.4. The SE05x port got a lot of work this release. Some of it adds APIs people have been asking for. Some of it was needed because newer silicon changed the rules.

ECDH on applet 7.2

The SE051 runs applet 7.2, which is much stricter about what can be read back out of the chip. wolfSSL used to compute an ECDH shared secret into an object on the secure element and then read it back. Applet 7.2 refuses that read, so ECDH failed. In 5.9.4, wolfSSL uses the direct ECDH command on applet 7.2 and later, where the chip returns the shared secret in its response. We tested this on real SE051 hardware with P-256, X25519 and the full wolfCrypt test suite.

Smarter hardware offload

wolfSSL now chooses between the SE05x and software for each operation, based on where the key lives. If the key is resident on the secure element, the chip does the work. If it isn’t, such as an ECDH with a key that only exists in RAM, wolfSSL falls back to software instead of returning an error.

New provisioning and lifecycle APIs

This is the biggest change. 5.9.4 adds application-facing APIs for:

  • Session lifecycle: Get at the underlying Plug & Trust session with wc_se050_get_session() or wc_se050_get_config() when you need an operation wolfSSL doesn’t wrap. Close a wolfSSL-owned session with wc_se050_close(). wolfCrypt_Cleanup() now closes it for you, and wolfCrypt_Init() leaves a session you set up yourself alone.
  • Policy-aware keys: You can attach applet policies when you insert or generate keys on-chip. Passing zero keeps the old default behaviour, so existing code works as before. On applet 7.2 and later, wc_se050_get_object_attributes() lets your provisioning code check exactly what was stored.
  • Binary objects: You can store larger objects, which are written in chunks.
  • Runtime Platform SCP03: Supply your SCP03 keys at runtime instead of compiling them in, and rotate them when you need to.
  • Nonce-bound attestation: The host supplies a fresh challenge, so an attestation response can’t be replayed. If you don’t need attestation, WOLFSSL_SE050_NO_ATTEST compiles it out.

The SE05x transport is shared with wolfCrypt, so threaded builds now enable the wolfCrypt hardware mutex by default. We’ve also tested against Plug & Trust middleware 04.07.01.

Testing without the hardware

All of this runs in CI against our SE050 simulator. We checked the simulator’s behaviour against a real SE050C (applet 3.1.1) and SE051 (applet 7.2.0), so regressions should be caught well before they reach your board.

Check out the full details in the wolfSSL 5.9.4 Release Notes.

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