Hardware-rooted identity

Abstract

On Tenzro Network 1, every identity and every key is rooted in hardware. People hold passkeys on their devices. Machines hold keys rooted in a TPM 2.0 or a Secure Enclave. Each identity's DID is derived from its key, so the identifier and the key cannot drift apart. Every passkey operation is a hybrid P-256 and ML-DSA-65 signature, and the post-quantum key is bound to the account. Users link more devices, recover with a second passkey or with guardians behind a timelock and veto, and delegate narrowly scoped authority to agents. There are no key files, no seed phrases and no custodian.

This paper specifies the identity model: roots of trust, DID derivation, hybrid signatures, device linking, recovery, delegation to agents, credentials and interoperability.

1. Introduction

An agent with a budget and a stolen key can spend at machine speed. A seed phrase written on paper, a key file on a disk or a secret in an environment variable can each be copied without anyone noticing, and copying it makes the copier the owner. The Machine Economy needs identities whose keys cannot be copied off the device that uses them, whose identifiers prove which key they belong to, and whose authority can be delegated to software without handing over the account.

Tenzro's answer is device custody: keys are rooted in the secure hardware people and machines already own.

2. Roots of trust

2.1 Passkeys

A passkey is a WebAuthn credential. Tenzro requires user verification on every passkey operation: a biometric or device PIN, not merely presence.

Passkeys come in two kinds, and Tenzro treats them differently:

• Device-bound passkeys cannot be copied off the authenticator. They carry the full tier and may be the sole root of an account.
• Synced passkeys, which a platform copies between a user's devices, are accepted at a lower tier. They carry lower limits and are never the sole root of an account: an account whose only passkey is synced must also have a second, device-bound passkey or guardians.

The tier is recorded in the identity so applications and spending policies can treat the two differently.

2.2 TPM 2.0 and Secure Enclave

A machine's identity is rooted in its TPM or Secure Enclave. Signing keys are derived from the hardware root on demand, used in memory and wiped after use. A host that cannot root a key in hardware is refused rather than given a key file.

2.3 What can anchor a machine

A machine identity must answer to something other than itself; otherwise it is a self-issued claim, indistinguishable from thousands more minted by the same script. Tenzro admits a machine under one of two anchors:

• Delegated: a person or organisation registered the machine and remains accountable for it.
• Hardware-rooted: an attestable root of trust, such as a TPM or a Secure Enclave, stands in the delegating party's place.

The distinction that matters is attestable versus merely unique. A model identifier names a design, not a unit. A fused serial number is unique per unit but readable by any software on the machine, so anyone who reads it can claim it. Only an attestable root proves possession without disclosing a secret, so only an attestable root can anchor an autonomous machine. Accelerators are never identity: a GPU is the most frequently swapped part of a machine, and an identity rooted in one would leave with the card.

Ownership moves on whatever anchors the machine. A delegated machine transfers on its controller's authority; a hardware-rooted one on proof of its root. Holding the hardware cannot take a machine that has an accountable party. Transfer authorisations are time-bounded so they cannot be replayed after the machine has changed hands.

3. DIDs derived from keys

Every identity has a W3C DID under the did:tenzro method.

The identifier is a deterministic function of the public key. Any verifier can check that a DID belongs to a key without a directory lookup, and enrolling the same key twice yields the same DID. An identity cannot be claimed by presenting someone else's key, and it cannot be created without one.

Every DID resolves to a DID document. The network serves a Universal Resolver-compatible endpoint at /1.0/identifiers/<did>, so any standards-compliant resolver client can resolve Tenzro DIDs without Tenzro-specific code.

4. Hybrid post-quantum signatures

Today's passkeys, TPMs and Secure Enclaves sign with P-256. A P-256 signature recorded today could be forged by a future quantum computer. Tenzro therefore pairs every passkey operation with an ML-DSA-65 signature.

• Composite and non-separable. The P-256 and ML-DSA-65 signatures are combined in a composite construction in the style of the IETF composite ML-DSA signatures. A signature is valid only if both legs verify over the same message and context, and neither leg can be stripped and reused alone.
• Bound to the account. The ML-DSA-65 public key is registered with the account when the account is created. A transaction whose post-quantum leg does not verify under the account's registered key is rejected.
• Rooted in the device. The post-quantum key is derived from the device's hardware root and used only for the account it is bound to. Where the hardware signs ML-DSA-65 natively, it does so.

The same composite construction is used for validator identity keys, described in Tenzro DAG Consensus.

5. Linking devices

A person rarely uses one device. Tenzro links devices to an identity the way a platform account links them, except the link is not held by a platform. What the network trusts is a signature from the existing device over a challenge the network chose, not a sign-in with any company's account.

1. The new device creates its own passkey or device key.
2. An already-linked device signs an authorisation to add the new key, naming the operation and the new key.
3. The network records the new key as a linked device of the same DID.

Sessions name the device that authorised them, not just the identity. Unlinking a lost phone therefore ends exactly the sessions that phone granted, in one action, and leaves the laptop still in the owner's hands signed in.

A person should link a second device before they have anything to lose. Two passkeys on one laptop are two ways into one box that a single failure takes together; a phone and a laptop are not.

6. Recovery

There is no seed phrase to restore from. Recovery uses what the owner holds:

• A second passkey. Any linked device can add a replacement device immediately.
• Guardians. The owner names guardians in advance: other people, organisations or devices. Guardian recovery runs behind a timelock.

Guardian recovery proceeds in five steps:

1. Initiate. A new device presents a fresh passkey and requests recovery.
2. Notify. The owner is alerted that recovery has started.
3. Delay. A timelock runs, visible to the owner.
4. Veto. Any existing linked device can cancel the recovery instantly, without waiting.
5. Finalise. The guardians co-sign, and the new device is linked when the timelock ends unopposed.

An attacker who compromises a notification channel gains nothing: the alert is only an alarm, and the owner cancels with a device they still hold. An attacker who compromises fewer guardians than the threshold cannot complete recovery. An attacker who compromises enough guardians still faces the timelock and the owner's veto.

7. Delegation to agents

Agents act on behalf of people and organisations. Delegation lets an owner grant an agent exactly the authority it needs and nothing more.

7.1 The agent's own identity

A delegated agent has its own machine DID, bound to its controller's DID, and its own hardware-rooted key. The agent signs with its own key; it never holds the owner's key.

7.2 Delegation scope

A delegation scope states what the agent may do:

The scope is signed by the owner, bound to the agent's DID and checked when the agent signs, not after the fact.

7.3 On-chain enforcement

Smart accounts enforce delegation on the ledger with ERC-7579 validator modules: session keys, spending limits and recovery. A user operation must satisfy every installed module to be accepted. Payment gateways check the same scope before settlement, alongside any protocol mandate, so a payment must clear the mandate, the delegation scope and the account's spending policy.

7.4 Revocation

The owner can revoke a delegation at any time. Revoking a controller's authority revokes every agent delegated under it. Revocations propagate across nodes, and the record is preserved.

8. Credentials and compliance tiers

Identities carry W3C Verifiable Credentials: statements by an issuer about a subject, signed by the issuer's hardware-rooted key, with an expiry and a revocation status that anyone can check.

Compliance tiers come from credentials, not from a central registry. An identity's tier is derived from credentials issued by parties the relying application trusts. A regulated service can require a credential from issuers it recognises; an open service can require none. The same mechanism is used for models and operators, described in Trust and provenance.

Organisations can hold identities for each desk, fund or subsidiary, and can carry credentials that bind them to a legal entity identifier.

9. Signing in and interoperability

• Sign-In With Tenzro. Applications authenticate users with a message in the EIP-4361 (Sign-In with Ethereum) shape: the requesting domain, the address, a nonce, the chain, an issue time, optional expiry and the resources requested. The user's device signs it; the application verifies it against the resolved DID document. The application stores only the nonce.
• ERC-8004. Agent identities can be mirrored to ERC-8004 identity registries on EVM chains, so an agent registered on Tenzro is recognisable elsewhere, and settled payments can feed its reputation.
• Standards. DIDs follow W3C DID; credentials follow W3C Verifiable Credentials; passkeys follow WebAuthn.

10. Custody model

11. Security properties

• Nothing to copy. Keys are rooted in hardware. There is no file, phrase or environment variable that, if copied, becomes the account.
• Identifiers bound to keys. A DID derives from its key, so no one can claim an identity without the key.
• Quantum-safe signatures. Every passkey operation carries an ML-DSA-65 leg bound to the account.
• Scoped agents. Agents hold their own keys and only the authority their owner signed.
• Recoverable. A second device or guardians behind a timelock and veto restore access without a custodian.

12. Conclusion

Hardware-rooted identity gives people, agents and machines one model: a key in secure hardware, a DID derived from it, hybrid post-quantum signatures, linked devices, recovery without a seed phrase and narrowly scoped delegation. For hands-on detail, see Hardware-rooted keys, Device linking and recovery, Identity and Smart account policies.