Attestation

Inherits: an ordered, tamper-evident boot history committed to PCRs plus the event log that explains it (Chapter 4, Measured Boot); a hardware-rooted signing identity. The manufacturer-certified Endorsement Key and a TPM-resident Attestation Identity Key that can quote PCRs over a verifier nonce (Chapter 2, The TPM).
Promise: a remote party who never touches the machine can verify that a particular boot story was measured and signed by a key it accepts as TPM-protected. Turning local measured state into evidence it can gate access on, without trusting the OS to self-report.
TCB: the TPM (or Pluton) that protects the EK/AIK private keys and signs the quote; the manufacturer or broker CA that vouches the signing key is TPM-bound; the attestation service that maps raw quote + event log into policy claims. The OS being evaluated is explicitly outside it.
Adversary → Break: a compromised OS that replays a stale healthy quote (defeated by the verifier nonce) or signs with an uncertified software key (defeated by EK→AIK certification). The Promise ends at the instant of attestation: it says nothing about runtime state after the quote is signed, and the EK→AIK broker can link device identity unless privacy is enforced cryptographically (DAA) rather than operationally.
Residual: runtime compromise after a healthy quote → owned by Chapter 6 (The Secure Kernel) and Chapter 8 (Code Integrity); broker-linkability of device identity off the box → owned by Chapter 26 (Zero Trust) and Chapter 28 (Confidential VMs).
Bequeaths: "a remote verifier can gate access on proven, hardware-anchored platform state": the cryptographic floor the kernel-isolation and cloud-authorization links build on. Does NOT provide: proof the machine is currently uncompromised, runtime code/credential isolation, or any claim about the user.
Proof: 🔵 documented: Get-TpmEndorsementKeyInfo (Microsoft Learn) and the TPM 2.0 quote structure; no 🟢 capture on our lab VM (silicon-tier rule: no captured block without a real capture file).

The Reasoner's question. What is actually signed, by which TPM-rooted identity, who vouches for that identity, what privacy does that vouching leak, and where does the proof stop?

Foundations. What you need before this chapter.

Inherited silicon vocabulary. The Foundations chapter (Chapter 0) and the Measured Boot chapter (Chapter 4) establish what this chapter builds on: a PCR is an extend-only register (new = H(old || measurement)) whose final value is a compact commitment to an ordered boot history. Attestation does not re-derive those measurements; it packages selected ones for a remote verifier.
Event log. PCRs are hashes. The event log explains what was hashed. A useful verifier checks both: the log should replay to the PCR values, and the resulting events should satisfy policy.
Quote. A TPM quote is a signature over selected PCR values plus verifier-supplied freshness data, normally a nonce. The nonce prevents replay; the PCR selection defines the question being answered.
EK. The Endorsement Key is the TPM’s manufacturer-provisioned identity, established in the TPM chapter (Chapter 2). Its public half, often accompanied by an EK certificate, is the root used to decide whether an attestation key is really TPM-bound.
AIK / AK. The Attestation Identity Key, also called an Attestation Key, is a TPM-resident signing key used for quotes. It is certified as TPM-bound so verifiers do not need to see the EK every time.
Privacy-CA / AttCA. A broker validates the EK or EK certificate, proves the TPM controls the EK private key, and certifies an AIK. Relying parties then trust the AIK certificate. Privacy depends on the broker not abusing or disclosing the EK-to-AIK linkage.
DAA / ECDAA. Direct Anonymous Attestation is the zero-knowledge alternative. A TPM proves membership in an issuer-certified group without revealing which TPM it is and without an online broker in the verification path. ECDAA is the elliptic-curve form named by TPM 2.0, optional in the PC Client Platform TPM Profile, and rarely implemented or verified in production.
vTPM caveat. In a virtual machine, the endorsement identity may be host-issued rather than burned into physical silicon. A vTPM EK can be useful evidence inside a cloud trust boundary, but it is not the same claim as a discrete hardware TPM EK. Confidential-VM attestation is developed in the Confidential VMs chapter (Chapter 28).

What this link is responsible for

Attestation has one job: carry the silicon’s promise to someone who is not on the machine.

Measured Boot records facts locally. Secure Boot says the firmware should only load signed components. The TPM records the sequence in PCRs. BitLocker can seal a key to that state. All of that helps the local machine defend itself. None of it, by itself, answers the cloud’s question: is the device asking for this token the same class of device that booted through the policy I require?

The relying party cannot ask msinfo32. It cannot ask Task Manager. It cannot ask an agent whose answer may be produced after compromise. It needs evidence anchored below Windows: a TPM-resident key signs a fresh statement about PCRs; a certificate chain or issuer credential says that signing key is really TPM-bound; an attestation service maps the raw evidence to claims such as secureBootEnabled, aikValidated, codeIntegrity, or virtualizationBasedSecurity; the relying party consumes those claims in policy.

There are therefore two separable questions in every attestation design. The first is state: which measurements, logs, and security-mode flags are being asserted? The second is identity: why should the verifier believe the signing key is inside genuine hardware rather than generated by a script? Confusing the two creates bad reviews. A beautiful PCR quote signed by an uncertified software key proves nothing about silicon. A perfectly certified AIK over the wrong PCR selection proves only that the wrong question was signed by real hardware.

That is why attestation is the bridge from local boot integrity to remote authorization. Silicon and firmware produce the measurements. Cloud control planes decide whether those measurements are good enough to receive corporate data, an Entra token, an Intune compliance state, or access to a workload. Without attestation, measured boot is local hygiene. With attestation, it becomes a remote authorization input.

The link is deliberately narrow. It proves that a particular boot story was measured and signed by a key the verifier accepts as TPM-protected. It does not prove the machine is currently uncompromised. It does not prove the user is benign. It does not prove the MDM policy is wise. It gives the next layer a cryptographic floor: “this device’s boot evidence satisfied the policy at the time of attestation.” Everything after that is someone else’s trust problem.

The production Windows flow: EK, AIK, quote, Privacy-CA

The production Windows flow is Privacy-CA-shaped. Microsoft Azure Attestation’s TPM documentation describes the pillars plainly: validate TPM authenticity, then validate the measurements made during boot [199]. The authenticity leg starts with the EK. A CA establishes trust in the TPM through EKPub or EKCert; the device proves the requested attestation key is cryptographically bound to that EK and that the TPM owns EKPriv; the CA issues a certificate or claim with a special policy denoting that the key is protected by a TPM [199].

That certified key is the AIK. The AIK signs quotes over a digest of the selected PCRs. The quote binds three things: the selected PCR values, a relying-party nonce, and the TPM-resident private key. The boot log explains what was extended; the PCRs commit to the result; the AIK signature prevents a compromised operating system from editing the values in transit. The relying party or attestation service then checks whether the measurements match the policy it cares about.

The nonce is not decorative. Without it, a compromised host could replay last week’s good quote after today’s bad boot. With it, the signed object is tied to a challenge the verifier just generated. Freshness is what turns a stored boot receipt into live evidence. The verifier still has to decide how long that evidence remains acceptable after issuance, but replay is no longer a free attack against the protocol itself.

Microsoft’s attestation policy examples make the bridge explicit: a TPM-bound AIK must validate, Secure Boot must evaluate as enabled, and only then does policy issue a platform-attested claim [199]. Windows device-health surfaces expose the same idea at management scale through Microsoft Graph’s deviceHealthAttestationState, including fields such as attestationIdentityKey, secureBoot, codeIntegrity, bootDebugging, testSigning, safeMode, windowsPE, earlyLaunchAntiMalwareDriverProtection, virtualSecureMode, pcrHashAlgorithm, and pcr0. These are not magic truth fields. They are the management-plane rendering of attestation evidence: boot measurements interpreted into device-health state for Intune and related MDM consumers [207].

The privacy question lives inside the EK-to-AIK step. The EK is uniquely identifying by design. If every relying party saw the EK, attestation would become a cross-site device-tracking mechanism. The classic TCG answer is the Privacy-CA: the CA sees the EK, certifies an AIK, and the verifier later sees only the AIK certificate. Privacy is operational. The CA promises not to log or disclose the EK-to-AIK linkage.

This is a respectable engineering choice, not a footnote. Enterprises often want revocation, audit trails, support tickets, and a place to ask why a device failed. A Privacy-CA gives them a database, logs, certificate issuance policy, and a familiar PKI failure model. The price is that the broker becomes part of the privacy and availability story. If the broker logs too much, is compelled to produce records, misissues certificates, or is unavailable during enrollment, the attestation system inherits that operational reality.

Direct Anonymous Attestation was invented to remove that promise. In DAA, the TPM runs a one-time Join protocol with an issuer and receives a membership credential. Later it signs in zero knowledge: “I hold a valid issuer credential” without revealing which TPM holds it and without asking the issuer to participate in each verification. The rest of this chapter follows that thread: the DAA history, the Privacy-CA trap, the ECDAA mechanism, the TPM2_Commit surface, the FIDO ECDAA deprecation, and the Windows/Azure reality that made broker-mediated attestation win production.

Specified everywhere, deployed nowhere

The TPM 2.0 Library Specification published since 2014 names a zero-knowledge proof of knowledge; Windows-class platform profiles later made the relevant algorithm optional. 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. When ECDAA is implemented, the mandated curve is TPM_ECC_BN_P256 (0x0010), a 256-bit Barreto-Naehrig curve picked specifically because it admits the asymmetric pairings the protocol needs [83]. 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" [208].

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 [199]. The Windows Health Attestation Service does not. AWS Nitro Enclaves does not [209]. Apple App Attest does not [210]. Google Play Integrity does not [211]. 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 [212]. 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) [115]. Microsoft Pluton, the security processor covered in the Pluton chapter (Chapter 3), exposes its algorithms through a TPM 2.0 personality; that published surface does not advertise ECDAA at all [6].

The most thoroughly standardized hardware-anchored group-signature primitive in the history of platform security is specified everywhere, implemented or exposed unevenly, and verified in almost no production systems.

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.

Figure: Thirty years of DAA and group signatures, from Chaum, van Heyst's 1991 group-signature paper to the 2024 CoSNIZK lattice-DAA construction. The horizontal line at 2014: when TPM 2.0 standardized ECDAA in firmware: divides the era that won the standardization fights (above) from the era that lost the deployment fights (below).

To answer the question of why, we have to start where every TPM attestation story does: with the architecture DAA was invented to replace.

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 [213], 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 [208]:

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 [74].
The platform generates a fresh Attestation Identity Key (AIK) inside the TPM.
The platform sends (EKCert, AIKpub, proof-of-binding) to a Privacy-CA.
The Privacy-CA validates the EK certificate, confirms the binding proof, and issues Cert(AIKpub) signed by the CA.
The platform uses the AIK to sign TPM attestation structures such as PCR quotes (the boot event log is presented separately and replayed against the quoted PCR digest) and TPM2_Certify key-attestation outputs, and presents Cert(AIKpub) to relying parties as proof that the AIK is TPM-resident.

Definition: Endorsement Key (EK) and Attestation Identity Key (AIK). The Endorsement Key is the long-lived, manufacturer-certified asymmetric key anchored in the TPM at manufacture (in TPM 2.0, derived from a persistent endorsement seed). Its public half is the chip's long-term 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 anchors a one-time certification of the AIK (or one per Privacy-CA), and the AIK does the signing thereafter [199].

Definition: Privacy Certificate Authority (Privacy-CA). 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 [208].

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" [208]. 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" [208]. 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 [214]:

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.

Note. 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 [215] and in a PODC 2003 paper "Cryptography and Competition Policy: Issues with Trusted Computing" [216]. 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 [217]. European data-protection authorities had begun studying TCPA in the same window [215]. 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" [199]. The full verbatim Microsoft Learn quote is reproduced later, in the Windows case study, where it anchors the Microsoft analysis.

The same pattern repeats across every hyperscaler. AWS Nitro Enclaves produces signed attestation documents, verified against an AWS-operated X.509 certificate chain, that contain enclave measurements (PCRs) and instance/module identifiers [209]. Apple App Attest issues per-app device identifiers from Apple-operated infrastructure [210]. Google Play Integrity ships integrity verdicts signed by Google-operated infrastructure [211]. In 2026 the operational descendants of TPM 1.1's Privacy-CA broker run the production attestation surface of every consumer-grade cloud platform.

Walkthrough: the brokered attestation path. Start with a chip whose manufacturer provisioned EKPriv and certified EKPub. The platform creates an AIK inside the TPM and sends EKCert, AIKpub, and a binding proof to a broker. The broker validates the EK certificate chain, proves that the requester controls EKPriv by using a MakeCredential / ActivateCredential-style challenge, and issues Cert(AIKpub) or a platform-attested token. The relying party later receives a quote signed by the AIK, validates the broker's certificate or token, checks freshness and PCR policy, and never sees the EK directly. The privacy pivot is therefore not hidden: the broker saw both EK and AIK at enrollment time. If it logs the mapping, is compromised, or is compelled to disclose records, anonymity collapses operationally even though the relying party's normal protocol transcript contains only the 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.

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 [218]. 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.

Definition: Group signature. 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 [218].

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 [219]. 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 [220]. 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.

Note. 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 [221]. 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 [222]. 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.

Definition: Camenisch-Lysyanskaya (CL) signature. 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 [222] [223].

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 [223], a generalization that would matter for the elliptic-curve DAA schemes of the next decade.

Walkthrough: the primitives DAA inherited. Chaum and van Heyst gave the field the core abstraction: one public group key, many private member keys, and signatures that convince a verifier that some group member signed. Camenisch and Stadler made that abstraction usable for large groups by making signatures constant-size rather than proportional to membership. ACJT added the coalition-resistance requirement DAA needs: even a pool of malicious members should not be able to mint a new signing identity outside the issuer's control. Camenisch-Lysyanskaya credentials supplied the last missing mechanism: blind issuance plus later proof-of-possession. DAA's Join is a CL-style credential issuance bound to a TPM secret; DAA's Sign is a zero-knowledge proof that the signer holds such a credential. By 2004, BCC did not need to invent anonymous credentials from scratch. It needed to remove the group manager's opener and specialize the machinery to TPM attestation.

A sibling lineage was building in parallel. Dan Boneh, Xavier Boyen, and Hovav Shacham presented "Short Group Signatures" at CRYPTO 2004 [224]. 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.

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

Definition: Direct Anonymous Attestation (DAA). 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 [225].

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} = ζ^{f} (mod Γ), ζ = H_{Γ} (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.

Definition: User-controlled linkability. 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 [226].

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:

Computes the pseudonym N_V = ζ^f mod Γ where ζ = H_Γ(bsn).
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.
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^{''}}) (mod 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 the brokered Privacy-CA flow described earlier, makes the contrast vivid.

Walkthrough. BCC DAA end to end. During Join, the TPM chooses or protects a secret membership value f. The Issuer validates the platform's endorsement evidence without learning a reusable verifier-facing identifier, then issues a CL credential over f; in the BCC notation the credential material is often written as (f, A, e, v). During Sign, the TPM and host prove in zero knowledge that they know a valid Issuer credential on the hidden f. If the verifier supplies no basename, the proof is unlinkable across relying parties and sessions. If the verifier supplies a basename, the TPM derives a pseudonym from that basename and f, so the same TPM can be recognized by the same relying party without becoming globally trackable. Verification requires only the Issuer public key and the proof transcript. There is no online Privacy-CA, no opener, and no manager who can deanonymize the signer after the fact.

This is the first turning point. Group signatures aimed at anonymity with manager-controlled traceability; TPM attestation needs the opposite: 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), not an addition.

Note. 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 [227]. 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 [228] 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 in the mid-2000s [74]. 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.

The evolution: From RSA-DAA to EC-DAA (2007-2013)

Six papers in seven years, two industrial branches, one dead end, one standardized ECDAA-capable 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 TPM 2.0 later standardized for ECDAA-capable implementations runs through five waypoints, each addressing the problem the previous one created. Read the section as a narrowing funnel, not as a triumphal deployment story: RSA-DAA proved the privacy primitive; EPID proved one industrial revocation strategy; pairing-based DAA made signatures small enough for firmware; the CMS proof flaw forced the community to separate symmetric-pairing intuition from asymmetric-pairing security; CPS split the protocol across TPM and host; BFGSW and CDL then repaired the formal model. The cryptography became mature just as production platforms learned to prefer brokered PKI. That historical mismatch is why this chapter keeps ECDAA framed as optional, rarely exposed, and almost never verified in mainstream Windows deployments.

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 [229]. The journal version appeared at IEEE TDSC in 2012 [230]. 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" [231]. 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 [232]. 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 [231].

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 standardized for ECDAA-capable implementations 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.

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

Definition: Bilinear pairing (Type-3, asymmetric). 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 [234].

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" [235], 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 [236].

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

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

Chen-Page-Smart 2010: The scheme TPM 2.0 standardized for ECDAA-Capable implementations

The fix arrived at CARDIS 2010 in Passau in April 2010 [238]. Liqun Chen, Dan Page, and Nigel Smart published "On the Design and Implementation of an Efficient DAA Scheme" [234] [239], 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 standardized for ECDAA-capable implementations. That distinction matters: the standard names the algorithm and command surface, but the PC Client Platform profile later made ECDAA optional, and many Windows-class surfaces do not expose it. The Wikipedia DAA article makes the attribution direct, in a sentence that is itself the most-cited single primary-source extract in this chapter:

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 [208]

Definition: Barreto-Naehrig (BN) curve. 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 [240]. 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.

Note. 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 [241]. 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.

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 [226] [242]. 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 [227]. 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" [243] [244], 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 [245]. The CDL16 scheme is what most modern DAA library code references as the canonical construction.

Walkthrough: the evolution map. The main line begins with BCC 2004: RSA-based DAA, TPM 1.2-era assumptions, and the first opener-free attestation primitive. One branch becomes EPID in 2007, adding signature-based revocation and becoming Intel's production group-attestation system. A second branch becomes BCL 2008, replacing large RSA proofs with pairing-based DAA. The CMS 2008 proposal tries to move that idea onto asymmetric pairings, but its proof does not survive the model shift. CPS 2010 is the repair: Type-3 pairings over BN curves and a practical TPM/host split. BFGSW 2013 then formalizes user-controlled linkability and the pre-DAA-signing split, while SRC 2015 audits BCC's privacy model and CDL 2016 supplies the q-SDH revisitation and DH-oracle fix modern libraries follow. The standardized ECDAA-capable TPM path is therefore CPS-shaped, but the safest software understanding is BFGSW/CDL-shaped.

By 2013 the cryptography was complete. The standards organizations took the construction and made it official: in two different specifications, on two parallel tracks.

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 specification you have almost certainly never used; your particular chip may not implement or expose it at all. 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 [83]. 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.

Definition: TPM_ALG_ECDAA (0x001A). 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 [83].

Definition: TPM_ECC_BN_P256 (0x0010). 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.

Definition: TPM2_Commit and TPM2_Sign. 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 [83].

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.

BN-P256 is not NIST P-256. 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 [83]. 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.

Note. 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 [83]
Mandatory curve	`TPM_ECC_BN_P256 = 0x0010`	Part 2 [83]
First-round command	`TPM2_Commit(keyHandle, P1, s2, y2) -> (K, L, E, counter)`	Part 3 [83]
Second-round command	`TPM2_Sign(keyHandle, digest, scheme=TPM_ALG_ECDAA, validation) -> signature`	Part 3 [83]
Join anchor	`TPM2_MakeCredential` / `TPM2_ActivateCredential`	Part 3 [83]
Math description	Part 1 Annex C.5 (informative)	Part 1 [83]
Optionality status	Optional since PTP v1.04 (Feb 2020); carried through v1.07 RC1 (Dec 2025)	TCG PC Client Platform TPM Profile changelog [115]

A practical capability probe is therefore two-stage. First ask whether the TPM reports TPM_ALG_ECDAA = 0x001A; then ask whether it reports TPM_ECC_BN_P256 = 0x0010. ECDAA without the pairing-friendly BN curve is not a usable TPM 2.0 ECDAA path for the construction described here, and BN-P256 without an exposed ECDAA signing scheme is merely a curve identifier. Passing both checks is still not deployment: Join requires an Issuer, credential provisioning, revocation policy, verifier libraries, and application policy. Failing either check is enough to explain why the Windows production stack routes around ECDAA. The two-stage probe teaches the decision logic, not a supported Windows API, because Microsoft ships no BCryptDirectAnonymousAttestation or NCryptDaaSign wrapper.

A sourcing caveat belongs here too. The TCG resource pages for the TPM Library Specification and PC Client Platform profile sometimes reject automated fetches with HTTP 403. The claims this chapter uses from those specifications are narrow and audit-stable: the algorithm identifier, the BN-P256 curve identifier, the command names, and the PTP changelog line making ECDAA optional. Treat the canonical TCG documents as the normative source even when a non-browser fetcher cannot retrieve them directly [83] [115].

Figure: The TPM2_Commit / TPM2_Sign split protocol. The host drives the exchange. It sends a basename, has the TPM (which holds the secret f) commit, hashes the commitment points into a Fiat-Shamir challenge, requests a Schnorr-style response, and assembles the ECDAA signature; the verifier checks the pairing equation on BN-P256. The TPM never computes the pairings and the host never learns f.

Walkthrough: TPM2_Commit / TPM2_Sign. A verifier first chooses the message context and, optionally, a basename. The host translates that context into the ECDAA inputs P1, s2, and y2 expected by the TPM command surface. The TPM, which protects the secret f, runs TPM2_Commit(keyHandle, P1, s2, y2) and returns commitment points (K, L, E) plus a counter tying this first round to the later response. The host hashes the issuer parameters, basename, message, and commitment points into the Fiat-Shamir challenge c. It then invokes TPM2_Sign with scheme=TPM_ALG_ECDAA and the validation data that binds the response to the prior commit. The TPM returns the Schnorr-style scalar response derived from its nonce and f. The host assembles (K, L, E, c, s, basename data, issuer parameters) into the ECDAA signature. The verifier recomputes c, checks the pairing equations on BN-P256, checks the optional basename pseudonym, and rejects if the issuer key, curve, counter binding, or revocation checks fail. The TPM never computes the expensive pairings; the host never learns f.

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) [115]. 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 200V (Lunar Lake) in 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 [6].

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 chapter carries from its opening to its FAQ.

The spec was written. Some implementations shipped. The TCG was satisfied. So why does no one verify ECDAA signatures?

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 [246]. Part 2 ("Mechanisms using a group public key") catalogs 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 [247]. Part 3 ("Mechanisms using multiple public keys") catalogs a different family of schemes that is not the focus of this chapter.

Definition: ISO/IEC 20008. 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 [247].

A note on the title, because it is easy to get wrong. ISO/IEC 20008-2 is sometimes mis-cited as "anonymous signatures with message recovery." That phrasing belongs to a different standard, ISO/IEC 9796. The verified ISO catalog title for 20008-2 is, verbatim, "Information technology (Security techniques) Anonymous digital signatures: Part 2: Mechanisms using a group public key" [247].

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 [248]. A FIDO authenticator using an anonymous group-signature attestation (ECDAA or EPID) is, in ISO-speak, executing a 20009-2 mechanism that wraps a 20008-2 signature; ordinary TPM-backed Kerberos and key-attestation flows use non-anonymous keys and are separate protocol designs.

Aside: The patent and licensing context for EPID 2.0 in ISO. Intel held patents on the EPID construction. In contributing the EPID 2.0 algorithm to ISO/IEC 20008 and 20009, Intel made the underlying intellectual property available under royalty-free (RAND-Z) terms. Intel's EPID white paper records the contribution and notes that EPID "complies with international standards ISO/IEC 20008 / 20009" [231]. The licensing structure mattered: it is what made the construction acceptable to the FIDO Alliance, to the TCG for the TPM 2.0 ECDAA surface, and to the European procurement community whose conformance regimes treat royalty-bearing cryptographic primitives differently from royalty-free ones. Exact licensing-event dates are not directly indexed in publicly fetchable Intel materials; this paragraph is inference-grade reconstruction from the Wikipedia citation chain.

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.

The FIDO bet that failed (2017-2021)

In 2018, the FIDO Alliance bet that ECDAA was the missing privacy story for WebAuthn (the WebAuthn and Passkeys chapter, Chapter 21). Three years later, W3C took the bet off the table.

The bet was not casual. FIDO had a real problem. WebAuthn authenticators need to attest that they are genuine hardware: the YubiKey hardware tokens, the Windows Hello platform authenticators (the Windows Hello chapter, Chapter 20), and the Touch ID and Face ID modules. 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 [249], 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 [214]. The document is the most carefully written specification of the DAA contract from a deployment perspective; the editor was Rolf Lindemann at Nok Labs. The motivation section quoted earlier: the FIDO ECDAA v2.0 draft on Privacy-CA load and aggregation: names the Privacy-CA failure mode in unusually direct terms.

WebAuthn Level 1 reached W3C Recommendation status on March 4, 2019 [250]. 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.3 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 finds dozens of 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 [250].

WebAuthn Level 2 reached W3C Recommendation status on April 8, 2021 [212]. 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" [251].

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 [251].

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 [252] [249]. Feitian, Google Titan, and other major FIDO2 authenticator vendors ship Basic Attestation under the same FIDO certification-policy cohort rule [249]. 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 [253] [199]. 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 [214]. 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 [249]. 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.

Aside: The 100,000+ cohort rule as operational privacy. The FIDO Basic Attestation cohort minimum is a particularly clean example of how operational rules can compete directly with cryptographic primitives. The privacy property a relying party wants ("I cannot single out this device from its peers") can be obtained by (a) hardware-anchored zero-knowledge proofs that mathematically forbid linkage (cryptographic DAA), or (b) a contractual obligation that every batch of attestation keys covers at least 100,000 devices (FIDO Basic Attestation) [249]. The cryptographic answer is mathematically stronger. The operational answer is dramatically easier to debug, audit, and revoke. Production has consistently chosen the latter.

Key idea. ECDAA reached standards and some implementation surfaces. It never shipped mainstream 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 turning point. A standardized cryptographic primitive backed by FIDO, three browser vendors, and a publicly authored attestation format still did not deploy: 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.

Windows: TPM attestation without ECDAA

Microsoft has shipped over a billion Windows TPM 2.0 platforms [254] [255]. 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 [199]:

"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 [6]. 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. This chapter 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 centrally: stop issuing fresh attestation tokens for that device, or publish its certificate status through CRL or OCSP. Revoking a DAA credential in the TPM 2.0 ECDAA construction 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 centralized status publication. 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 CNG 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.

Walkthrough: Windows production attestation without ECDAA. Hardware starts below the OS: a discrete TPM or Pluton-class security processor protects EK material and TPM-resident keys. Windows reaches it through TPM Base Services (Tbs.dll) and exposes ordinary TPM-backed application keys through the TPM Platform Crypto Provider in CNG. The production attestation path then turns brokered: Azure Attestation or the Windows Health Attestation Service validates EK / AIK binding, interprets quote and boot evidence, and emits claims that Intune, Defender for Endpoint, Entra Conditional Access, or a customer policy engine can consume. Where ECDAA is present in a particular TPM implementation, it remains below this supported Windows API layer; where it is absent, the platform is still conformant under the optional PC Client profile. In either case, the mainstream Windows stack routes through AIK certificates, JWTs, and PKI validation rather than through a DAA issuer and ECDAA verifier.

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 turning point. Cryptographic superiority does not, on its own, win in production, and Microsoft's non-adoption of DAA is not an oversight or a missed product opportunity: 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.

Why the broker calculus wins for Microsoft, AWS, and Google in 2026. 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 specifications and scattered firmware support while remaining outside mainstream production attestation flows.

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.

Documented evidence surface

This chapter has no captured evidence block. The silicon-tier rule is strict: no higher-confidence block appears unless a real capture file exists and the chapter quotes it verbatim. The surface below is therefore documented-only. It shows what a reader can run, what Microsoft documents the command as returning, and how that local evidence fits into the quote and Azure Attestation flow.

🔵 DOCUMENTED: Microsoft Learn, Get-TpmEndorsementKeyInfo [256] · reproduce: Get-TpmEndorsementKeyInfo -HashAlgorithm Sha256

IsPresent                : True
PublicKey                : System.Security.Cryptography.AsnEncodedData
PublicKeyHash            : 70769c52b6e24ef683693c2a0208da68d77e94192e1f4080ae7c9b97c6caa681
ManufacturerCertificates : {[Subject]
OID.2.23.133.2.3=1.2,
OID.2.23.133.2.2=C4T8SOX3.5,
OID.2.23.133.2.1=id:782F345A
...
[Issuer]
CN=Contoso TPM CA1, OU=Contoso Certification Authority, O=Contoso, C=KR
...
[Thumbprint]
77378D1480AB48FEA2D4E610B2C7EEF648FEA2 (truncated for illustration)
}
AdditionalCertificates   : {}

That output is the root of the authenticity leg. IsPresent says Windows knows an endorsement public key. PublicKeyHash is the reproducible identifier of that public key under SHA-256. ManufacturerCertificates is the certificate material a CA can use when deciding whether this TPM is genuine. On virtual machines, read the result with the vTPM caveat in mind: the vTPM endorsement key may be issued by the host or cloud platform rather than by a discrete TPM manufacturer. It can still be valid evidence inside that platform’s trust boundary, but it is not the same physical-silicon claim.

The next object in the chain is the quote. In TPM 2.0 terms, a quote is not just "PCRs signed by an AIK." The signed digest covers a TPMS_ATTEST structure. For a quote, TPMS_ATTEST contains the magic value that identifies TPM-generated attest data, the attestation type TPM_ST_ATTEST_QUOTE, the qualified name of the signing key, the verifier-provided extraData nonce, clock and reset counters, firmware-version information, and a TPMS_QUOTE_INFO payload containing the PCR selection and a digest over the selected PCR values [83]. The AIK signature is over the marshaled attest structure, not over a human-readable report. A verifier that checks only a displayed pcr0 string has skipped the security boundary; the boundary is the signature over TPMS_ATTEST plus replay of the event log into the selected PCR digest.

A production Azure Attestation-style evaluation adds three more checks. First, authenticity: the service validates that the AIK is TPM-bound by walking from EK evidence through the broker's certification policy. Second, freshness: the nonce in extraData must match the relying party's challenge, or the quote might be a replay from a prior healthy boot. Third, policy: the PCR selection, event-log replay, Secure Boot state, Code Integrity state, debug flags, and VBS indicators are interpreted into claims such as aikValidated, secureBootEnabled, codeIntegrity, and related device-health fields [199] [207]. Those claims are the objects Conditional Access and MDM policy usually consume. ECDAA would change the authenticity leg (issuer credential plus zero-knowledge proof instead of EK-to-AIK certification) but it would not remove the need to parse TPMS_ATTEST, verify freshness, replay measurements, and make policy decisions.

A useful reader exercise is therefore three-layered. Run the documented EK command to see the identity root Windows can expose. Obtain or inspect a quote path from your attestation service to locate the TPMS_ATTEST fields and the nonce. Then compare the service's issued claims against the boot policy you think you are enforcing. If those three layers do not line up (EK/AIK authenticity, quote freshness, and PCR/event-log policy), the attestation story is incomplete no matter how elegant the underlying TPM primitive is.

🔵 DOCUMENTED: TPM 2.0 quote shape [83] · documented structure, not captured on our lab VM check: TPMS_ATTEST{ type = TPM_ST_ATTEST_QUOTE, extraData = verifier nonce, attested.quote.pcrSelect = selected PCRs, attested.quote.pcrDigest = digest(selected PCR values) } signed by an AIK / AK.

Theoretical limits and open problems

This is the boundary section: it separates the property ECDAA gives from the properties marketing language is tempted to imply. DAA gives anonymous, issuer-backed proof that the signer holds a valid group credential bound to TPM-protected secret material. It does not make a compromised chip honest, erase linkability after a basename has been reused, make revocation free, survive a cryptographically relevant quantum computer, or automatically fit confidential-computing deployments whose privacy and audit requirements differ from PC-client attestation. Four problems organize the active research community in 2026: failure containment after f leaks, DH-oracle-safe protocol driving, post-quantum anonymous credentials, and whether group-signature attestation helps or hurts VM-scale confidential computing.

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.

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 [245]. 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 [243] [244]; library implementations of DAA published from 2017 onward incorporate the fix.

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

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 [257], 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 [258], 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 [259], 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 [260], 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 post-quantum signature primitives (ML-DSA, FN-DSA/Falcon, or SLH-DSA) and new TPM algorithm identifiers 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.

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, the subject of the Confidential VMs chapter (Chapter 28). 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?

What it means for you

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	Centralized (refuse / CRL / OCSP)	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

Note. The "essentially zero production verifiers" entry for TPM 2.0 ECDAA is the deployment story this chapter exists to explain. The cryptography is in the standard and may be present in some TPM firmware; 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.

What would Microsoft have to ship for DAA to actually win in production? 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.

Closing

The cryptography is mature. The standardization is mature. Some hardware support 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.

Bequeaths. Attestation closes Part I. The silicon tier now offers one composite guarantee the rest of the book stands on: a machine can prove (to a party that never touches it) that it booted a particular, measured software state, signed by a key rooted in hardware the verifier accepts. That is the floor remote authorization is built on. The kernel-isolation links take it first: the Secure Kernel chapter (Chapter 6) and the Code Integrity chapter (Chapter 8) assume a platform whose boot state was already proven before they reason about what runs after boot. The cloud links take it last: the Zero Trust chapter (Chapter 26) and the Continuous Access Evaluation chapter (Chapter 27) gate tokens on attested device health, and the Confidential VMs chapter (Chapter 28) carries the same EK→AIK→quote shape into host-issued vTPMs. What attestation does NOT bequeath is just as load-bearing: it proves a boot story was measured and signed at one instant, not that the machine is uncompromised now; it isolates no secret and no token; and it makes no claim about the user behind the keyboard. Silicon hands up a proven platform; everything above must still protect the code, credentials, and tokens that run on it.

The Windows Trust Chain