The opaque card-identity principle. HAV operates on an opaque
card-identity field R_x whose internal format is defined by the issuing bank.
R_x may be a network token (VTS, MDES), a bank-internal alias, or any other
identifier the bank uses to denote the cardholder's payment instrument. HAV cryptographically
binds R_x to the customer's hardware-rooted K_d, regardless of
R_x's internal structure. This is the reason HAV is bank-agnostic and
network-token-agnostic.
Card-identity layer
R_x- The card identity. Whatever 16/15-digit value the issuing bank uses to represent the
cardholder's payment instrument. HAV treats it as opaque bytes — bank-internal PAN,
VTS/MDES network token, or alias, all flow through the same path.
- PAN
- Primary Account Number. The actual 16-digit number embossed on the card. In a real
production bank, the PAN never leaves the issuing bank's HSM in plaintext.
- VTS
- Visa Token Service. Visa's network-tokenization platform that issues merchant-specific
16-digit tokens to replace the real PAN. A VTS token looks like a Visa card number but
is generated by Visa and bound to a specific merchant + PAN combination.
- MDES
- Mastercard Digital Enablement Service. Mastercard's equivalent of VTS. Issues
merchant-specific 16-digit tokens that replace the real Mastercard PAN.
Hardware-rooted keys (lives in your laptop's TPM 2.0 silicon)
EK — Endorsement Key- A non-exportable RSA/ECC key burned into your TPM at manufacturing time. Identifies
the silicon to the manufacturer's root certificate (Intel OnDie CA, AMD, NXP, etc.).
Never leaves the chip.
K_attest — Attestation Key- A TPM-generated key used to sign attestation statements about other TPM keys.
Created during Step 2 (Bind Hardware). Proves to the bank that other keys
(like
K_d) really live in real silicon.
K_d — Device Signing Key- A non-exportable RSA/ECC key generated inside the TPM during Step 2.
The key that actually signs every payment authorization. Cannot leave the chip,
cannot be cloned, cannot be exfiltrated by malware. The whole security
model rests on K_d being trapped in silicon.
TPM 2.0- Trusted Platform Module v2.0. The hardware security chip in every modern laptop
(since ~2016). Provides isolated key generation, sealed storage, and remote
attestation. The cryptographic root HAV depends on.
Continuity chain (the cryptographic story of the card)
H_b — Binding genesis hash- The hash that anchors a card to a device. Computed at Step 3 as
H_b = hash(K_d_pub, R_x_canonical, enrollment_id). Permanent record
of "this card was linked to this hardware on this date". When the card is revoked
and re-bound later, a fresh H_b is computed for the new binding;
the old H_b remains in the audit log as historical record.
H_n — Authorization-chain hash- Each payment advances the chain:
H_n+1 = hash(H_n, action_canonical, signature).
The chain is per-card-per-device. H_n[1] is the first authorization,
H_n[2] the second, and so on. Replaying or skipping a chain link fails
verification — making forgery cryptographically impossible.
- Sequence 1 and the "prior" hash
- You may notice the PDF for a first authorization shows a non-zero
H_n prior. That is by design: the prior for sequence 1 IS the
binding genesis H_b. Anchoring the chain to H_b
from byte 1 prevents null-state attacks where an attacker could mint a fake
"sequence 1" HAV with arbitrary prior data. Because H_b depends on the
real K_d_pub + R_x + enrollment_id, an
attacker would need access to the actual silicon to produce a valid first link.
Infrastructure signing & timestamping
K_infra- HAV's infrastructure-side ECDSA P-256 signing key, managed by Cloudflare. Signs
every HAV credential body so a relying party can verify "the HAV infrastructure
observed and recorded this authorization under policy v1" — a layer above the
customer's
K_d signature.
ES256- ECDSA using P-256 curve and SHA-256 hashing. The signing algorithm used for
K_infra signatures. Industry standard for JWT, WebAuthn, etc.
QTSP — Qualified Trust Service Provider- An EU-regulated timestamping authority. Issues RFC 3161 timestamp tokens proving
"this data existed at this exact UTC moment". HAV uses
DigiCert
in this demo; production deployments would use a paid eIDAS-qualified QTSP.
RFC 3161- The IETF standard for time-stamp protocols. Defines how to request a signed timestamp
for arbitrary data from a QTSP, and how to verify it. The mechanism that gives
HAV credentials legal admissibility in court.
Crown Code (the deterministic math engine)
- Crown Code C1
- HAV's integer-only, zero-heap C library compiled to WebAssembly. Computes the
canonical hashes used in
H_b and H_n. Produces bit-identical
output across 30+ languages and platforms (Cloudflare Workers, ESP32, STM32, etc.) —
the same calculation runs identically everywhere.
- Canonical JSON
- A deterministic serialization of a JSON object: keys sorted, no whitespace, no
ambiguity. Two different machines producing the same canonical bytes from the same
object is what lets the cryptographic chain stay verifiable.