Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Direct Anonymous Attestation
open-in-new
<h2 id="historical-perspective">Historical perspective</h2> <p>In principle the privacy issue could be resolved using any standard signature scheme (or <a href="/facts/Public-key_cryptography/gowoFTxS">public key encryption</a>) and a single key pair. Manufacturers would embed the private key into every TPM produced and the public key would be published as a certificate. Signatures produced by the TPM must have originated from the private key, by the nature of the technology, and since all TPMs use the same private key they are indistinguishable ensuring the user's privacy. This rather naive solution relies upon the assumption that there exists a <i>global secret</i>. One only needs to look at the precedent of <a href="/facts/Content_Scramble_System/vzPVMQvk">Content Scramble System</a> (CSS), an encryption system for <a href="/facts/DVD/7fJsHJrN">DVDs</a>, to see that this assumption is fundamentally flawed. Furthermore, this approach fails to realize a secondary goal: the ability to detect rogue TPMs. A rogue TPM is a TPM that has been compromised and had its secrets extracted. </p><p>The solution first adopted by the TCG (TPM specification v1.1) required a trusted third-party, namely a <i>privacy certificate authority</i> (privacy CA). Each TPM has an embedded <a href="/facts/RSA_(algorithm)/XTzyfHuq">RSA</a> key pair called an Endorsement Key (EK) which the privacy CA is assumed to know. In order to attest the TPM generates a second RSA key pair called an Attestation Identity Key (AIK). It sends the public AIK, signed by EK, to the privacy CA who checks its validity and issues a certificate for the AIK. (For this to work, either a) the privacy CA must know the TPM's public EK <i>a priori</i>, or b) the TPM's manufacturer must have provided an <i>endorsement certificate</i>.) The host/TPM is now able to authenticate itself with respect to the certificate. This approach permits two possibilities to detecting rogue TPMs: firstly the privacy CA should maintain a list of TPMs identified by their EK known to be rogue and reject requests from them, secondly if a privacy CA receives too many requests from a particular TPM it may reject them and blocklist the TPMs EK. The number of permitted requests should be subject to a risk management exercise. This solution is problematic since the privacy CA must take part in every transaction and thus must provide high availability whilst remaining secure. Furthermore, privacy requirements may be violated if the privacy CA and verifier collude. Although the latter issue can probably be resolved using blind signatures, the first remains. </p><p>The EPID 2.0 solution embeds the private key in the microprocessor when it is manufactured, inherently distributes the key with the physical device shipment, and has the key provisioned and ready for use with 1st power-on. </p> <h2 id="overview">Overview</h2> <p>The DAA protocol is based on three entities and two different steps. The entities are the DAA Member (TPM platform or EPID-enabled microprocessor), the DAA Issuer and the DAA Verifier. The issuer is charged to verify the TPM platform during the Join step and to issue DAA credential to the platform. The platform (Member) uses the DAA credential with the Verifier during the Sign step. Through a <a href="/facts/Zero-knowledge_proof/38soaPT5">zero-knowledge proof</a> the Verifier can verify the credential without attempting to violate the platform's privacy. The protocol also supports a blocklisting capability so that Verifiers can identify attestations from TPMs that have been compromised. </p> <h2 id="privacy-properties">Privacy properties</h2> <p>The protocol allows differing degrees of privacy. Interactions are always anonymous, but the Member/Verifier may negotiate as to whether the Verifier is able to link transactions. This would allow user profiling and/or the rejection of requests originating from a host which has made too many requests. The Member and Verifier can also elect to reveal additional information to accomplish non-anonymous interactions (just as you can choose to tell a stranger your full name, or not). Thus, known identity can be built on top of an anonymous start. (Contrast this with: if you start with known identity, you can never prove you un-know that identity to regress to anonymity.) </p> <h2 id="implementations-and-attacks">Implementations and attacks</h2> <p>The first Direct Anonymous Attestation scheme was due to Brickell, Camenisch, and Chen;<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> that scheme proved insecure and required a fix.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> Brickell, Chen, and Li improved efficiency of that first scheme using symmetric pairings, rather than RSA.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> And Chen, Morrissey, and Smart attempted to further improve efficiency by switching from a symmetric to an asymmetric setting;<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a><a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> unfortunately, the asymmetric scheme was also insecure.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> Chen, Page, and Smart proposed a new <a href="/facts/Elliptic_curve_cryptography/YbjcXIWk">elliptic curve cryptography</a> scheme using Barreto–Naehrig curves.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> This scheme is implemented by both EPID 2.0 and the TPM 2.0 standard. It is recommended for TPMs in general<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> and required for TPMs that conform to the PC client profile.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> In addition, the Intel EPID 2.0 implementation of ISO/IEC 20008 DAA and the available open source SDK<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> can be used for members and verifiers to do attestation. Since one of the DAA attestation methods in TPM 2.0 is identical to EPID 2.0, work is underway to make ISO/IEC 20008 DAA and TPM 2.0 DAA attestation read consistently with each other at the spec level. </p> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Cryptographic_protocol/0WuyTkFo">Cryptographic protocol</a></li> <li><a href="/facts/Digital_credential/3nyLl2px">Digital credential</a></li> <li><a href="/facts/Trusted_platform_module/3XHCGYkX">Trusted platform module</a></li> <li><a href="/facts/Enhanced_privacy_ID/gF2G3gMe">Enhanced Privacy ID</a></li> <li><a href="/facts/Privacy_enhancing_technologies/2v8rvT4l">Privacy enhancing technologies</a></li></ul> <h2 id="external-links">External links</h2> <ul><li>E. Brickell, J. Camenisch, and L. Chen: <i>Direct anonymous attestation</i>. In Proceedings of 11th ACM Conference on Computer and Communications Security, ACM Press, 2004. (<a href="http://www.zurich.ibm.com/~jca/papers/brcach04.pdf">PDF</a>)</li> <li>E. Brickell, J. Camenisch, and L. Chen: <i>Direct anonymous attestation</i> . (<a href="http://eprint.iacr.org/2004/205.pdf">[1]</a>)</li> <li><a href="https://www.ma.rhul.ac.uk/static/techrep/2005/RHUL-MA-2005-13.pdf"><i>Interdomain User Authentication and Privacy</i></a> by Andreas Pashalidis - section 6</li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>TPM Specification <a href="https://www.trustedcomputinggroup.org/tpm-library-specification/" target="_blank">https://www.trustedcomputinggroup.org/tpm-library-specification/</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>Brickell, Ernie; Camenisch, Jan; Chen, Liqun (2004). "Direct Anonymous Attestation" (PDF). ACM Conference on Computer and Communications Security: 132–145. <a href="/wiki/Jan_Camenisch" target="_blank">/wiki/Jan_Camenisch</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>Smyth, Ben; Ryan, Mark; Chen, Liqun (2015). "Formal analysis of privacy in Direct Anonymous Attestation schemes" (PDF). Science of Computer Programming. 111 (2): 300–317. doi:10.1016/j.scico.2015.04.004. <a href="https://eprint.iacr.org/2012/650.pdf" target="_blank">https://eprint.iacr.org/2012/650.pdf</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>Brickell, Ernie; Chen, Liqun; Li, Jiangtao (2009). "Simplified security notions of Direct Anonymous Attestation and a concrete scheme from pairings" (PDF). International Journal of Information Security. 8 (5): 315–330. doi:10.1007/s10207-009-0076-3. S2CID 16688581. <a href="https://eprint.iacr.org/2008/104.pdf" target="_blank">https://eprint.iacr.org/2008/104.pdf</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Chen; Morrissey; Smart (2008). "On Proofs of Security for DAA Schemes". 3rd International Conference on Trust and Trustworthy Computing. 5324: 156–175. <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Chen; Morrissey; Smart (2008). "Pairings in Trusted Computing". 2nd International Conference on Pairing-Based Cryptography. 5209: 1–17. <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Chen; Li (2010). "A note on the Chen-Morrissey-Smart DAA scheme". Information Processing Letters. 110 (12–13): 485–488. doi:10.1016/j.ipl.2010.04.017. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>Chen; Page; Smart (2010). "On the Design and Implementation of an Efficient DAA Scheme" (PDF). 9th International Conference on Smart Card Research and Advanced Applications. 6035: 223–237. <a href="https://eprint.iacr.org/2009/598.pdf" target="_blank">https://eprint.iacr.org/2009/598.pdf</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>Trusted Platform Module Library. Part 1: Architecture. trustedcomputinggroup.org, Retrieved 25 June 2024 <a href="https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.16.pdf" target="_blank">https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.16.pdf</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>TCG PC Client Platform. TPM Profile (PTP) Specification. trustedcomputinggroup.org, Retrieved 25 June 2024 <a href="https://www.trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2-0-v43-150126.pdf" target="_blank">https://www.trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2-0-v43-150126.pdf</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>EPID SDK <a href="https://github.com/Intel-EPID-SDK/epid-sdk" target="_blank">https://github.com/Intel-EPID-SDK/epid-sdk</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> </ol>