Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
wolfhsm
Safe Rust client for wolfHSM hardware security modules.
What
wolfHSM is an open-source C firmware library from wolfSSL that implements the server side of a hardware security module (HSM). It runs on secure microcontrollers — Infineon TC3xx, Microchip PIC32CZ, Renesas RH850, and others — and exposes cryptographic services to a host processor over a transport layer (TCP, Unix socket, or shared memory).
This crate wraps the wolfHSM C client library with an idiomatic Rust API. Your application links this crate; the wolfHSM server runs separately (on secure hardware or a POSIX simulator). The crate provides:
- Hardware-isolated keys — ECC P-256, Ed25519, Curve25519, RSA, ML-DSA — generated and stored inside the secure enclave; private key material never leaves
- Symmetric crypto — AES-GCM encryption/decryption, CMAC, HKDF key derivation
- NV storage — tamper-resistant object store for keys, certificates, counters, and arbitrary data
- CryptoCb integration — register the HSM as a wolfcrypt CryptoCb device so existing wolfcrypt code routes operations to the HSM transparently
- RustCrypto traits —
EccP256KeyandEd25519Keyimplementsignature::Signer
Why
Why wolfHSM?
wolfHSM is self-contained (depends only on wolfSSL/wolfCrypt), compiles to a small footprint, and is designed from the ground up for embedded and automotive HSM targets. The client library is portable C that is straightforward to wrap.
Why this crate?
wolfhsm adds the Rust guarantees the C API cannot express:
- RAII key management — cache slots are always released on drop, even if the closure returns
Err - Typed key handles —
EccP256Key,RsaKey,AesKeyprevent mixing key types at compile time Resulteverywhere — no raw C return code checking in application code- RustCrypto interop — use HSM keys anywhere a
signature::Signeris accepted
How it works
Crate stack
wolfhsm-src Compiles the wolfHSM C client library from source via the
│ cc crate; emits DEP_WOLFHSM_SRC_{INCLUDE,LIB} for downstream
│
wolfhsm-sys bindgen-generated FFI bindings to wh_client.h and friends;
│ also compiles C shims for key operations (wolfcrypt structs
│ are zero-sized in the Rust FFI and must be stack-allocated
│ on the C side)
│
wolfhsm Safe Rust API — Client, typed key handles, NVM, counters,
CryptoCb, RustCrypto trait impls (this crate)
Communication model
Your app (Rust) → wolfhsm → wolfHSM C client lib → TCP/UDS/SHM → wolfHSM server
The server is a separate process (or secure element firmware). This crate handles the client side only. The server must be started independently before calling Client::connect.
Quick start
= { = "0.1" }
use ;
let mut client = connect?;
// Generate a P-256 key, sign, then evict — guaranteed even on error.
let digest = digest;
let sig = client.with_ecc_p256_key?;
Crypto operations
| Operation | API |
|---|---|
| ECC P-256 keygen, sign, verify, ECDH | Client::with_ecc_p256_key |
| RSA keygen, raw op, public key export | Client::with_rsa_key |
| Ed25519 keygen, sign, verify | Client::with_ed25519_key |
| AES-GCM encrypt/decrypt | Client::with_aes_key |
| CMAC | Client::with_cmac_key |
| CryptoCb device registration | CryptoCbGuard |
EccP256Key also implements signature::Signer<p256::ecdsa::DerSignature> via EccP256Key::signer().
Key management
Key handles hold a cache slot on the HSM server. The closure-based API ensures slots are always released:
client.with_ecc_p256_key?;
// Cache slot is evicted here, whether the closure succeeded or failed.
NVM
Persistent key and object storage on the HSM:
client.nvm_add?;
let data = client.nvm_read?;
client.nvm_erase?;
Feature flags
| Feature | What it enables |
|---|---|
cert |
Certificate management (wh_Client_Cert*) — store, read, and verify DER certificates against trusted roots in NVM |
auth |
Authentication and user management (wh_Client_Auth*) |
she |
SHE (Secure Hardware Extension) automotive key management |
mldsa |
ML-DSA (Dilithium) key support; requires HAVE_DILITHIUM in the linked wolfSSL |
Transport
| Variant | Description |
|---|---|
Transport::Tcp |
TCP/IP socket |
Transport::Uds |
Unix domain socket |
Transport::Shm |
POSIX shared memory (same host, zero-copy) |
Building
Requires a wolfHSM source tree and a compiled wolfSSL:
wolfSSL must be built with WOLF_CRYPTO_CB enabled. See the workspace README for full build instructions.
References
Copyright
Copyright (C) 2006-2026 wolfSSL Inc.
wolfHSM is copyright wolfSSL Inc. and its contributors.
License
GPL-3.0-only OR LicenseRef-wolfSSL-commercial
This crate is available under the GNU General Public License v3.0. For proprietary or commercial use where the GPL is not acceptable, a commercial license is available from wolfSSL Inc.
wolfHSM itself is licensed under GPL-2.0-or-later or a commercial wolfSSL license.