# Direct Anonymous Attestation: The Zero-Knowledge Proof Already in Every TPM
> TPM 2.0 names a zero-knowledge group-signature primitive in its spec. A billion chips ship it. Almost nobody verifies it. The story of why DAA won every standardization fight and lost every deployment one.
*Published: 2026-05-12*
*Canonical: https://paragmali.com/blog/direct-anonymous-attestation-the-zero-knowledge-proof-alread*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**Direct Anonymous Attestation is the zero-knowledge proof your laptop already has -- and never uses.** Every TPM 2.0 specification since 2014 names a group-signature primitive called `TPM_ALG_ECDAA`, with a normative command pair (`TPM2_Commit`, `TPM2_Sign`) and a mandatory curve (`TPM_ECC_BN_P256`). A TPM with ECDAA enabled can prove "I am a genuine TPM whose endorsement key was certified by a known issuer" without revealing *which* TPM and without an online third party in the verification path. ISO/IEC 20008-2:2013 Mechanism 4 standardizes it. FIDO Alliance bound it to authenticator attestation in 2018. WebAuthn Level 1 registered ECDAA as an attestation type carried inside the `packed` and `tpm` attestation statement formats in March 2019. Three years later, WebAuthn Level 2 removed it entirely. The TCG PC Client Platform TPM Profile made `TPM_ALG_ECDAA` optional in February 2020. Microsoft Azure Attestation, Windows Health Attestation, AWS Nitro, Apple App Attest, and Google Play Integrity all use Privacy-CA-shaped broker flows instead. This article walks the thirty-year cryptographic lineage, the TPM 2.0 normative surface, the FIDO ECDAA failure, and the structural reasons Microsoft chose brokers over math.
## 1. A Billion Chips, Zero Verifiers
Every TPM 2.0 Library Specification published since 2014 names a zero-knowledge proof of knowledge. The algorithm identifier `TPM_ALG_ECDAA` (value `0x001A`) appears in Part 2 (Structures). The command pair `TPM2_Commit` and `TPM2_Sign` appears in Part 3 (Commands). The mathematical construction appears in Part 1 Annex C.5. The mandatory curve is `TPM_ECC_BN_P256` (`0x0010`), a 256-bit Barreto-Naehrig curve picked specifically because it admits the asymmetric pairings the protocol needs [@tpm-library-spec]. A conforming [TPM 2.0 chip](/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) with ECDAA enabled can produce a signature that proves the chip is a genuine TPM whose endorsement key was certified by a known issuer -- without revealing *which* TPM, and without an online certificate authority sitting in the verification path. The cryptography is called Direct Anonymous Attestation, and the Wikipedia article notes that the construction is "implemented by both EPID 2.0 and the TPM 2.0 standard" [@wiki-daa].
Almost nobody uses it.
Microsoft Azure Attestation does not. Its public architecture document describes a certificate authority that ingests endorsement-key certificates and issues per-key JWTs with a special issuance policy [@azure-attestation]. The Windows Health Attestation Service does not. AWS Nitro Enclaves does not [@aws-nitro-attestation]. Apple App Attest does not [@apple-app-attest]. Google Play Integrity does not [@google-play-integrity]. WebAuthn Level 1 registered ECDAA as an attestation type carried inside the `packed` and `tpm` formats in March 2019; WebAuthn Level 2 in April 2021 removed it entirely [@webauthn-2]. The TCG PC Client Platform TPM Profile, the document that governs which TPM 2.0 algorithms an OEM must support to ship a Windows-class platform, made `TPM_ALG_ECDAA` and `TPM_ALG_ECSCHNORR` optional in v1.04 (February 2020) and has carried that designation through v1.07 RC1 (December 2025) [@tcg-ptp]. [Microsoft Pluton](/blog/pluton-a-tpm-on-silicon-microsoft-can-patch/)'s published surface, which enumerates the algorithms the security processor exposes through its TPM 2.0 personality, does not advertise ECDAA at all [@pluton].
The most thoroughly standardized hardware-anchored group-signature primitive in the history of platform security sits in firmware on a billion-plus machines and runs on almost none.
Why?
> **Key idea:** Direct Anonymous Attestation solves the same problem as a Privacy-CA -- prove the TPM is genuine without disclosing *which* TPM -- by moving the trust assumption from operational (the broker promises not to log) to cryptographic (the math forbids the issuer from learning). The interesting question is not whether the cryptography works. It is why an industry that spent thirty years building the math chose, in production, the architecture the math was meant to replace.
This article walks the answer in four moves. Sections 2 through 5 reconstruct the cryptographic lineage: the Privacy-CA architecture DAA was invented against (TPM 1.1, 2003), the group-signature pre-history that made the construction possible (Chaum-van Heyst 1991 through Camenisch-Lysyanskaya 2004), the Brickell-Camenisch-Chen breakthrough at ACM CCS 2004, and the seven-year evolution to the elliptic-curve scheme TPM 2.0 actually ships (Chen-Page-Smart, CARDIS 2010). Sections 6 and 7 walk the normative surfaces: the TPM 2.0 ECDAA command surface and the ISO/IEC 20008-2 / 20009-2 standards. Sections 8 and 9 are case studies in non-deployment: FIDO's three-year experiment with ECDAA-in-WebAuthn, and Microsoft's two-decade commitment to broker-mediated attestation. Section 10 names the open problems -- post-quantum DAA, confidential computing, the One-TPM-to-Bind-Them-All fix that has not made it into TCG text. Section 11 closes with a role-keyed practical guide and an FAQ.
timeline
title Direct Anonymous Attestation, 1991-2024
1991 : Chaum-van Heyst (EUROCRYPT)
: Group signature defined
1997 : Camenisch-Stadler (CRYPTO)
: Constant-size signatures
2000 : ACJT (CRYPTO)
: Coalition resistance
2004 : Brickell-Camenisch-Chen (CCS)
: Boneh-Boyen-Shacham short groupsigs
2005 : DAA-RSA added to TPM 1.2 rev 94
2007 : Brickell-Li EPID (WPES)
: Signature-based revocation
2008 : Brickell-Chen-Li (TRUST)
: First pairing DAA
: CMS asymmetric DAA proposed
2010 : Chen-Li (IPL)
: CMS proof flaw
: Chen-Page-Smart (CARDIS)
: The scheme TPM 2.0 ships
2013 : BFGSW (IJIS)
: User-controlled linkability model
: ISO/IEC 20008-2 / 20009-2
2014 : TPM 2.0 Library Spec
: ECDAA in firmware
2015 : Smyth-Ryan-Chen
: Retroactive BCC privacy bug
2018 : FIDO ECDAA v2.0
2019 : WebAuthn Level 1
: ecdaa attestation format
2020 : TCG PTP v1.04
: ECDAA made optional
2021 : WebAuthn Level 2
: ecdaa format removed
2024 : CoSNIZK
: Lattice DAA at 38 kB
To answer the question of why, we have to start where every TPM attestation story does -- with the architecture DAA was invented to replace.
## 2. The Privacy-CA Trap (1999-2003)
TPM 1.1, originally published by the Trusted Computing Platform Alliance in 2002 and taken over in April 2003 by the Trusted Computing Group that replaced it [@wiki-tcg], had a privacy story. The story was a broker called the Privacy Certificate Authority. The story had a single load-bearing flaw, and the field spent the next two decades writing papers about it.
The mechanism, paraphrased from the Wikipedia summary that itself paraphrases the TCG spec, is five steps [@wiki-daa]:
1. A TPM manufacturer embeds a 2048-bit RSA Endorsement Key (EK) at the time the chip is provisioned, along with a certificate `EKCert` signed by the manufacturer [@wiki-tpm].
2. The platform generates a fresh Attestation Identity Key (AIK) inside the TPM.
3. The platform sends `(EKCert, AIKpub, proof-of-binding)` to a Privacy-CA.
4. The Privacy-CA validates the EK certificate, confirms the binding proof, and issues `Cert(AIKpub)` signed by the CA.
5. The platform uses the AIK to sign actual attestations -- platform configuration register quotes, boot logs, key-attestation certificates -- and presents `Cert(AIKpub)` to relying parties as proof that the AIK is TPM-resident.
The Endorsement Key is the long-lived, manufacturer-certified asymmetric key burned into the TPM at provisioning. Its public half is the chip's permanent cryptographic identity; its certificate, signed by the manufacturer, is the platform's proof that the chip is a real TPM. The Attestation Identity Key is a short-lived TPM-resident key generated for signing attestation outputs. Because the EK is uniquely identifying, the AIK exists to absorb attestation traffic on the EK's behalf: the EK certifies the AIK once (or once per Privacy-CA), and the AIK does the signing thereafter [@azure-attestation].
The broker introduced by the TCG in TPM 1.1 to separate the unique-by-design Endorsement Key from the per-attestation Attestation Identity Key. The Privacy-CA verifies the EK certificate, attests that the AIK is bound to a real TPM, and issues a certificate on the AIK that the platform then uses to sign quotes. The privacy property is operational, not cryptographic: the CA promises not to log the linkage between EK and AIK [@wiki-daa].
The architecture has three structural problems, and the Wikipedia summary of the original TPM 1.1 design makes the most uncomfortable one explicit: "privacy requirements may be violated if the privacy CA and verifier collude" [@wiki-daa]. The Privacy-CA *can* link AIKs to EKs. It promises not to. That promise is enforceable by audit, by legal contract, by reputation, and by the threat of a regulator finding out. It is not enforceable by mathematics.
The other two problems are availability and concentration. Wikipedia again, on the TPM 1.1 design: "the privacy CA must take part in every transaction" [@wiki-daa]. Every AIK certification is a synchronous network round-trip to a single CA. The CA is therefore a high-availability target, a high-value attack target, and a high-throughput service obligation for whoever decides to operate one. The FIDO Alliance, fifteen years later, wrote down the operational consequences of that obligation with surprising frankness in its ECDAA Algorithm v2.0 specification [@fido-ecdaa-v2]:
"An alternative approach to 'group' keys is the use of individual keys combined with a Privacy-CA [TPMv1-2-Part1]. Translated to FIDO, this approach would require one Privacy-CA interaction for each Uauth key. This means relatively high load and high availability requirements for the Privacy-CA. Additionally the Privacy-CA aggregates sensitive information (i.e. knowing the relying parties the user interacts with). This might make the Privacy-CA an interesting attack target." -- FIDO ECDAA Algorithm v2.0 Implementation Draft, 2018
The FIDO document was written in 2018, but it is operating on a problem that was current in 2003. The Privacy-CA model concentrates the very identifiers it is supposed to anonymize. A regulator with a subpoena, an insider with a database query, or a successful attacker with persistent access can recover the linkage the CA promised to forget. In 2003 the TCG named the missing primitive -- a *direct* attestation scheme whose anonymity was guaranteed by math rather than a CA's promise -- and the cryptographic literature went to work on it.
The privacy-advocate criticism of the TPM in the 2003-2005 window came from a small but well-placed group. Ross Anderson at Cambridge had been writing critical surveys of trusted computing since 2002, both in a continuously updated TCPA FAQ [@anderson-tcpa-faq] and in a PODC 2003 paper "Cryptography and Competition Policy -- Issues with Trusted Computing" [@anderson-tcpa-paper]. Seth Schoen and the Electronic Frontier Foundation published a 2003 white paper, "Trusted Computing: Promise and Risk," on the privacy implications of trusted-computing-class identifiers [@eff-schoen-2003]. European data-protection authorities had begun studying TCPA in the same window [@anderson-tcpa-faq]. The DAA construction was, by 2004, a research community answer to these criticisms more than it was a TCG product requirement.
The Privacy-CA architecture is still production architecture in 2026. Microsoft Azure Attestation runs a Privacy-CA in everything but name. Its public documentation describes a CA-mediated flow whose five-step shape mirrors the TPM 1.1 Privacy-CA almost line for line: "A certification authority (CA) establishes trust in the TPM either via EKPub or EKCert... The CA issues a certificate with a special issuance policy to denote that the key is now attested as protected by a TPM" [@azure-attestation]. The full verbatim Microsoft Learn quote is reproduced in §9, where it anchors the Windows case study.
The same pattern repeats across every hyperscaler. AWS Nitro Enclaves issues PKIX certificates rooted in AWS-operated CAs that bind enclave measurements to instance identifiers [@aws-nitro-attestation]. Apple App Attest issues per-app device identifiers from Apple-operated infrastructure [@apple-app-attest]. Google Play Integrity ships integrity verdicts signed by Google-operated infrastructure [@google-play-integrity]. In 2026 the operational descendants of TPM 1.1's Privacy-CA broker run the production attestation surface of every consumer-grade cloud platform.
flowchart TD
M["TPM manufacturer"] -->|"signs EK with EKCert"| EK["EK in TPM"]
EK --> AIK["TPM generates AIK"]
AIK -->|"(EKCert, AIKpub, proof)"| CA["Privacy-CA"]
CA -->|"issues Cert(AIKpub)"| Plat["Platform"]
Plat -->|"AIK signs quote"| V["Verifier / Relying Party"]
CA -.->|"can link AIK to EK (promises not to)"| AIK
By 2003 the field had a name for the missing primitive: a direct attestation scheme that delivered the Privacy-CA's anonymity property cryptographically rather than operationally. What followed was an academic lineage that had been quietly building, for a decade and a half, the primitives that lineage required.
## 3. The Pre-History: Group Signatures Before DAA (1991-2003)
Direct Anonymous Attestation was invented in 2004. The primitive it was built from was invented in 1991, in a paper that had nothing to do with TPMs.
David Chaum and Eugene van Heyst presented "Group Signatures" at EUROCRYPT 1991 [@chaum-vh-1991]. The construction was a curiosity: a digital signature scheme in which any one of `n` group members could sign on behalf of the group, the verifier could check that *some* member of the group signed, and a designated *group manager* could, given a signature, recover the identity of the signer. The use case Chaum and van Heyst had in mind was organizational: a company spokesperson signs press releases on behalf of the company; the CEO can, if necessary, recover which spokesperson signed which release.
A digital signature scheme in which any one of `n` group members can sign on behalf of the group such that (i) verifiers can confirm "some member of the group signed this message" using a single group public key, (ii) verifiers cannot determine which member signed, and (iii) a designated group manager, holding a trapdoor, can *open* any signature to recover the original signer. Chaum and van Heyst introduced the primitive in 1991; the next decade was about making the construction efficient enough to deploy [@wiki-group].
The 1991 construction had a fatal practical property: signature size was linear in the size of the group. A 10,000-member group meant a 10,000-component signature. For a primitive intended to handle organizational use cases at organizational scale, this was a non-starter. The next decade is a sequence of papers, each adding one property to the previous, each addressing the issue that made the previous unfit for deployment.
Jan Camenisch and Markus Stadler, at CRYPTO 1997, gave the field its first constant-size group signature -- signature length independent of the number of group members, suitable for groups of arbitrary size [@camenisch-stadler-1997]. Their construction relied on a particular kind of zero-knowledge proof of knowledge of a discrete logarithm whose form would, six years later, become the structural template for DAA's Sign protocol. The CS97 scheme had its own problems -- the security proof made strong assumptions, and the construction was vulnerable to "framing" attacks where a malicious group manager could forge signatures attributable to other members -- but the size barrier was broken.
Three years later, at CRYPTO 2000, Giuseppe Ateniese, Jan Camenisch, Marc Joye, and Gene Tsudik introduced what the field now calls the ACJT scheme [@acjt-2000]. The Springer abstract is unusually direct about what ACJT contributed: the paper "introduces a new provably secure group signature... proven secure and coalition-resistant under the strong RSA and the decisional Diffie-Hellman assumptions." The property that made ACJT important was *coalition resistance* -- a formal guarantee that no subset of `k` group members, no matter how large, could collude to produce a valid signature that did not open to one of them. ACJT's security proofs were the first in the group-signature literature to treat coalitions as a first-class threat model.
Coalition resistance as a property predated ACJT, but coalition resistance as a *formal* property -- something proven against an adversary defined in a complexity-theoretic model -- did not. Camenisch and Michels in 1998, and several authors in between, had given coalition-resistance arguments that depended on heuristic assumptions about the underlying hash function or signature scheme [@camenisch-michels-1998]. ACJT 2000 gave the proof under the strong RSA assumption, which by 2000 was a well-understood number-theoretic conjecture that the cryptographic community treated as a load-bearing security primitive.
ACJT was the construction the DAA designers built on. The reason is in its protocol structure. The ACJT signer holds a *signed credential* on a secret membership value `f`. Signing a message means producing a non-interactive zero-knowledge proof of knowledge of `(f, signature)` satisfying the group manager's verification equation, bound to the message. The proof is constant-size; the verifier checks it against the group public key and learns only that *some* member signed.
Jan Camenisch and Anna Lysyanskaya, working in parallel, were building the other primitive DAA would need. Their EUROCRYPT 2001 paper introduced what the field now calls CL credentials -- a digital signature scheme with two unusual properties [@cl-2001]. First, a signer can issue a signature on a *committed* value `Commit(f)` without seeing `f` itself, so the holder of `f` ends up with a signature on something the signer never learned. Second, a holder of `(f, signature)` can prove possession of that pair in zero knowledge, revealing neither `f` nor the signature itself.
A digital signature scheme with two algorithmic protocols on top of the standard sign-and-verify pair. A *blind issuance* protocol lets a signer issue a signature on a value the signer cannot see (the holder commits to a value `f` and proves the commitment well-formed; the signer signs the commitment without learning `f`). A *proof-of-possession* protocol lets a holder of `(f, signature)` prove "I have a CL signature from this signer on some value" without revealing either the value or the signature. CL signatures are the primitive a DAA Issuer uses to issue the long-lived attestation credential the TPM keeps after the Join protocol [@cl-2001] [@cl-2004].
CL signatures gave the field a clean way to issue a member credential without the issuer ever learning the member's secret -- exactly the property a TPM needs when receiving a long-lived DAA credential from an issuer who, by design, must remain unable to recognize the TPM later. Camenisch and Lysyanskaya's CRYPTO 2004 paper extended the construction to bilinear pairings [@cl-2004], a generalization that would matter for the elliptic-curve DAA schemes of the next decade.
flowchart LR
A["Chaum-van Heyst 1991 Primitive defined Linear-size signatures"] --> B["Camenisch-Stadler 1997 Constant-size signatures"]
B --> C["ACJT 2000 Coalition resistance Strong RSA + DDH"]
C --> D["Brickell-Camenisch-Chen 2004 DAA-RSA"]
A --> E["Camenisch-Lysyanskaya 2001 Blind issuance Proof of possession"]
E --> D
E --> F["Camenisch-Lysyanskaya 2004 CL on bilinear pairings"]
F --> G["Chen-Page-Smart 2010 EC-DAA"]
A sibling lineage was building in parallel. Dan Boneh, Xavier Boyen, and Hovav Shacham presented "Short Group Signatures" at CRYPTO 2004 [@bbs-2004]. The BBS scheme used bilinear pairings to compress group signatures to a few hundred bytes -- signatures, in the abstract's words, "approximately the size of a standard RSA signature with the same security." BBS gave the W3C Verifiable Credentials community a primitive that descendants like BBS+ would later use for selective-disclosure credentials. BBS itself did not become the TPM construction. The DAA designers, working from ACJT and CL, took a different path.
By 2003 the primitives existed. The TPM community had the use case. The two communities had not yet met. In 2004, three authors at three different industrial labs made the introduction.
## 4. The Breakthrough: DAA-RSA (Brickell-Camenisch-Chen, CCS 2004)
The introduction happened at ACM CCS 2004. Ernie Brickell at Intel, Jan Camenisch at IBM Zurich, and Liqun Chen at HP Labs Bristol published "Direct Anonymous Attestation" [@bcc-2004]. The IACR ePrint abstract makes the structural contribution explicit:
"Direct anonymous attestation can be seen as a group signature without the feature that a signature can be opened, i.e., the anonymity is not revocable. Moreover, DAA allows for pseudonyms, i.e., for each signature a user (in agreement with the recipient of the signature) can decide whether or not the signature should be linkable to another signature. DAA furthermore allows for detection of 'known' keys: if the DAA secret keys are extracted from a TPM and published, a verifier can detect that a signature was produced using these secret keys." -- BCC 2004 (IACR ePrint 2004/205)
Two design moves did the work, and naming them clearly is the first step in understanding why DAA solved the Privacy-CA problem.
The first move is a *subtraction*. Every prior group-signature scheme -- Chaum-van Heyst, Camenisch-Stadler, ACJT, BBS -- gave a designated group manager the power to *open* a signature and recover its signer. For a TPM attestation primitive, the opening capability is undesirable. An issuer who can open is morally a Privacy-CA: it has the linkage information the architecture is supposed to forget. BCC 2004 removes the opening capability entirely. No party can de-anonymize a signature -- not the issuer, not the verifier, not a coalition of either. The IACR ePrint 2004/205 abstract captures the consequence: DAA "can be seen as a group signature without the feature that a signature can be opened, i.e., the anonymity is not revocable" [@bcc-2004]. Once the credential is issued, the issuer has no cryptographic handle left to break the user's privacy.
A zero-knowledge attestation primitive in which a TPM holds a long-lived membership credential (the output of a one-time Join protocol with an Issuer) and can subsequently produce signatures that prove "the signing TPM holds a credential certified by this Issuer" without revealing which TPM signed and without an online third party in the verification path. No party -- not the Issuer, not the Verifier, not a coalition of either -- can de-anonymize a DAA signature. The construction first appeared in Brickell-Camenisch-Chen 2004 [@bcc-2004].
The second move is a *substitution*. Where prior schemes traced misbehaving signers by manager-controlled opening, DAA introduces a *user-controlled* linkability mechanism through what the BCC paper calls a basename-keyed pseudonym. The signing TPM holds a secret membership value `f`. The verifier supplies a *basename* `bsn` (a string the verifier picks per session, per relying party, or per global epoch). The TPM derives a pseudonym
$$N_V = \zeta^f \pmod \Gamma, \qquad \zeta = H_\Gamma(\text{bsn})$$
where `H_Γ` hashes the basename into a generator of a multiplicative group `Γ`. The pseudonym `N_V` has two structural properties. If the same verifier reuses the same `bsn` across sessions, signatures from the same TPM produce the same `N_V`, so the verifier can link them (and blacklist them if needed). If the verifier randomizes `bsn` per session, or sets `bsn` to the special value `⊥` indicating "no linkability," signatures from the same TPM produce different `N_V` values that are indistinguishable from random.
A DAA property in which the *verifier* chooses a basename `bsn` per session or per relying party. Signatures from the same TPM under the same basename produce the same pseudonym; signatures under different basenames produce pseudonyms indistinguishable from random. The TPM, not a group manager, controls which signatures are linkable to which others. The Bernhard-Fuchsbauer-Ghadafi-Smart-Warinschi 2013 paper gives the canonical formal model [@bfgsw-2013].
Together the subtraction and the substitution define the DAA contract. The Issuer issues a CL signature on the TPM's secret `f` during a one-time Join. The TPM thereafter holds the credential `(f, A, e, v)` -- the secret membership value plus the CL signature components. To sign a message `m` against a verifier-supplied basename `bsn`, the TPM:
1. Computes the pseudonym `N_V = ζ^f mod Γ` where `ζ = H_Γ(bsn)`.
2. Randomizes the CL signature: picks a fresh `w`, computes `T_1 = A · S^w mod n` and `T_2 = g^e · h^w mod n`.
3. Produces a Fiat-Shamir non-interactive zero-knowledge proof of knowledge of `(f, A, e, v, w)` satisfying the CL verification equation
$$A^e \equiv Z / (R^f \cdot S^{v' + v''}) \pmod n,$$
binding the proof to the tuple `(m, T_1, T_2, N_V)`.
A verifier checks the proof against the Issuer's public key. The verifier learns nothing about `f`, nothing about the TPM's identity, nothing about which CL signature was randomized -- and either gains a linkable pseudonym (if `bsn` was reused) or no linkability at all (if `bsn` was fresh).
The architectural picture, set against §2's Privacy-CA flow, makes the contrast vivid.
flowchart TD
I["Issuer (holds CL signing key)"]
T["TPM (holds secret f)"]
V["Verifier (holds Issuer pub key)"]
I -.->|"one-time Join CL signature on f (blind, issuer never sees f)"| T
T -->|"credential (f, A, e, v) stored in TPM forever"| T
T -->|"DAA-Sign(m, bsn) = randomized credential + NIZK + N_V"| V
V -->|"Verify against Issuer pub key (no online interaction)"| V
This is the first aha. The reader entered §3 thinking "anonymity with manager-controlled traceability" was the goal of group signatures. They exit §4 understanding that for TPM attestation the goal is *anonymity without any opener* plus *user-controlled, per-verifier linkability*. The breakthrough is structurally a subtraction (remove the opener) plus a substitution (per-verifier basename pseudonyms in place of manager-controlled opening). It is not an addition.
Eleven years after BCC 2004, Ben Smyth, Mark Ryan, and Liqun Chen ran a formal analysis of the original BCC construction and found a retroactive privacy bug [@smyth-ryan-chen-2015]. The bug allowed certain Issuer-coalition adversaries to link signatures across basenames in ways the original security argument had not anticipated. The bug was fixed in the 2008-2010 redesigns (specifically the BCL 2009 simplified-security-notions paper [@bcl-2009] and the CDL 2016 strong-Diffie-Hellman revisitation). The reader interested in why "we proved this in 2004" is not the same as "this is provably secure in 2026" should read SRC 2015 alongside the original BCC abstract.
On paper, the BCC 2004 construction solved the Privacy-CA trap. In practice, DAA-RSA was hard to ship. The CL signature in the original scheme used strong RSA moduli at 2048 bits. A single Sign operation took several seconds on the TPM 1.2 hardware of the time. The signature itself was approximately 2.5 kilobytes -- larger than the entire AIK signature output a Privacy-CA-mediated attestation produced. TPM 1.2 shipped DAA-RSA as an optional capability when revision 94 of the spec added it in 2005 [@tpm-library-spec]. Almost no platform integrator turned it on. The cryptography worked. The implementation budget did not.
The next decade was about making the construction small enough to deploy. The path was anything but straight.
## 5. The Evolution: From RSA-DAA to EC-DAA (2007-2013)
Six papers in seven years, two industrial branches, one dead end, one production scheme. Why was the EC-DAA story so much harder than it should have been?
The honest answer: the entire toolkit of pairing-based cryptography arrived at the same time the TPM industry needed it, and the field discovered in real time that not every choice of pairing was safe. The path from BCC 2004 to the construction the TPM 2.0 spec actually shipped runs through five waypoints, each addressing the problem the previous one created.
### 5.1 Brickell-Li 2007: EPID and signature-based revocation
In 2007 Ernie Brickell, now leading Intel's trusted-computing work, and Jiangtao Li published "Enhanced Privacy ID: A Direct Anonymous Attestation Scheme with Enhanced Revocation Capabilities" at WPES 2007 [@brickell-li-epid-2007]. The journal version appeared at IEEE TDSC in 2012 [@brickell-li-tdsc-2012]. The single feature EPID added was a revocation list called Sig-RL: a list of *signatures* the issuer wished to disavow. A verifier, given a signature `σ` and a Sig-RL containing entries `σ_1, ..., σ_k`, could prove that `σ` was not produced by the same TPM as any `σ_i` -- without learning the linking information itself.
EPID became Intel's production attestation primitive. Wikipedia records the deployment scale: "It has been incorporated in several Intel chipsets since 2008," and "at RSAC 2016 Intel disclosed that it has shipped over 2.4B EPID keys since 2008" [@wiki-epid]. EPID is what Intel SGX enclaves used to attest, before SGX attestation migrated to the vendor-CA DCAP architecture. EPID is what certain Intel-platform Widevine L1 implementations use to attest content-decryption modules. The Intel EPID SDK (the reference implementation) was eventually marked public-archive on GitHub [@epid-sdk]. The Wikipedia entry notes that the original EPID 2.0 specification was contributed by Intel into ISO/IEC 20008 and 20009 under royalty-free terms [@wiki-epid].
EPID is not exactly DAA. EPID is a DAA variant with the Sig-RL revocation layer added. The Chen-Page-Smart construction that TPM 2.0 actually ships is closer to BCC 2004 plus an elliptic-curve substrate; EPID 2.0 is closer to BCC 2004 plus EC plus Sig-RL plus Intel's specific basename and key-management conventions. The two converge at the cryptographic core and diverge at the deployment surface.
### 5.2 Brickell-Chen-Li 2008: the first pairing-based DAA
At the TRUST 2008 conference, Ernie Brickell, Liqun Chen, and Jiangtao Li published "A New Direct Anonymous Attestation Scheme from Bilinear Maps" -- the first DAA scheme constructed over bilinear pairings instead of strong RSA [@bcl-2008]. Signature size dropped by an order of magnitude relative to BCC 2004, from roughly 2.5 kilobytes to a few hundred bytes [@bcl-2008]. TPM-side sign time, on hardware that supported elliptic-curve arithmetic, came down from seconds to fractions of a second [@bcl-2008]. The construction used symmetric (Type-1) pairings -- pairings where the two input groups `G_1` and `G_2` are the same -- which the implementation community would, two or three years later, decide were too inefficient for production TPM hardware.
A function `e : G_1 × G_2 -> G_T` on three elliptic-curve subgroups satisfying *bilinearity* (for all integers `a, b` and points `P ∈ G_1, Q ∈ G_2`, `e(aP, bQ) = e(P, Q)^(ab)`) and *non-degeneracy*. Type-3 (asymmetric) pairings, in which `G_1 ≠ G_2` and no efficient homomorphism is known between them, are the production pairing for TPM 2.0 ECDAA because they admit faster implementations and tighter security reductions than Type-1 (symmetric) pairings. The Chen-Page-Smart 2010 construction is built on Type-3 pairings over Barreto-Naehrig curves [@cps-2010].
### 5.3 Chen-Morrissey-Smart 2008: the asymmetric proposal and its proof flaw
Pairing 2008 hosted the next move. Liqun Chen, Paul Morrissey, and Nigel Smart published "Pairings in Trusted Computing" [@cms-pairing-2008], proposing a DAA scheme on asymmetric Type-3 pairings -- the kind that admit Barreto-Naehrig curves and the speed-ups TPM hardware needed. The same authors published a companion ProvSec 2008 paper "On Proofs of Security for DAA Schemes" providing the security argument [@cms-provsec-2008].
Two years later, in Information Processing Letters, Liqun Chen and Jiangtao Li published "A note on the Chen-Morrissey-Smart Direct Anonymous Attestation scheme" [@chen-li-2010] showing that the CMS asymmetric-pairing construction had a flawed proof. The cryptographic intuition was correct; the proof technique used an assumption that did not hold in the asymmetric-pairing setting the construction relied on.
The Chen-Morrissey-Smart episode is, in 2026, one of the most cited proof-flaw stories in pairing-based cryptography precisely because the construction was simple and the flaw was subtle. The mathematical content of the scheme was salvageable. The security argument was not. The lesson the field took away -- a proof in the symmetric-pairing model does not transfer to the asymmetric-pairing model without a separate argument -- has been a load-bearing convention in cryptographic publishing since.
### 5.4 Chen-Page-Smart 2010: the scheme TPM 2.0 actually ships
The fix arrived at CARDIS 2010 in Passau in April 2010 [@cardis-book]. Liqun Chen, Dan Page, and Nigel Smart published "On the Design and Implementation of an Efficient DAA Scheme" [@cps-2010] [@cps-2010-eprint], proposing an asymmetric-pairing DAA over Barreto-Naehrig curves with a Sign protocol *split* between the TPM and the host. The TPM, in the new design, performed only the cryptographic operations that absolutely required custody of the secret `f`: it produced commitment points and computed a Schnorr-style response over those commitments. The host -- a comparatively powerful general-purpose CPU sitting in front of the TPM -- composed the Fiat-Shamir challenge, performed the pairing computations, and assembled the final signature.
The Chen-Page-Smart construction is the scheme TPM 2.0 actually ships. The Wikipedia DAA article makes the attribution direct, in a sentence that is itself the most-cited single primary-source extract in this article:
"Chen, Page, and Smart proposed a new elliptic curve cryptography scheme using Barreto-Naehrig curves. This scheme is implemented by both EPID 2.0 and the TPM 2.0 standard." -- Wikipedia, *Direct Anonymous Attestation* [@wiki-daa]
A family of pairing-friendly elliptic curves with embedding degree 12, parameterized by an integer `u` to admit Type-3 pairings whose arithmetic is fast enough for resource-constrained devices [@bn-2006]. The curve identifier `TPM_ECC_BN_P256` (`0x0010`) is the specific 256-bit instance the TPM 2.0 Library Specification mandates for ECDAA, picked because of its pairing-friendly structure rather than as a NIST P-256 equivalent.
Six years after CPS 2010, Taechan Kim and Razvan Barbulescu (CRYPTO 2016) published "Extended Tower Number Field Sieve: A New Complexity for the Medium Prime Case," giving an improved sieve attack against pairing-friendly elliptic curves at the 256-bit BN level. The improvement dropped the practical security of BN-256 from roughly 128 bits to roughly 100 bits [@kim-barbulescu-2016]. The TCG normative text for TPM 2.0 ECDAA did not, as of late 2025, change the mandatory curve in response. This is the kind of cryptographic technical debt that lives quietly in deployed systems for a decade -- specs do not migrate on the same calendar as research moves.
### 5.5 BFGSW 2013 and SRC 2015: the formal closure
The cryptographic engineering of EC-DAA was done by 2010. What the field still owed itself was a clean security model: one definition of "secure DAA" that captured the user-controlled-linkability property and the TPM/host split, against which any candidate scheme could be evaluated.
In 2013 David Bernhard, Georg Fuchsbauer, Essam Ghadafi, Nigel Smart, and Bogdan Warinschi published "Anonymous attestation with user-controlled linkability" in the *International Journal of Information Security* [@bfgsw-2013] [@bfgsw-2013-eprint]. The BFGSW paper formalized the user-controlled-linkability property the BCC 2004 abstract had described in prose, introduced a clean separation of "pre-DAA signing" (TPM-side operations) from "DAA signing" (TPM + host composition), and proved the security of a representative construction in the resulting model.
In 2015, Ben Smyth, Mark Ryan, and Liqun Chen published the retroactive analysis that closed the BCC 2004 privacy bug [@smyth-ryan-chen-2015]. By 2015 the cryptography was, formally, settled.
In 2016 Jan Camenisch, Manu Drijvers, and Anja Lehmann revisited the construction at TRUST 2016 in "Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited" [@cdl-2016] [@cdl-2016-eprint], giving a tighter security argument under the q-SDH assumption and providing a fix for a Diffie-Hellman-oracle issue in the TPM 2.0 ECDAA interface that "One TPM to Bind Them All" would document in 2017 [@one-tpm-2017]. The CDL16 scheme is what most modern DAA library code references as the canonical construction.
flowchart LR
BCC["BCC 2004 RSA-DAA TPM 1.2"] --> BL["Brickell-Li 2007 EPID + Sig-RL Intel SGX / Widevine"]
BCC --> BCL["BCL 2008 Type-1 pairing DAA"]
BCL --> CMS["CMS 2008 Asymmetric pairing (broken by CL 2010)"]
BCL --> CPS["CPS 2010 Type-3 BN-curve DAA TPM 2.0 ECDAA"]
CPS --> BFGSW["BFGSW 2013 Formal user-controlled linkability model"]
BFGSW --> CDL["CDL 2016 q-SDH revisitation Canonical modern DAA"]
BCC --> SRC["SRC 2015 Retroactive BCC privacy bug"]
By 2013 the cryptography was complete. The standards organizations took the construction and made it official -- in two different specifications, on two parallel tracks.
## 6. The TPM 2.0 ECDAA Surface (2014-Present)
If you own a Windows laptop with a TPM 2.0, this section is the part of the chip you have never used. What does the spec actually say?
The TPM 2.0 Library Specification, the canonical document published by the Trusted Computing Group, is a four-part normative reference [@tpm-library-spec]. Part 1 (Architecture) describes the threat model and the mathematical primitives. Part 2 (Structures) defines the data types every TPM command accepts and returns. Part 3 (Commands) defines the commands themselves. Part 4 (Supporting Routines) gives a reference C implementation. The ECDAA surface lives across all four parts.
An algorithm identifier defined in TPM 2.0 Library Specification Part 2 and selectable from any `TPMT_SIG_SCHEME` field. A signing key tagged with `TPM_ALG_ECDAA` produces signatures using the Chen-Page-Smart 2010 elliptic-curve DAA construction. The same algorithm identifier appears in any signature-scheme negotiation point in the TPM 2.0 command surface [@tpm-library-spec].
The 256-bit Barreto-Naehrig curve identifier the TPM 2.0 Library Specification mandates for any ECDAA-capable signing key. BN-P256 is *not* NIST P-256: it is a pairing-friendly curve with embedding degree 12 whose group structure admits the Type-3 pairings the DAA verification equation requires. Implementations that confuse the two will produce signatures that verify against the wrong group.
The command pair defined in TPM 2.0 Library Specification Part 3 that implements the Chen-Page-Smart 2010 split-protocol structure. `TPM2_Commit(keyHandle, P1, s2, y2)` returns commitment points `(K, L, E)` plus a `counter`. The host then computes the Fiat-Shamir challenge `c` over the message and the commitment points. `TPM2_Sign(keyHandle, digest, scheme=TPM_ALG_ECDAA, validation)` returns the Schnorr-style response `s = r + c·f mod p`. The host assembles the final signature from the commitment points, the challenge, and the response [@tpm-library-spec].
The protocol split matters. The TPM, in the CPS 2010 construction, holds the secret `f` and must perform exactly two cryptographic operations on it: produce a freshly randomized commitment to `f` (via `TPM2_Commit`), and produce a Schnorr response that proves knowledge of `f` modulo the verifier's challenge (via `TPM2_Sign`). Everything else -- the pairing computations, the curve arithmetic in `G_T`, the Fiat-Shamir hash, the final signature assembly -- happens on the host CPU. This is the *only* reason the construction is practical on a TPM. A monolithic Sign that did pairing arithmetic inside the chip would be unshippable; the split offloads the expensive operations onto silicon that has them for free.
> **Note:** The most common implementer mistake when working with TPM 2.0 ECDAA for the first time is to reuse the NIST P-256 ECDSA code path with the curve identifier swapped. The two curves share a bit length and a hash function and otherwise nothing. BN-P256 has a pairing-friendly group structure with embedding degree 12; NIST P-256 does not admit efficient pairings at all. Signatures produced by ECDSA over NIST P-256 will not verify against an ECDAA verifier expecting BN-P256, and the converse is true. The pairing requirement is what forces the BN curve choice; treat BN-P256 as a separate primitive with a separate code path.
The Join protocol -- the one-time exchange between the Issuer and the TPM that produces the long-lived credential -- piggybacks on a TPM 2.0 command pair already present in every Windows attestation flow: `TPM2_MakeCredential` and `TPM2_ActivateCredential` [@tpm-library-spec]. The Issuer wraps the DAA credential under an encryption key derived from the TPM's Endorsement Key, ensuring that only the legitimate TPM (the one that holds the EK private key) can decrypt the credential and bind it to its internal `f`.
The choice of `TPM2_ActivateCredential` as the Join anchor is convenient. The same primitive that TPM 2.0 attestation-key certification flows use for AIK-binding gets reused for DAA-credential binding. An OEM that supports `TPM2_ActivateCredential` for ordinary AIK enrollment already has 80% of the firmware path the Join protocol needs. The difference is in what the Issuer ships back -- a per-TPM AIK certificate in the AIK case, an Issuer-randomized CL credential in the DAA case.
Part 1 Annex C.5 contains the informative mathematical description -- the actual ECDAA verification equation, the basename-pseudonym derivation, the proof-of-knowledge template. Part 3 contains the normative command definitions. An implementer who reads only the Part 3 command definitions without reading Annex C.5 will have correct byte-buffer-level semantics and no idea what the protocol is computing; an implementer who reads only Annex C.5 without the normative command definitions will have correct math and the wrong API.
The implementation surface, gathered into one place:
| Artifact | Identifier / location | Source |
|---|---|---|
| Algorithm selector | `TPM_ALG_ECDAA = 0x001A` | TPM 2.0 Library Specification Part 2 [@tpm-library-spec] |
| Mandatory curve | `TPM_ECC_BN_P256 = 0x0010` | Part 2 [@tpm-library-spec] |
| First-round command | `TPM2_Commit(keyHandle, P1, s2, y2) -> (K, L, E, counter)` | Part 3 [@tpm-library-spec] |
| Second-round command | `TPM2_Sign(keyHandle, digest, scheme=TPM_ALG_ECDAA, validation) -> signature` | Part 3 [@tpm-library-spec] |
| Join anchor | `TPM2_MakeCredential` / `TPM2_ActivateCredential` | Part 3 [@tpm-library-spec] |
| Math description | Part 1 Annex C.5 (informative) | Part 1 [@tpm-library-spec] |
| Optionality status | Optional since PTP v1.04 (Feb 2020); carried through v1.07 RC1 (Dec 2025) | TCG PC Client Platform TPM Profile changelog [@tcg-ptp] |
sequenceDiagram
participant V as Verifier
participant H as Host (CPU)
participant T as TPM
V->>H: send basename bsn
H->>T: TPM2_Commit(keyHandle, P1, s2, y2)
T-->>H: (K, L, E, counter)
H->>H: compute c = H(K, L, E, message, bsn)
H->>T: TPM2_Sign(keyHandle, digest=c, scheme=ECDAA)
T-->>H: response s = r + c*f mod p
H->>H: assemble signature (K, L, E, c, s)
H->>V: ECDAA signature
V->>V: verify pairing equation
The TCG published the TPM 2.0 Library Specification in 2014. From 2014 through early 2020, the PC Client Platform TPM Profile -- the document that says "to ship a TPM 2.0 in a PC-class device, these algorithms must be present" -- listed `TPM_ALG_ECDAA` as mandatory-if-the-platform-supports-elliptic-curve-cryptography. In v1.04 (released February 2020) the TCG PTP working group made a quiet but consequential change. The changelog records the line verbatim: "Made TPM_ALG_ECDAA and TPM_ALG_ECSCHNORR optional." The same designation has carried through v1.06 RC1 (January 2025) and v1.07 RC1 (December 2025) [@tcg-ptp]. After February 2020, an OEM can ship a Windows-class TPM 2.0 platform that does not implement ECDAA at all and remain conformant.
> **Note:** The Trusted Computing Group's resource pages (`trustedcomputinggroup.org/resource/tpm-library-specification/` and `trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/`) reject non-browser User-Agents at the HTTP layer. This is a long-standing anti-bot policy. Citations in this article to the TPM 2.0 Library Specification and to the PC Client Platform TPM Profile point to the canonical URLs but are flagged in the verified-source registry as UNVERIFIED_FETCH; the verbatim changelog text was extracted under primary-source rules during the Stage 0a focus-premise audit and is the audit-of-record for the optionality claim. The downstream accuracy and fact-check stages of this pipeline carry the same caveat forward.
The Pluton question is the second hedge. Microsoft Pluton is the security processor Microsoft has been shipping in successive Windows-class platforms since AMD's Ryzen 6000 in 2022, in AMD Ryzen 7040 (Phoenix) in 2023, in Qualcomm Snapdragon X Elite in 2024, and in Intel Core Ultra (Meteor Lake, December 2023; Lunar Lake, September 2024) and successive Intel Core Ultra generations. Pluton exposes a TPM 2.0 personality. The Microsoft Learn documentation page enumerates the cryptographic algorithms the processor exposes and the platform-security primitives it implements [@pluton].
The page contains zero occurrences of `ECDAA` or `TPM_ALG_ECDAA`. The honest framing here is *not* "Pluton does not implement ECDAA" -- the documentation neither confirms nor denies it -- but "Pluton's published surface does not advertise ECDAA." That is the hedged statement this article carries from its opening to its FAQ.
The runnable demonstration below is *educational* -- Microsoft ships no `BCryptDirectAnonymousAttestation`, no `NCryptDaaSign`, no Windows API at all that exposes ECDAA from a user-mode application. The code shows the *logic* an admin or platform engineer would follow when probing a TPM's reported algorithm set, not a working call against any shipping Windows API.
{`
// Logic only. Microsoft ships no Windows API that surfaces TPM_ALG_ECDAA.
// In practice an admin would parse the output of Get-TpmEndorsementKeyInfo
// or use a vendor-specific tool to inspect the TPM's algorithm capability table.
const TPM_ALG_ECDAA = 0x001A;
const TPM_ECC_BN_P256 = 0x0010;
function probeECDAA(tpmAlgList, tpmEccCurveList) {
const hasECDAA = tpmAlgList.includes(TPM_ALG_ECDAA);
const hasBN256 = tpmEccCurveList.includes(TPM_ECC_BN_P256);
if (!hasECDAA) return 'no ECDAA: chip omits algorithm 0x001A';
if (!hasBN256) return 'ECDAA without BN-P256: nominally compliant, practically unusable';
return 'ECDAA + BN-P256 present (Join still requires Issuer infrastructure)';
}
// Example: a Pluton-class chip whose published surface does not advertise ECDAA.
const plutonLike = [0x0001 /* RSA */, 0x0008 /* SHA-256 */, 0x0023 /* ECDSA */];
console.log(probeECDAA(plutonLike, [0x0003 /* NIST P-256 */]));
// -> "no ECDAA: chip omits algorithm 0x001A"
// Example: a discrete Infineon SLB9670 TPM 2.0 (vendor docs list ECDAA + BN-P256).
const discreteTpm = [0x0001, 0x0008, 0x0023, TPM_ALG_ECDAA];
console.log(probeECDAA(discreteTpm, [0x0003, TPM_ECC_BN_P256]));
// -> "ECDAA + BN-P256 present (Join still requires Issuer infrastructure)"
`}
The spec was written. The chips shipped. The TCG was satisfied. So why does no one verify ECDAA signatures?
## 7. The Standards Bridge: ISO/IEC 20008 and 20009
There is a difference between a TCG specification section number and an ISO/IEC mechanism identifier. The difference is the price of admission to a Common Criteria protection profile and to most government procurement contracts.
ISO/IEC 20008 is the international-standards anchor for anonymous digital signatures. It comes in three parts. Part 1 ("General") sets the framework and terminology [@iso-20008-1]. Part 2 ("Mechanisms using a group public key") catalogues the specific anonymous-signature schemes the international community has standardized -- and Mechanism 4 is the EPID-derived elliptic-curve DAA construction that aligns with the TPM 2.0 ECDAA surface [@iso-20008-2]. Part 3 ("Mechanisms using multiple public keys") catalogues a different family of schemes that is not the focus of this article.
The international-standards series titled "Information technology -- Security techniques -- Anonymous digital signatures." Part 1 (general framework) and Part 2 (mechanisms using a group public key) were both published in 2013. Mechanism 4 in Part 2 standardizes EPID-derived elliptic-curve DAA. ISO/IEC 20008 is the bibliographic anchor cited by Common Criteria protection profiles, FIPS 140-3 module-validation evidence, and government procurement specifications that need to reference a *named, internationally agreed* anonymous-signature mechanism rather than a vendor-specific construction [@iso-20008-2].
A note on the title. Earlier drafts of this article carried the title of ISO/IEC 20008-2 as "anonymous signatures with message recovery." That phrasing belongs to a different standard, ISO/IEC 9796. The verified ISO catalogue title for 20008-2 is, verbatim, "Information technology -- Security techniques -- Anonymous digital signatures -- Part 2: Mechanisms using a group public key" [@iso-20008-2].
ISO/IEC 20009 is the companion standard for authentication. Where 20008 standardizes signatures, 20009 standardizes the challenge-response protocols that wrap signatures into entity-authentication exchanges. Part 2 ("Mechanisms based on signatures using a group public key") is where TPM-style attestation lives in ISO terminology [@iso-20009-2]. A FIDO authenticator or a TPM-backed Kerberos client that performs an attested authentication is, in ISO-speak, executing a 20009-2 mechanism that wraps a 20008-2 signature.
The procurement reason ISO standardization mattered is structural. A Common Criteria Protection Profile cannot, in the general case, reference a TCG specification section number. It can reference an ISO mechanism identifier. The Federal Information Processing Standards 140-3 evidence package for a cryptographic module must, in many cases, demonstrate that the cryptographic primitives the module implements are members of an internationally recognized standard family. The European Cyber Resilience Act, drafted in 2024 and applicable in stages from 2027 onward, treats compliance with a recognized international standard as one of the routes to a presumption of conformity. ISO/IEC 20008-2 Mechanism 4 is the door TPM 2.0 ECDAA walks through to be admissible in those regimes.
Standardization was complete by 2014. Cryptographic primitive: CPS 2010. Security model: BFGSW 2013. ISO mechanism: 20008-2 Mechanism 4. TPM normative surface: `TPM_ALG_ECDAA`, `TPM_ECC_BN_P256`, `TPM2_Commit`, `TPM2_Sign`. Every box was checked. The next question -- the one the standardization community could not answer on its own -- was whether anyone would write a verifier.
## 8. The FIDO Bet That Failed (2017-2021)
In 2018, the FIDO Alliance bet that ECDAA was the missing privacy story for [WebAuthn](/blog/webauthn-and-passkeys-on-windows-from-ctap-to-the-credential/). Three years later, W3C took the bet off the table.
The bet was not casual. FIDO had a real problem. WebAuthn authenticators -- the YubiKey hardware tokens, the [Microsoft Hello](/blog/your-face-is-not-your-password-inside-windows-hellos-hardwar/) platform authenticators, the Touch ID and Face ID modules -- need to attest that they are genuine hardware. The attestation surface FIDO Alliance had inherited from U2F was *Basic Attestation*: every authenticator in a manufacturing batch of 100,000 or more units shared one attestation key [@fido-cert-levels], so a relying party that checked the attestation learned only "this is one of 100,000-plus YubiKey 5 NFCs," not which device specifically. The cohort-size rule gave Basic Attestation a workable operational privacy property. But there was an architectural fork in the road for an organization that wanted *cryptographic* attestation privacy without the cohort-key fan-out problem.
FIDO Alliance picked the cryptographic fork. The FIDO ECDAA Algorithm v2.0 specification was published as an Implementation Draft on February 27, 2018 [@fido-ecdaa-v2]. The document is the most carefully written specification of the DAA contract from a deployment perspective; the editor was Rolf Lindemann at Nok Nok Labs. The motivation section we have already quoted in §2 names the Privacy-CA failure mode in unusually direct terms.
WebAuthn Level 1 reached W3C Recommendation status on March 4, 2019 [@webauthn-1]. Section 8 defined six attestation statement formats by `fmt` identifier: `packed`, `tpm`, `android-key`, `android-safetynet`, `fido-u2f`, and `none`. ECDAA was not a separate format; the WebAuthn-1 §6.4.4 attestation-type list (Basic, Self, AttCA, ECDAA, None) carried ECDAA as an attestation *type* supported *within* the `packed` and `tpm` formats. An independent verification of the live HTML returns 63 occurrences of the string "ecdaa" in the Level 1 Recommendation -- ECDAA had its own type identifier, its own signing logic, and its own verification procedure embedded inside the two formats that mattered [@webauthn-1].
WebAuthn Level 2 reached W3C Recommendation status on April 8, 2021 [@webauthn-2] [@wiki-webauthn]. The same independent verification against the live Level 2 HTML returns zero occurrences of "ecdaa." Every reference -- the type identifier, the signing rules, the verifier procedure that the `packed` and `tpm` formats invoked -- was removed in a single editorial pass. The Yubico migration guide for its Java WebAuthn server library makes the vendor view explicit: "This attestation type was removed from WebAuthn Level 2. ECDAA support has not been implemented in this library, so this value could in practice never be returned" [@yubico-migration].
Why did the bet fail? Four reasons, each visible from the public record.
First, no major browser ever shipped an ECDAA verifier inside the `packed` or `tpm` statement format paths. Chromium, Firefox, and Safari implemented WebAuthn with `packed`, `tpm`, `fido-u2f`, and `android-safetynet` attestation, but the ECDAA branch within `packed` and `tpm` stayed unimplemented. The Yubico migration guide quoted above is the vendor-side confirmation of an industry-wide outcome [@yubico-migration].
Second, the largest authenticator vendors picked the Basic and AttCA attestation types instead of ECDAA. YubiKey 5 series ships with the `packed` format using a Basic Attestation key shared across a 100,000+-unit cohort [@yubico-yk5-attestation] [@fido-cert-levels]. Feitian, Google Titan, and other major FIDO2 authenticator vendors ship Basic Attestation under the same FIDO certification-policy cohort rule [@fido-cert-levels]. Microsoft Hello platform authenticators on Windows TPM-backed devices use the `tpm` attestation statement format with an AIK that a Microsoft-operated CA certifies -- the AttCA type, functionally a Privacy-CA [@ms-hello-doc] [@azure-attestation]. The vendor base from which a WebAuthn relying party would actually see an attestation statement, in practice, never produced an ECDAA one.
Third, FIDO ECDAA v2.0 never advanced beyond Implementation Draft. The URL slug for the document literally encodes its status: `fido-v2.0-id-20180227` -- the `id-20180227` segment names the format `-`, and "id" is "Implementation Draft." It never reached "Proposed Standard" or "Approved Specification" in FIDO's process [@fido-ecdaa-v2]. A relying party making a long-term technology bet on an attestation statement format that has never advanced past Implementation Draft has no reason to invest in a verifier library.
Fourth, FIDO Basic Attestation's cohort-size rule (100,000+ authenticators per attestation group key, enforced contractually on the certified-authenticator side) gave the underlying privacy concern an *operational* answer [@fido-cert-levels]. A WebAuthn relying party that sees a Basic Attestation signature learns "this is one of at least 100,000 identical authenticators" -- a cohort large enough that the relying party cannot, in practice, recover individual identifying information from the attestation alone. The cohort rule does not require pairing arithmetic, does not need a verifier library, and works with the same `packed` and `tpm` attestation formats every relying party already implements.
> **Key idea:** ECDAA shipped chips. It never shipped verifiers. Standardization is necessary but not sufficient for production deployment: production cryptography needs verifier libraries, and verifier libraries are *social* phenomena -- they emerge from relying-party demand, SDK presence, incident-response tooling, and library-maintainer attention, none of which the cryptography itself produces. Cryptographic excellence does not predict deployment; library availability does.
This is the second aha. The reader entered §8 believing that a standardized cryptographic primitive backed by FIDO, three browser vendors, and a publicly authored attestation format would deploy. They exit understanding that ECDAA standardized everything except the social machinery -- and the social machinery is where production attestation actually lives.
If a consortium with FIDO's privacy mandate, browser-vendor coalition, and authenticator-vendor base could not generate enough relying-party momentum to keep ECDAA in WebAuthn, what chance did the silent option in TPM 2.0 ever have? The answer requires walking the Microsoft attestation stack.
## 9. Windows: A Billion Chips, Zero Production Use (2014-Present)
Microsoft has shipped over a billion Windows TPM 2.0 platforms [@ms-pluton-blog] [@wiki-windows-11]. Microsoft has not shipped a Windows DAA API. The two facts are not in tension. They are the story.
The shipping Windows attestation stack is documented and unambiguous. Microsoft Azure Attestation is the production-grade attestation service. Its public architecture document describes the protocol in five paragraphs that read, line for line, like TPM 1.1 from 2003 [@azure-attestation]:
> "Every TPM ships with a unique asymmetric key called the endorsement key (EK)... A certification authority (CA) establishes trust in the TPM either via EKPub or EKCert... A device proves to the CA that the key for which the certificate is being requested is cryptographically bound to the EKPub and that the TPM owns the EKPriv. The CA issues a certificate with a special issuance policy to denote that the key is now attested as protected by a TPM."
The architecture is the Privacy-CA architecture. The Microsoft-operated CA inputs an EK certificate and outputs a JWT that downstream Microsoft services (Defender for Endpoint device-compliance, Intune Conditional Access policies, Entra ID conditional access, customer-defined Azure Attestation policies) consume. The Windows Health Attestation Service, the older Microsoft surface that predated Azure Attestation, used the same broker model with different deployment shape. The Defender for Endpoint device-compliance flow that gates Conditional Access on attested TPM boot state consumes WHAS or Azure Attestation JWTs, not raw DAA quotes.
Microsoft Pluton's published surface tells the same story from the silicon side. Pluton is the security processor Microsoft has been shipping in successive Windows-class platforms. Its Microsoft Learn page enumerates the cryptographic algorithms and platform-security primitives the processor exposes [@pluton]. The page is exhaustive about TPM 2.0 baseline algorithms (RSA-2048, ECDSA over NIST P-256, SHA-2 family). It contains zero occurrences of `ECDAA`, of `TPM_ALG_ECDAA`, or of any phrase like "anonymous attestation." Insufficient public evidence to assert that Pluton implements ECDAA; sufficient evidence to assert that Pluton's published surface does not advertise it.
The Windows API surface gap is the third piece of evidence. The TPM Base Services (`Tbsi_*` functions in `Tbs.dll`) expose `TPM2_Commit` and `TPM2_Sign` to user-mode applications -- but only as raw command-buffer submissions. There is no `BCryptDirectAnonymousAttestation`. There is no `NCryptDaaSign`. There is no Web Authentication API wrapper that surfaces ECDAA.
The TPM Platform Crypto Provider (PCP) that Windows ships as part of the Cryptography Next Generation (CNG) framework supports RSA and ECDSA TPM-backed keys but does not surface ECDAA. The TSS.MSR open-source TPM stack from Microsoft Research does not ship a DAA wrapper. An application developer who wants ECDAA on Windows today writes raw `TBS_SUBMIT_COMMAND` byte buffers against the documented TPM 2.0 command numbering, manages the Join protocol against an Issuer of their own provisioning, and verifies the resulting signatures with a library they wrote themselves or pulled from a research-grade implementation.
The interesting question is why. Microsoft has never published a "we considered DAA and chose the broker model because..." statement. Treating that absence honestly, the four reasons below are *inferences* from observable architecture decisions, not Microsoft-engineer-published rationales. The article labels them as such.
First, *operational simplicity*. A hosted CA with audit logs is more debuggable than a per-relying-party DAA verifier with no central audit point. When a device fails attestation in production, the on-call engineer reading the Azure Attestation logs can answer "why did this device fail?" in seconds; the same question against a DAA verifier requires reasoning about pairing arithmetic, basename derivation, and Issuer-credential validity. Engineering organizations choose architectures whose failure modes they can debug.
Second, *revocation economics*. A Privacy-CA can revoke an AIK by removing one certificate from its issued-certificate store. Revoking a DAA credential, in the construction TPM 2.0 ships, requires either EPID-style signature-based revocation -- which the TPM 2.0 ECDAA scheme does not provide -- or a private-key list distributed to every relying party (extracting the private key from the misbehaving TPM is presumed possible after compromise, and verifiers then check that the signing key is not on the list). The CA's revocation primitive is a database delete. The DAA revocation primitive is an SDK rollout to every consumer of the verification library.
Third, *the relying-party stack*. DAA verifier libraries are not present in any mainstream cloud platform's SDK. The .NET CryptoNG surface, the Java JCA, the Python `cryptography` library, the Go `crypto` standard library, the Rust `ring` and `dalek` ecosystems -- none ship an ECDAA verifier. X.509 / PKI verifier libraries, by contrast, are everywhere. A relying party building on top of mainstream SDKs gets PKI verification for free; gets DAA verification for nothing close to free.
Fourth, *the Windows API surface gap is itself the obstacle*. Adding a `BCrypt` / `NCrypt` / WebAuthn DAA wrapper to Windows requires designing a new key-storage provider contract, defining the JOIN-protocol service interface, writing the conformance test suite, drafting the security documentation, and rolling it out on the Windows release calendar. That is a project the size of Windows Hello's. Microsoft has not, to public knowledge, prioritized it.
flowchart TD
HW["TPM 2.0 hardware (discrete or Pluton) TPM_ALG_ECDAA may be present"]
TBS["TPM Base Services (Tbs.dll, kernel)"]
PCP["TPM Platform Crypto Provider (BCrypt / NCrypt) RSA and ECDSA only"]
AZ["Microsoft Azure Attestation (Privacy-CA architecture)"]
WHAS["Windows Health Attestation Service (Privacy-CA architecture)"]
RP["Intune / Defender / Entra Conditional Access enforcement"]
HW --> TBS
TBS --> PCP
PCP --> AZ
PCP --> WHAS
AZ --> RP
WHAS --> RP
HW -.->|"ECDAA path exists no Windows API"| HW
The deeper reading -- the one that makes Microsoft's choice look structural rather than accidental -- starts from a comparison the four inferences above already pointed toward.
> **Key idea:** Privacy-CA brokers and DAA solve the same problem -- prove the TPM is genuine without disclosing which TPM. They differ only in *where the trust assumption lives*. The broker treats privacy as an operational policy (the CA promises not to log, audit logs prove it kept the promise, regulators enforce the promise). DAA treats privacy as a mathematical property (the issuer cannot link, period, no audit needed). The architecture that wins in production is the one with the *smaller operational surface*, not the one with the *better cryptographic guarantee*.
This is the third aha. The reader entered §9 believing that cryptographic superiority should eventually win in production, and that Microsoft's non-adoption of DAA must be an oversight or a missed product opportunity. They exit understanding that the deployment-economics asymmetry is structural: a broker-mediated attestation flow reduces, end-to-end, to standard X.509 plumbing every cloud SDK already ships, while a DAA-mediated flow requires bespoke verifier libraries, bespoke revocation infrastructure, bespoke debugging tooling, and bespoke incident-response runbooks. Cloud-platform organizations have spent the last ten years building world-class operational machinery for X.509 attestation. They will not throw it away for a cryptographic property no compliance regime currently demands.
> **Note:** The four reasons compound. The broker model gives a single audit point, a database-delete revocation primitive, an SDK that ships in every major language, and a debugging story the on-call engineer can walk through at 3 a.m. DAA gives mathematical privacy and requires every one of those operational properties to be rebuilt from scratch. Cloud platforms have, repeatedly and consistently, picked the architecture whose operational properties are easier to ship -- not because they do not understand the cryptographic alternative, but because the cryptographic alternative would require them to discard the operational machinery they already have. This is the structural reason DAA has stayed in firmware on a billion chips and out of production attestation flows on all of them.
If the broker calculus is this durable, is there any future world in which DAA wins? Two, and both are research-stage with decade-long horizons.
## 10. Theoretical Limits and Open Problems
What can DAA never do? Where does the next decade of research go? Three open problems organize the active research community in 2026.
### 10.1 What DAA cannot do
The first honest statement is the negative one. A correctly implemented DAA scheme does not prevent a *compromised TPM* from signing for the cohort it belongs to. The EK certificate attestation must be honest at manufacture time; if a TPM's secret membership value `f` leaks to an attacker (through fault injection, through side-channel extraction, through a firmware backdoor), the attacker can produce ECDAA signatures indistinguishable from legitimate ones until the TPM's `f` is added to a revocation list. The same constraint applies to every group-signature scheme.
A second hard limit is per-basename linkability. The user-controlled-linkability property gives a TPM the choice of linkable or unlinkable signing -- but once a verifier has seen the pseudonym `N_V = ζ^f mod Γ` for a particular `(TPM, bsn)` pair, the linkage for that basename is permanent. A misbehaving TPM that wants its history with a particular relying party forgotten cannot, by signing under a different basename, retroactively unlink past sessions.
A third limit is rogue-key scalability. The TPM 2.0 ECDAA scheme detects rogue keys by checking each signature against a list of compromised-`f` values the verifier maintains. For small lists this is cheap. For very large lists -- imagine a deployment where 1% of the chip population leaks `f` to attackers and the verifier must check every signature against ten million revoked values -- the constant factor matters. EPID's Sig-RL mechanism uses signature-based revocation that scales better; the TPM 2.0 ECDAA scheme does not include it.
### 10.2 The One-TPM-to-Bind-Them-All fix
In 2017 a team consisting of Jan Camenisch, Liqun Chen, Manu Drijvers, Anja Lehmann, David Novick, and Rainer Urian published "One TPM to Bind Them All: Fixing TPM 2.0 for Provably Secure Anonymous Attestation" at IEEE S&P 2017 [@one-tpm-2017]. The paper demonstrated a Diffie-Hellman-oracle attack against the TPM 2.0 ECDAA interface as shipped: a malicious host could query the TPM in a way that gave the host a DH-oracle relative to the TPM's secret `f`, effectively breaking the unlinkability property. The proposed fix had been published the previous year by Camenisch, Drijvers, and Lehmann at TRUST 2016 [@cdl-2016] [@cdl-2016-eprint]; library implementations of DAA published from 2017 onward incorporate the fix.
The CDL16 fix is library-level, not silicon-level. The TPM 2.0 ECDAA command surface in the chip remains as shipped; the *software* that drives it must use the corrected protocol sequence to avoid presenting the host-controlled DH oracle. As of late 2025, the TCG normative TPM 2.0 Library Specification text has not been amended to require the corrected sequence. Implementations of DAA on top of TPM 2.0 -- the FIDO ECDAA v2.0 library, the Camenisch-Drijvers-Lehmann reference code, modern academic ECDAA implementations -- follow CDL16. Implementations written against the bare TPM 2.0 Library Specification without reading CDL16 are vulnerable.
### 10.3 Post-quantum DAA
Shor's algorithm is fatal to DAA. Every classical DAA construction -- BCC 2004, BCL 2008, CPS 2010, CDL 2016 -- relies on the hardness of discrete logarithms in elliptic-curve groups, the hardness of strong-RSA factoring, or both. A cryptographically relevant quantum computer breaks all of them. [Post-quantum](/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati/) DAA is therefore active research, with no production deployment as of 2026. Three candidate families are being actively explored:
- **Symmetric-primitive DAA.** Dan Boneh, Saba Eskandarian, and Ben Fisch presented "Post-quantum EPID Signatures from Symmetric Primitives" at CT-RSA 2019 [@bef-2019], building a post-quantum group signature from one-way functions and Merkle trees. The construction has classical post-quantum security guarantees but pays a steep size cost.
- **Lattice-based DAA.** Rachid El Bansarkhani and Ali El Kaafarani published "Direct Anonymous Attestation from Lattices" as IACR ePrint 2017/1022 [@bk-2017-eprint], the earliest such proposal in the literature. The state-of-the-art lattice DAA construction is the 2024 Collaborative Segregated NIZK ("CoSNIZK") work by Liqun Chen, Patrick Hough, and Nada El Kassem [@cosnizk-2024], achieving signatures of approximately 38 kilobytes -- an order of magnitude smaller than the earliest lattice proposals but still two orders of magnitude larger than CPS 2010 ECDAA.
- **Hash-based DAA.** Liqun Chen, Changyu Dong, Nada El Kassem, Christopher Newton, and Yalan Wang published "Hash-Based Direct Anonymous Attestation" at PQCrypto 2023 [@hashdaa-2023], building DAA from SPHINCS+-style stateless hash-based signatures. Size and speed remain unfavorable for TPM 2.0 firmware budgets.
The blocker for any of these reaching production TPM firmware is not academic. The TPM 2.0 normative algorithm set does not include lattice primitives. A post-quantum DAA in TPM 2.0 would require introducing `TPM_ALG_DILITHIUM`, `TPM_ALG_FALCON`, `TPM_ALG_KYBER`, or some equivalent into the spec, mandating support in the PC Client Platform TPM Profile, and rolling out across the OEM TPM-vendor base. That is, at minimum, a three-to-five-year standards effort that the TCG has not, as of late 2025, publicly committed to. CoSNIZK at 38 kilobytes is also two to three times larger than the largest signature any deployed TPM 2.0 firmware budgets for; the TPM-side compute time at quantum-safe parameter sets is currently measured in seconds rather than tens of milliseconds.
### 10.4 DAA for confidential computing
The other future-world thread is confidential computing -- the family of CPU-anchored isolated-execution primitives (Intel SGX, Intel TDX, AMD SEV-SNP, ARM CCA) that need their own attestation surfaces. Intel SGX attestation initially used EPID and has since migrated to DCAP, a vendor-CA broker similar in shape to Microsoft Azure Attestation. AMD SEV-SNP and Intel TDX use vendor-rooted PKI from the start.
Whether DAA-style group-signature schemes are appropriate for VM-level attestation -- where cohorts are small (per-region TDX hosts in a given hyperscaler datacenter), where the verifier is often a small set of well-known cloud-platform endpoints, and where traffic-analysis leakage between confidential VMs and Privacy-CA-like services is itself a threat -- is an open architectural question. The 2026 default is "vendor-CA broker"; the academic community continues to argue that cryptographic DAA would be a better match for the threat model. Production has not, so far, agreed.
A note on Java Card DAA prototypes. A small number of academic implementations of DAA on Java Card secure elements appeared between 2014 and 2017 -- Camenisch and others published smartcard-class implementations as proofs of concept. None reached production deployment. The reasons appear to be the same operational-economics asymmetry that limits TPM 2.0 ECDAA adoption: Java Card environments lack the relying-party verifier libraries that would consume the output. This is inference; no Java Card vendor has, to public knowledge, published a "we evaluated DAA and chose not to ship it" statement.
These are the open problems for researchers. What about the rest of us, on Monday morning?
## 11. Practical Guide and Frequently Asked Questions
Five roles, one Monday morning. Where does this leave you?
**For a Windows platform engineer.** The minimum viable Windows DAA API surface is approximately a `BCryptCreateDaaContext`, `BCryptDaaJoin`, `BCryptDaaSign`, and `BCryptDaaVerify` set, plus an `NCryptDaaKeyHandle` for key-storage-provider lifecycle, plus a Web Authentication API surface that consumes ECDAA attestation. Shipping all of that costs a Hello-sized engineering investment. If Pluton's published surface ever advertises ECDAA, an OEM-side integration becomes possible. Today the answer is that DAA is not available through any supported Windows API.
**For an attestation-provider product engineer.** Pick a Privacy-CA broker architecture for production. The comparison table below makes the trade-offs explicit. Cryptographic DAA does not pay for the architectural switch unless the relying-party privacy threat is specifically the broker itself -- a threat model that, in 2026, no shipping production attestation product publicly assumes.
**For a FIDO authenticator vendor.** ECDAA attestation is not a viable production choice in 2026. The path to it becoming viable runs through verifier libraries in Chromium, Firefox, and Safari; relying-party SDK support across Auth0, Okta, Microsoft Entra, and Google Identity Platform; and a non-deprecated WebAuthn Level N specification that re-adds the format. None of those preconditions are visibly in progress.
**For an academic zero-knowledge-proof researcher.** Four open problems map onto production needs: post-quantum DAA at TPM-firmware-shippable signature sizes (the current state-of-the-art at 38 kilobytes is too large), threshold-issuer DAA (no single party can issue a credential), confidential-computing DAA (for small-cohort VM attestation), and IoT DAA (for milliwatt-class energy budgets). Each is publishable; none yet has a deployment path.
**For a privacy-tech advocate or policymaker.** The framing that helps Microsoft, Google, and AWS engineering teams hear the request is "the broker can be compelled by a subpoena; the math cannot." The framing that does not help is "your cryptography is worse than the academic alternative." The first is a threat-model conversation that engineering organizations can engage with; the second is a technology conversation they have already had and decided.
### Comparison: four production architectures for attested privacy
| Property | Privacy-CA broker | TPM 2.0 ECDAA | EPID 2.0 | Vendor-CA (Apple, AWS Nitro, Google) |
|---|---|---|---|---|
| Trust assumption | Operational (CA promises not to log) | Cryptographic (issuer cannot link) | Cryptographic (issuer cannot link) | Operational (vendor CA promises not to log) |
| Anonymity from verifier? | If CA does not log | Yes (per-basename) | Yes (per-basename) | If vendor does not log |
| TPM-side sign time | Milliseconds (AIK signing) | Tens of milliseconds | Tens of milliseconds | N/A (signing on vendor silicon) |
| Signature size | Hundreds of bytes (AIK) | Hundreds of bytes | Hundreds of bytes | Hundreds of bytes (X.509 over signed JWT) |
| Revocation | CA database delete | Private-key list (TPM 2.0) | Sig-RL (signature-based) | Vendor revocation list |
| Implementer complexity | Low (X.509 PKI everywhere) | High (BN-P256 pairing libraries) | High (vendor SDK required) | Low (vendor SDK ships it) |
| Standardization | TCG (2003) | TPM 2.0 + ISO 20008-2 Mech 4 | ISO 20008-2 Mech 4 | Vendor-proprietary |
| Best suited for | Cloud attestation at hyperscaler scale | Hardware-anchored attestation where broker is the threat | Intel-deployed enclave attestation | Vendor-platform attestation |
| 2026 deployment scale | Billions of attestations per day | Essentially zero production verifiers | 2.4B+ EPID keys per RSAC 2016 | Billions of attestations per day |
The "essentially zero production verifiers" entry for TPM 2.0 ECDAA is the deployment story this article exists to explain. The cryptography is in firmware on hundreds of millions of devices; the verifier side, in 2026, is research-grade libraries and the FIDO ECDAA-Verify reference code. No production cloud-platform SDK ships an ECDAA verifier.
Four things, in order. First, Pluton's published surface advertises `TPM_ALG_ECDAA` and an Issuer key-management story (a Microsoft-operated DAA Issuer for Windows devices, with documented enrollment and revocation flows). Second, a Cryptography Next Generation API surface (`BCryptDaaSign`, `NCryptDaaKey*`) that exposes the TPM2_Commit / TPM2_Sign sequence behind a single managed-language call. Third, a Web Authentication API extension that surfaces ECDAA attestation as a first-class statement format the same way the `tpm` format is today. Fourth, an Azure Attestation policy mode that consumes ECDAA signatures and produces JWT outputs downstream Microsoft services already understand. None of these are technically blocking; all four require a multi-year roadmap commitment that, as of late 2025, Microsoft has not publicly made. This is a thought experiment about technical feasibility, not a forecast about Microsoft strategy.
The companion piece to this article is the [TPM in Windows](https://paragmali.com/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) article, which walks the broader TPM 2.0 command surface ECDAA sits inside.
It depends on what the laptop ships. The TPM 2.0 Library Specification names `TPM_ALG_ECDAA`. The TCG PC Client Platform TPM Profile made the algorithm optional in v1.04 (February 2020) and has carried that designation through v1.07 RC1 (December 2025), so a conformant Windows-class platform is allowed to omit it. Many discrete TPM 2.0 modules (Infineon, STMicroelectronics, Nuvoton) do implement the algorithm; Microsoft Pluton's published documentation does not advertise it. The honest answer is "look at your specific TPM vendor's algorithm capability table" -- and that even if your TPM does support the algorithm, Windows ships no API to use it [@tpm-library-spec] [@tcg-ptp] [@pluton] [@wiki-daa].
Microsoft has not published an explicit rationale. Four inferable reasons are visible from the architecture: (1) operational simplicity -- a hosted CA is easier to debug than a per-relying-party DAA verifier; (2) revocation economics -- a CA can revoke an AIK by deleting a certificate, while DAA revocation requires a private-key list distributed to every verifier; (3) a missing relying-party verifier-library stack; (4) no Windows API surface for ECDAA. All four are inferences. The shipped architecture is the Privacy-CA-shaped flow documented at the Microsoft Learn attestation page [@azure-attestation].
WebAuthn Level 1 (March 2019) registered ECDAA as an attestation *type* (Basic, Self, AttCA, ECDAA, None) carried inside the `packed` and `tpm` attestation statement formats. The Level 1 specification text contains 63 references to "ecdaa." WebAuthn Level 2 (April 2021) removed the type entirely; an independent grep of the Level 2 Recommendation HTML returns zero occurrences of "ecdaa." The Yubico migration guide for its WebAuthn server library states verbatim that "this attestation type was removed from WebAuthn Level 2" and that "ECDAA support has not been implemented in this library." The format has not been resurrected as of 2026 [@webauthn-1] [@webauthn-2] [@yubico-migration].
EPID is a DAA variant with one cryptographic addition: signature-based revocation (Sig-RL), which lets a verifier prove that a candidate signature was not produced by the same signer as any signature on a revocation list. The TPM 2.0 ECDAA scheme is the Chen-Page-Smart 2010 construction; EPID 2.0 is essentially the same construction with Sig-RL added. Intel positions EPID separately because of its production deployment (2.4 billion-plus keys shipped per Intel's RSAC 2016 disclosure, used for SGX attestation, Widevine, and several Intel chipsets), its specific licensing structure (royalty-free under Intel's contribution to ISO/IEC 20008 / 20009), and its open-source SDK that Intel maintained until archiving in 2023 [@brickell-li-epid-2007] [@brickell-li-tdsc-2012] [@wiki-epid] [@epid-sdk].
Active research, no production deployment as of 2026. The leading constructions are lattice-based (CoSNIZK 2024 at approximately 38 kilobytes per signature [@cosnizk-2024]), hash-based (the 2023 PQCrypto paper from SPHINCS+ [@hashdaa-2023]), and symmetric-primitive-based (Boneh-Eskandarian-Fisch CT-RSA 2019 [@bef-2019]). The barriers to shipping any of them in a TPM are fundamental: TPM 2.0 firmware does not implement lattice primitives, signature sizes at 30+ kilobytes are incompatible with current attestation-latency budgets, and no relying-party verifier library exists. A post-quantum DAA TPM is a 2030s project at the earliest.
No. The Stage 0a focus-premise audit of this article demoted that framing as not supported by evidence. The accurate claim is "standardized in the TPM 2.0 Library Specification (2014); optional in the TCG PC Client Platform TPM Profile since February 2020; present on many discrete TPMs (vendor documentation confirms); absent from Microsoft Pluton's published algorithm surface; supported by no Windows API." That hedged statement is the one the article carries from its first 200 words through to this FAQ [@tpm-library-spec] [@tcg-ptp] [@pluton].
The cryptography is finished. The standardization is finished. The hardware is in the field. What is missing is the social machinery -- the verifier libraries, the SDK presence, the operational tooling, the incident-response runbooks, the regulator demand -- that turns cryptography into deployment. Direct Anonymous Attestation is the cleanest example in platform security of a primitive that won every standardization fight and lost every deployment one. The lesson is not that the cryptography is wrong. The lesson is that cryptography is necessary but never sufficient. Production systems are social systems whose mathematical components, however elegant, must compete with operational alternatives whose properties are easier to ship.
The companion pieces in this series are [The TPM in Windows](https://paragmali.com/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) (the cryptographic primitive plumbing TPM 2.0 ECDAA sits inside) and the Microsoft Pluton continuation article (Pluton's published capability surface and the negative claim this article rests its §9 hedge on). The Measured Boot piece -- forthcoming -- walks the data that a hypothetical DAA quote would attest. If those three articles arrive together, the picture of Windows attestation as a *system* rather than a primitive becomes complete.