Direct Anonymous Attestation: The Zero-Knowledge Proof Already in Every TPM

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 ^[1]. A conforming TPM 2.0 chip 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" ^[2].

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 ^[3]. The Windows Health Attestation Service does not. AWS Nitro Enclaves does not ^[4]. Apple App Attest does not ^[5]. Google Play Integrity does not ^[6]. 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 ^[7]. 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) ^[8]. Microsoft Pluton's published surface, which enumerates the algorithms the security processor exposes through its TPM 2.0 personality, does not advertise ECDAA at all ^[9].

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?

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 ^[10], 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 ^[2]:

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 ^[11].
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 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" ^[2]. 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" ^[2]. 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 ^[12]:

"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-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" ^[3]. 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 ^[4]. Apple App Attest issues per-app device identifiers from Apple-operated infrastructure ^[5]. Google Play Integrity ships integrity verdicts signed by Google-operated infrastructure ^[6]. 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 ^[16]. 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.

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 ^[18]. 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 ^[19]. 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.

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 ^[21]. 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.

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 ^[22], 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 ^[23]. 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" ^[24]. 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" ^[24]. Once the credential is issued, the issuer has no cryptographic handle left to break the user's privacy.

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.

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.

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 ^[1]. 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 ^[28]. The journal version appeared at IEEE TDSC in 2012 ^[29]. 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" ^[30]. 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 ^[31]. 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 ^[30].

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 ^[32]. Signature size dropped by an order of magnitude relative to BCC 2004, from roughly 2.5 kilobytes to a few hundred bytes ^[32]. TPM-side sign time, on hardware that supported elliptic-curve arithmetic, came down from seconds to fractions of a second ^[32]. 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.

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" ^[34], 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 ^[35].

Two years later, in Information Processing Letters, Liqun Chen and Jiangtao Li published "A note on the Chen-Morrissey-Smart Direct Anonymous Attestation scheme" ^[36] 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.

5.4 Chen-Page-Smart 2010: the scheme TPM 2.0 actually ships#

The fix arrived at CARDIS 2010 in Passau in April 2010 ^[37]. Liqun Chen, Dan Page, and Nigel Smart published "On the Design and Implementation of an Efficient DAA Scheme" ^{[33] [38]}, 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 ^[2]

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 ^{[25] [41]}. 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 ^[26]. 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" ^{[42] [43]}, 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 ^[44]. 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 ^[1]. 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.

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.

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 ^[1]. 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.

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:

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) ^[8]. After February 2020, an OEM can ship a Windows-class TPM 2.0 platform that does not implement ECDAA at all and remain conformant.

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 ^[9].

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 ^[45]. 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 ^[46]. Part 3 ("Mechanisms using multiple public keys") catalogues a different family of schemes that is not the focus of this article.

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" ^[46].

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 ^[47]. 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. 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 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 ^[48], 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 ^[12]. 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 ^[49]. 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 ^[49].

WebAuthn Level 2 reached W3C Recommendation status on April 8, 2021 ^{[7] [50]}. 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" ^[51].

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 ^[51].

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 ^{[52] [48]}. Feitian, Google Titan, and other major FIDO2 authenticator vendors ship Basic Attestation under the same FIDO certification-policy cohort rule ^[48]. 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 ^{[53] [3]}. 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 <status>-<date>, and "id" is "Implementation Draft." It never reached "Proposed Standard" or "Approved Specification" in FIDO's process ^[12]. 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 ^[48]. 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.

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 ^{[54] [55]}. 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 ^[3]:

"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 ^[9]. 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.

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.

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 ^[44]. 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 ^{[42] [43]}; library implementations of DAA published from 2017 onward incorporate the fix.

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 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 ^[56], 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 ^[57], 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 ^[58], 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 ^[59], 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#

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 (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.