Encrypted Bus Transfers, Multi-Vendor TPM Support, and TCG SPDM Binding
Your Secrets Are on the Wire
The Problem
Discrete TPM chips talk to the host CPU over physical buses: SPI, I2C, or LPC. By default, this communication is unencrypted. Security researchers have repeatedly demonstrated that an attacker with brief physical access can tap these buses with cheap hardware and read secrets in transit.
- SPI sniffing: Probes clipped to the SPI flash chip (which often shares a bus with the TPM) can capture encryption keys during boot. This has been done with a $5 Raspberry Pi Pico.
- LPC sniffing: An FPGA or logic analyzer attached to the LPC bus can intercept TPM unseal commands and extract disk encryption keys in real time.
- I2C interposing: I2C buses are similarly low-speed and unprotected, making them vulnerable to the same passive capture techniques.
These attacks apply to any system that stores keys in a TPM but transmits them in the clear, including SPDM identity keys used for device authentication and firmware verification.
How wolfTPM Closes the Gap
wolfTPM supports TPM 2.0 parameter encryption using AES-CFB, which encrypts all sensitive data in transit between the host and the TPM. With SPDM support, wolfTPM delivers two layers of protection:
- Secure storage: Identity keys live inside the TPM hardware and never touch system memory.
- Secure transmission: Every bus transaction is encrypted, meaning a logic analyzer sees only ciphertext.
wolfTPM’s SPDM implementation uses Algorithm Set B, the FIPS 140-3 Level 3 compliant suite: ECDSA/ECDHE P-384, SHA-384, AES-256-GCM, and HKDF-SHA384. All cryptographic operations are handled by wolfCrypt, wolfSSL’s FIPS 140-3 validated crypto engine.
Multi-Vendor TPM Support
wolfTPM is the first and only open-source SPDM implementation with native hardware TPM integration. Working in partnership with both Nuvoton and NSING, wolfTPM now supports SPDM on two TPM families.
| Feature | Nuvoton NPCT75x | NSING NS350 |
| Session mode | Identity key (ECDHE P-384) | Identity key + PSK |
| SPDM version | 1.3 | 1.3 |
| Algorithm set | Algorithm Set B | Algorithm Set B |
| SPDM control | GPIO-based enable/disable + HW reset | Command-based |
| Certification | — | FIPS 140-2 Level 1 |
Both vendors negotiate SPDM 1.3 and use the same Algorithm Set B for session establishment and encrypted data transport.
PSK Mode (NSING NS350)
The NSING NS350 supports an additional session establishment mode using a 64-byte pre-shared key. PSK mode replaces the ECDHE key exchange with symmetric key derivation, providing an alternative for environments where asymmetric key management is not preferred. PSK and identity key modes are mutually exclusive on the NS350. Both modes use the same AES-256-GCM encryption for all subsequent TPM commands.
TCG SPDM Binding
wolfTPM implements the TCG SPDM binding specification for secure TPM command transport. Once an SPDM session is established, every TPM command is wrapped in a VENDOR_DEFINED_REQUEST(“TPM2_CMD”) message and encrypted with AES-256-GCM. This is transparent to the application; existing TPM code works without modification.
The TCG binding also supports vendor-defined commands for key provisioning, status queries, and SPDM-only mode enforcement.
Why This Matters
The DMTF reference implementation (libspdm) has no TPM integration; it cannot store keys in hardware or encrypt bus transfers. It also requires dynamic memory allocation and pulls in a large dependency footprint, making it impractical for many embedded targets. wolfTPM is the only SPDM implementation that combines hardware TPM support, encrypted bus transfers, and embedded-first design in a single stack:
- SPDM device identity and firmware verification via wolfTPM’s spdm/ directory
- Hardware key protection via wolfTPM and the Nuvoton NPCT75x or NSING NS350, keeping private keys off system memory entirely
- Encrypted bus transfers via wolfTPM’s AES-256-GCM SPDM sessions, preventing the sniffing attacks described above
- PSK mode for symmetric key-based session establishment on NSING NS350
- TCG SPDM binding for transparent encryption of all TPM commands over SPI/I2C
- Embedded-first design zero dynamic allocation by default, fixed-size buffers, no external dependencies beyond wolfCrypt, and a ~28 KB .text footprint. wolfTPM’s SPDM runs on bare-metal, RTOS, and Linux targets with the same codebase. No other open-source SPDM implementation is designed for constrained environments.
Because the entire stack is built on wolfSSL and wolfCrypt, it carries a path to FIPS 140-3 certification through wolfCrypt’s validated module and DO-178C DAL A through wolfSSL’s safety-certified codebase, the highest levels of both standards.
The wolfTPM Security Stack
| Layer | What It Provides |
| SPDM Protocol | Device authentication, firmware verification, session key exchange, PSK support |
| TCG SPDM Binding | Transparent TPM command encryption, vendor-defined command framework |
| wolfCrypt | FIPS 140-3 validated crypto (ECDSA, ECDHE, AES-GCM, SHA-384, HKDF) |
| wolfTPM | TPM 2.0 API, parameter encryption (AES-CFB), key management |
| Nuvoton NPCT75x | Hardware key storage, tamper resistance, secure boot root of trust |
| NSING NS350 | Hardware key storage, PSK mode, FIPS 140-2 Level 1 certified |
Expanding SPDM Support
wolfTPM’s SPDM support now covers two TPM vendors, Nuvoton and NSING Technologies, with both identity key and PSK session modes. wolfSSL continues to work with TPM manufacturers to expand SPDM capabilities. The spdm/ directory is architected to support additional vendors and can be branched into a standalone repository for non-TPM SPDM use cases.
Contact support@wolfssl.com to discuss your use case.
Get Started
wolfTPM with SPDM support is available now at github.com/wolfSSL/wolfTPM.
If you have questions about any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247