Hardware-Rooted Identity for Machines: TPMs, Enclaves and Passkeys

Most distributed systems identify a machine by a private key in a file. That file gets backed up, baked into an image, copied to a replacement server, pasted into a CI secret and occasionally committed to a repository. Each copy is a machine that can sign as the original. In a network where machines take payments, sign inference receipts and vote on finality, an identity that can be copied is an identity that can be multiplied.

Tenzro takes the opposite default: every identity is derived from a key that cannot leave hardware. This post explains the hardware involved, what it proves and does not prove, and how the design handles machines that lack it.

Three kinds of hardware key

TPM 2.0. A Trusted Platform Module generates and holds keys that cannot be exported in the clear, and signs with them on request. Discrete TPMs, firmware TPMs in modern CPUs and virtual TPMs in confidential VMs all implement the same interface. Each TPM also carries an endorsement key with a certificate from its manufacturer, defined in the TCG EK credential profile, which lets a verifier check that a key lives in a genuine TPM from a known vendor.

Secure Enclave. Apple's Secure Enclave is an isolated subsystem that generates and uses P-256 keys without exposing them to the application processor.

Passkeys. For people, WebAuthn credentials (passkeys) keep a private key in the device's authenticator, scoped to a relying party and unlocked by user verification. NIST's supplement on syncable authenticators accepts properly configured synced passkeys at AAL2, while reserving AAL3 for device-bound hardware authenticators.

All three sign with ECDSA P-256 and none will hand over the key. That shared property is what Tenzro builds on.

Identity derived from the key, not assigned to it

A machine's identifier on Tenzro is derived from the public half of its hardware P-256 key (did:tenzro:machine:...), and a person's from their first passkey (did:tenzro:human:...). Because the identifier is a function of the key, a verifier needs no directory lookup to connect a signature to an identity, and nobody can register someone else's key under a new name.

From that one root, a machine gets everything else it needs without storing another long-lived secret:

• A node key for peer bindings and availability attestations, derived from the same hardware.
• Per-boot session keys, held only in memory, which the hardware key certifies. Signing receipts and votes with a certified session key keeps the hot path fast while every signature still traces to the hardware.
• A post-quantum leg. Where the hardware root supports it, an ML-DSA-65 key is derived from the hardware root for each signature and wiped afterwards, so a composite signature carries both a classical and a post-quantum component.
• A transport identity. The node's network endpoint key is generated fresh at every boot; the hardware key signs a short-lived record vouching for it.

There is deliberately no software fallback. A machine without a hardware key cannot validate; it can follow the chain as a full node. Random identities are not generated as a substitute.

Is the TPM genuine?

A signature from "a TPM" is only as good as the evidence that it really is one. Tenzro keeps a governed list of TPM endorsement roots. The public genesis is seeded with the EK root certificates the major TPM vendors publish, fetched from each vendor's own site: Infineon, STMicroelectronics, Nuvoton, Intel's firmware TPM and AMD's firmware TPM. A machine whose endorsement certificate chains to one of them counts as a manufacturer-certified TPM for admission, key certification of serving nodes and TPM-backed credentials.

The list is a record, not a constant. Governance adds or retires roots with a policy update once a proposal passes. Where a vendor has not published a root, the list says so rather than guessing: firmware TPMs on NVIDIA Jetson modules had no publicly published manufacturer root when the list was assembled, so none is seeded until one is.

Machines without a TPM

Small boards are where the principle gets tested. A Raspberry Pi has no TPM. Rather than allow a key file "just for small devices", a Pi keeps its identity key in another machine's TPM: one machine serves its TPM to the network, and the Pi signs through it. Every signature is a round trip to that provider, which costs latency but keeps the rule intact. The light build of the node includes this remote-TPM client for exactly this case.

People: passkeys and many wallet providers

A person's account is their devices plus a keystore in consensus state listing the passkeys allowed to act for it, its policy and its recovery signers. Each passkey records the relying party it was registered with, and its assertions are checked against that relying party alone, so several independent wallet providers can serve the same account once an existing passkey approves linking. No single domain is part of consensus.

Synced passkeys are allowed, with independence counted honestly: passkeys held by one sync provider count as one root of control, and each device-bound credential counts as its own. Recovery uses a set of independent signers, not a split or escrowed copy of a key. For signed trust documents (certifications, ratings, operator policies), synced passkeys are refused and user verification is required.

What hardware identity does not prove

A hardware key proves that a signature came from a particular chip that holds the key. It does not prove what software asked for the signature, where the chip is, or that the operator is honest. Those need other tools: measured boot and remote attestation for the software, facility claims for location, and bonds and slashing for behaviour. Tenzro keeps these separate and does not let a TEE stand in for key custody. A TEE proves what code ran, but anyone with the same image can reproduce what it derives, so wallet, bridge and agent keys live in a TPM, Secure Enclave or passkey.

Try it

On a machine with a TPM or Secure Enclave, the CLI prints the identity its hardware key derives, creating the key on first use:

tenzro trust whoami --key-label issuer

What this means for hardware makers and operators

For hardware manufacturers, a published EK root is the difference between a device that can be admitted as certified and one that cannot; publish it and keep it reachable. For operators, plan for the TPM as a hard requirement on validators and as a strong default everywhere else. For policy makers, identities that cannot be copied make accountability tractable: a signature maps to a device, and a device maps to whoever registered it.

Where Tenzro fits

Built: identities derived from TPM, Secure Enclave and passkey keys; hardware-certified session keys; composite ML-DSA-65 and P-256 signatures where the hardware root supports it; a governed list of vendor EK roots seeded from vendors' own publications; remote TPM signing for boards without one; and passkey keystores with per-relying-party verification across multiple wallet providers. The network is live in preview; governance decides the steps to testnet and mainnet, including changes to the EK root list.