ZK-PKI

Abstract

ZK-PKI is a blockchain-native, FIDO2-compliant Public Key Infrastructure implemented as a Substrate FRAME pallet. It provides hardware-anchored proof of personhood, certificate issuance, and lifecycle management without biometric surrender, centralized authorities, or trusted third parties.

The system is distinguished from existing PKI infrastructure by three properties: hardware-anchored Sybil resistance via TPM Endorsement Key deduplication; user-owned certificates as NFTs that issuers cannot burn; and composable trust chains with no universal trust assumption.

ZK-PKI addresses a gap that existing systems do not close. Worldcoin requires biometric surrender. Traditional PKI requires centralized Certificate Authorities. Token-weighted governance concentrates power in whales. ZK-PKI requires only that the user possess real hardware and pass their device's own biometric check — the biometric never leaves the device.

Motivation

2.1 The Sybil Problem on Public Blockchains

Public blockchains are permissionless by design. Any address can be created for near-zero cost. This makes Sybil attacks trivially cheap — one actor controlling thousands of identities can manipulate governance, drain faucets, and game incentive systems.

Existing approaches are inadequate. Token-weighted governance concentrates power in whales. KYC via centralized providers reintroduces the trusted third party problem. Biometric systems require surrendering permanent physiological data to an authority. Social graph attestation is gameable at scale.

2.2 The Hardware Anchor

Modern consumer devices contain hardware security modules that generate cryptographic keypairs inside tamper-resistant silicon. The TPM Endorsement Key is burned in at manufacture — it cannot be copied, extracted, or replicated in software. Every physical device has exactly one EK.

ZK-PKI uses this existing hardware infrastructure as the identity anchor. The cost of a Sybil attack scales directly with the cost of real hardware. A bot farm that wants N proof-of-personhood certificates must acquire N physical devices.

2.3 Why a Substrate Pallet

The Polkadot ecosystem lacks a native identity layer that is hardware-anchored, user-owned, and composable. Existing identity solutions either require off-chain trust or centralized issuers. A pallet-native PKI that is verifiable on-chain, hardware-anchored off-chain, and composable by default fills this gap. PNS2 names integrate directly with ZK-PKI certificates — a resolved name can carry proof that a real person controls it.

System Overview

3.1 Trust Hierarchy

ZK-PKI operates a three-tier trust hierarchy. Trust flows downward — roots issue to issuers, issuers issue to end users. There is no universal trust assumption at any tier.

3.2 Certificate Ownership Model

Certificates in ZK-PKI are NFTs owned by the end user's SS58 address. The issuer who minted the certificate cannot burn it. The issuer can suspend or invalidate the cert's presence in the lookup table — functionally revoking it from a relying party's perspective — but the NFT remains permanently in the user's possession.

This design separates two concerns that traditional PKI conflates: the credential's existence and the credential's validity. The user always owns proof that a cert was minted. Whether relying parties honor it is a separate question governed by the lookup table state.

3.3 Attestation Tiers

Certificate Structure

4.1 Thumbprint Computation

Every certificate is identified by a Blake2b-256 thumbprint computed on-chain at mint time. The thumbprint is derived from the canonical serialization of these fields in order:

Hash function: sp_core::blake2_256 — Blake2b variant, 256-bit output. Computed on-chain at mint time via pallet extrinsic. Thumbprint changes on any field modification, invalidating the cert.

4.2 Hot/Cold Record Split

Certificate storage is split into hot and cold records to minimize read cost for the common case. Relying parties read CertRecordHot for validity checks. CertRecordCold is only accessed for signature verification and HIP proof operations.

4.3 Certificate State Machine

The on-chain CertState enum has two states: Active and Suspended. The RPC layer derives two additional states — Expired and Purged — by comparing the current block against stored expiry and purge indexes. Compromise and Challenge are entity-level states on issuers and roots, not on individual certs, because a compromise event pertains to the issuing entity rather than any specific cert it issued. Relying parties compare mint_block against compromised_at_block to determine cert validity under a compromised entity.

4.4 Extended Key Usage

Attestation and Hardware Integrity

5.1 TPM Attestation Chain Verification

For Tpm-tier attestation the pallet verifies a full certificate chain from the device's endorsement key through the manufacturer intermediate to a known root. Current whitelist entries verified against real hardware:

• Samsung S3K250AF — intermediate hash captured from SM-G986U (Galaxy S20+, Android 13)
• AMD fTPM PRG-RN — intermediate hash captured from AMD Ryzen laptop (Lucy, Windows 11)
• STMicroelectronics ST33 dTPM (Revision 1.38) — intermediate hash captured from Linux laptop (Ubuntu)

The whitelist is hardcoded for Paseo and Kusama testnet. At mainnet the whitelist migrates to an on-chain governance-controlled registry.

5.2 EK Deduplication

The TPM Endorsement Key is a device-unique key burned in at manufacture and present in every TPM attestation statement. ZK-PKI extracts the EK public key from the attestation chain and uses its Blake2b-256 hash as the deduplication key.

At mint: the pallet extracts the EK from the attestation chain, computes blake2_256(leaf_spki_der) — the hash of the leaf EK certificate's SubjectPublicKeyInfo DER bytes, checks the EK registry for an existing active PoP cert, and rejects the mint if one exists. The EK hash is written to the registry atomically with the cert mint.

This mechanism means the cost of a Sybil attack scales with the cost of real hardware. A bot farm that wants N PoP certificates must acquire N physical devices with N distinct Endorsement Keys.

5.3 Hardware Integrity Proof

PoP-eligible certificates at schema version 2 and above require a Hardware Integrity Proof (HIP) on every signing operation. The HIP proves that the signing device is the same device that enrolled, and that its security posture has not degraded since genesis.

On TPM 2.0 (Windows via TBS and Linux via tpm2-tss), the HIP is a TPM2_Quote — a TPM-signed assertion over selected PCR values using an Attestation Identity Key. Both paths share verification code in zk-pki-hip; the TPM response format is identical across operating systems, only the client-side transport differs. Verification checks:

• blake2_256(leaf_spki_der) == genesis.ek_hash — hash of the leaf EK certificate's SubjectPublicKeyInfo DER bytes matches genesis. This distinguishes individual devices rather than manufacturer roots.
• aik_certify_signature valid under EK — AIK was created under EK hierarchy (TPM2_Certify)
• quote_signature valid under AIK over SHA-256(TPMS_ATTEST) — correct TPM signing domain
• PCR 7 matches genesis value — Secure Boot state unchanged

Android StrongBox HIP proof uses a fresh attestation chain with hardwareEnforced RootOfTrust values compared against genesis fingerprint. Implementation pending ceremony tool completion — stubbed in current release.

5.4 PoP-Asserted Action Pattern

Every signing operation from a PoP-certified address carries a PopAssertion alongside the standard Substrate extrinsic signature. The assertion contains a cert_ec_signature over the call data plus a fresh nonce, and optionally a HIP proof.

The nonce is derived as blake2_256(parent_hash || cert_thumbprint || call_data) — client-computable before submission, unpredictable from the chain's perspective, and bound to the specific call being authorized.

Genesis Transaction Flow

6.1 Root Registration

A root entity registers by calling register_root with a valid hardware attestation payload and a proxy account that already exists in pallet_proxy. The pallet verifies the attestation chain, extracts and registers the EK, and writes the root record.

6.2 Issuer Issuance

A root issues an issuer certificate by calling issue_issuer_cert with the candidate issuer's address and the EKUs to grant. EKU capability inheritance is enforced — an issuer cannot be granted EKUs the root does not itself hold.

6.3 End User Certificate Mint

• Issuer creates a certificate template specifying PopRequirement, TTL bounds, maximum cert count, and EKUs
• Issuer calls offer_contract — pallet generates a unique block-bound nonce and writes the offer to ContractOffers storage
• User's device ceremony generates cert_ec keypair inside StrongBox/TPM. For PoP: TOTP secret generated atomically with keypair inside hardware
• User calls mint_cert with attestation payload, cert_ec public key, OTP (PoP only), contract nonce, and HIP proof (schema v2+)
• Pallet atomically verifies all inputs, computes Blake2b-256 thumbprint, mints NFT, writes CertLookupHot and CertLookupCold, registers EK hash, and distributes fees
• Contract nonce marked consumed atomically — replay impossible

6.4 Fee Distribution

Storage Architecture

7.1 Primary Storage

7.2 Secondary Indexes

Secondary double-maps enable O(1) trie prefix iteration for common query patterns without linear table scans:

• CertsByIssuer<(issuer, thumbprint) → ()>
• CertsByUser<(user, thumbprint) → ()>
• CertsByRoot<(root, thumbprint) → ()>
• UserIssuerIndex<(user, issuer) → thumbprint>
• IssuerTemplateNames<issuer → BoundedVec<n>>
• TemplateActiveCertCount<(issuer, name) → u32>

7.3 Pre-Scheduled Expiry and Purge

ZK-PKI uses pre-scheduled indexes to achieve O(1) on_initialize operations:

• ExpiryIndex<block → BoundedVec<thumbprint>> — pre-scheduled at mint. on_initialize flips state to Expired at the target block.
• PurgeIndex<block → BoundedVec<thumbprint>> — pre-scheduled at suspension/expiry. on_initialize removes cert records at the purge block.

The 30-day inactive purge window (432,000 blocks at 6-second block time) prevents the lookup table from becoming a permanent record of abandoned identities. This window was tightened from 60 days during red-team remediation to shorten the period an adversary could exploit a stale deposit. Anyone can call cleanup on an expired cert past the grace window and receive the full deposit as a bounty — chain hygiene is economically self-sustaining.

Compromise Handling

8.1 Issuer Compromise

A root invokes invalidate_issuer to flag an issuer as compromised. The issuer's compromised_at_block is recorded as a write-once field. Certs minted before compromised_at_block retain their validity status. Certs minted on or after that block are implicitly compromised.

8.2 Root Compromise

Root compromise is a network-level event requiring OpenGov governance. No single actor — including the root itself — can write to RootCompromiseRegistry directly. The design prevents hearsay attacks where a bad actor falsely marks a legitimate root as compromised.

Certs minted before the root's compromised_at_block remain in the lookup table. Relying parties compare mint_block to compromised_at_block to determine validity. A root under active challenge during the 45-day contest window remains operational until the challenge resolves.

8.3 Device Loss and Recovery

ZK-PKI provides a two-tier self-discard mechanism:

• Standard path (hardware present): The user calls self_discard_cert with a PopAssertion — cert_ec signature plus HIP proof. Full hardware verification. Cert removed from lookup table, deposit returned, NFT remains.
• Recovery path (hardware lost): The user calls self_discard_cert with only their SS58 key and the cert thumbprint. The thumbprint is purged from the lookup table. The recovery event is recorded on-chain as an immutable, timestamped, public attestation that the user has declared their hardware lost. EK registry entry cleared — user can enroll a new device.

JSON-RPC API

The zkpki_ RPC namespace exposes lookup table queries for third-party verification without requiring direct chain access. Every cert resolution endpoint returns expiry status, is_active, and compromised_at_block explicitly.

FIDO2 Compliance

ZK-PKI is architecturally consistent with FIDO2 requirements. The TOTP secret is generated by and validated against the TPM — the TPM is the validation authority, not a server. This inverts the standard TOTP model in a way that strengthens rather than weakens the guarantee.

Pallet Extrinsics

ZK-PKI exposes 19 extrinsics across three functional groups.

11.1 Root and Issuer Management

11.2 Certificate Lifecycle

11.3 Template Management

Security Properties

12.1 Guarantees

• One active PoP cert per physical device — enforced by EK deduplication
• Private key never leaves hardware — cert_ec_pubkey is public key only, never private
• Cert immutability — thumbprint changes on any field modification, invalidating the cert
• Replay prevention — block-bound nonces consumed atomically at mint
• Non-repudiation — mint_block timestamp plus compromised_at_block enables retroactive validity determination
• Atomic state transitions — no partial updates across all 11 deposit sites
• Hardware integrity continuity — HIP proof required on every PoP cert signing operation

12.2 Explicit Non-Goals

• Not a universal trust system — trust is contextual, relying parties set their own thresholds
• Not revocable by issuers — users own their NFT cert permanently
• Not dependent on any single root — multiple roots coexist with independent reputation
• Not compatible with VMs for PoP claims — hardware attestation and EK deduplication required
• Not key-rotatable — certs are monolithic by design, device loss requires reissuance
• Not a DNS integration — see PNS2 specification

12.3 Known Limitations

• Redundant TPMs: devices with both fTPM and discrete TPM can mint two PoP certs from two different EKs. Mitigated by one-cert-per-device policy at the issuer template level.
• fTPM vs discrete TPM physical security: AMD fTPM and Intel PTT share silicon with the main CPU. Discrete TPMs (such as STMicro ST33, Infineon SLB) have stronger isolation guarantees. Both are accepted — relying parties may distinguish via attestation metadata.
• Android StrongBox HIP proof: implementation pending ceremony tool completion. Stubbed in current release.
• Weight benchmarks: 18 of 19 extrinsics carry measured weights from reference hardware (AMD Ryzen 9 5900HX). renew_cert retained as placeholder pending successor-signature bench harness. Full measured weights required before Kusama.
• OS/patch regression enforcement: current HIP verification covers PCR 7 (Secure Boot state) and AIK identity match against genesis. Full OS version and patch level regression policy is future work, targeted before Kusama.
• IANA PEN: assigned as 65612. OID arc: 1.3.6.1.4.1.65612.

Implementation Status

13.1 Completed

• All 19 pallet extrinsics implemented and tested
• 267 tests passing — 156 pallet workspace + 111 runtime (86 zk-pki-runtime + 25 paseo-runtime)
• no_std verified: zk-pki-pallet, zk-pki-primitives, zk-pki-hip all compile without std
• Real hardware validation: Samsung S3K250AF (Galaxy S20+), AMD fTPM PRG-RN (Ryzen laptop), and STMicro ST33 dTPM rev 1.38 (Linux laptop)
• TPM2_Quote HIP proof with correct signing domain (SHA-256(TPMS_ATTEST)) verified against real hardware on both Windows (TBS) and Linux (tpm2-tss)
• Linux TPM 2.0 HIP path implemented and wired end-to-end: client generates TPM2_Quote against dTPM, pallet verifies against genesis fingerprint in signing extrinsic, failed HIP check rejects the extrinsic
• Fee system with named holds (fungible::MutateHold, HoldReason::CertDeposit)
• Proxy validation wired to pallet_proxy via ValidateProxy trait
• EKU capability inheritance enforced across root to issuer to template
• PoP-asserted action pattern with two-tier self-discard
• Pre-scheduled expiry and purge indexes for O(1) on_initialize
• Hot/cold cert record split for read-optimized relying party queries
• Paseo runtime end-to-end verified with production Config values
• Weight benchmarks: 18 of 19 extrinsics measured on AMD Ryzen 9 5900HX reference hardware

13.2 Deferred — targeted before Kusama

• Android StrongBox HIP proof ceremony — stubbed, pending Android client
• Final renew_cert weight benchmark — placeholder pending successor-signature bench harness
• ink! EK trust chain registry contract — hardcoded whitelist sufficient for Paseo
• Reputation scoring off-chain worker
• NFT integration via pallet-nfts
• IANA PEN OID 65612
• Full OS version and patch-level regression enforcement in HIP (current enforcement covers PCR 7 Secure Boot state and AIK identity match)

13.3 Crate Structure

Hardware Whitelist Governance

The hardware whitelist — KNOWN_MANUFACTURER_INTERMEDIATES — governs which TPM and StrongBox manufacturer intermediate certificates are accepted for attestation chain verification. It is the trust root for all hardware attestation in ZK-PKI.

The whitelist is explicitly not governed by OpenGov token-weighted voting. Hardware attestation chain evaluation requires domain expertise in TPM security, Android hardware attestation, and X.509 certificate chain validation. Token holders do not generally possess this expertise.

References and Standards Compliance

• TCG TPM 2.0 Library Specification, Parts 1-4
• TCG EK Credential Profile for TPM Family 1.2 and 2.0
• FIDO2 / WebAuthn — W3C Recommendation
• RFC 5280 — Internet X.509 Public Key Infrastructure
• RFC 6960 — Online Certificate Status Protocol (OCSP)
• ISO/IEC 9594-8 — The Directory: Public-key and attribute certificate frameworks
• Android Keystore System — Google Hardware Attestation
• Apple CryptoKit / Secure Enclave documentation
• Substrate FRAME documentation — frame_support, frame_system
• SCALE Codec Specification — Parity Technologies