A TPM does not have to be a separate chip. wolfTPM’s firmware-TPM (fwTPM) is the full TPM 2.0 command engine running as firmware on a processor you already have, speaking the same protocol a discrete TPM would. That turns “add a root of trust” from a board respin into a software port – and on the Zynq-7000 it lets us do something a discrete TPM cannot: derive the TPM’s root key from the chip itself.
The target: Zynq-7000
The Zynq-7000 (ZC702) pairs a hardened dual Cortex-A9 with FPGA fabric. This example runs bare-metal on a single A9 (ARMv7-A, 667 MHz) with DDR. For this example a host drives the Firmware TPM over UART with the same raw swtpm/mssim framing as our other ports, so the stock wolfTPM swtpm client works unmodified. The HAL (Cadence UART, Global Timer, cache/VFP, flat MMU) is wolfSSL-authored, with no vendor BSP.
The problem it solves: provisioning-free device identity
A TPM protects its non-volatile storage with an integrity key, and the usual question is where that key lives – fuses, flash, or provisioned at manufacture, each with its own secrecy burden. This example takes a different route: the NV integrity key is derived from the Cortex-A9 on-chip-memory (OCM) SRAM power-on state using wolfCrypt’s configurable SRAM PUF (a BCH fuzzy extractor plus HKDF). Nothing is stored – the key is regenerated from the physical quirks of that exact chip on every boot, and the persistent NV and PUF helper data live in QSPI flash. The board’s own SRAM is the secret, so two identical boards yield two different device-unique keys with no provisioning step at all.
What is in the example
The bare-metal HAL and swtpm/mssim command loop, the fwTPM clock and NV HALs (volatile RAM default, persistent QSPI opt-in), the OCM SRAM PUF integrity-key source with a synthetic regression, a hello image, and host-side clients. An optional post-quantum build swaps RSA + ECC for ECC + ML-DSA / ML-KEM. It is hardware-validated: the fwTPM boots, self-tests pass, and the PUF regenerates a stable device-unique key across power cycles.
Size, algorithms, and speed
With a hardened Arm core and DDR, the ZC702 runs the full TPM comfortably, and post-quantum is a measured build option rather than a stretch. Measured with the bundled wolfCrypt benchmark on one A9 (667 MHz, portable-C math, no NEON); the ML-DSA and ML-KEM figures use wolfCrypt’s small-memory paths (they trade speed for a smaller RAM footprint, so these are the conservative numbers):
| Operation | Result |
|---|---|
| RSA-2048 sign | 6.3 ops/sec |
| RSA-2048 verify | 364 ops/sec |
| ECC P-256 keygen | 92.5 ops/sec |
| ECDSA P-256 sign | 82.9 ops/sec |
| ECDSA P-256 verify | 46.0 ops/sec |
| ML-DSA-65 keygen | 237 ops/sec |
| ML-DSA-65 sign | 33.0 ops/sec |
| ML-DSA-65 verify | 238 ops/sec |
| ML-KEM-768 keygen | 999 ops/sec |
| ML-KEM-768 encap | 868 ops/sec |
| ML-KEM-768 decap | 655 ops/sec |
| SHA-256 | 19.3 MiB/s |
The post-quantum swap is not a penalty here: ML-DSA-65 signs about 5x faster than RSA-2048 (33 vs 6.3 ops/sec), and ML-KEM-768 key establishment and ML-DSA verification both sit in the hundreds-to-thousand ops/sec range – all well inside a TPM’s duty cycle. And this is all roughly an order of magnitude faster than the same firmware on a soft-core MicroBlaze V – comfortable headroom. See the example (Xilinx/fwtpm-zc702-a9) and PR #7.
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