# Direct Anonymous Attestation (DAA): Ensuring privacy with corrupt administrators [^3] [^4] Ben Smyth, Mark Ryan, Liqun Chen ## Abstract The Direct Anonymous Attestation (DAA) scheme provides a means for remotely authenticating a trusted platform whilst preserving the user’s privacy. The protocol has been adopted by the Trusted Computing Group (TCG) in the latest version of its Trusted Platform Module (TPM) specification. In this paper we show DAA places an unnecessarily large burden on the TPM host. We demonstrate how corrupt administrators can exploit this weakness to violate privacy. The paper provides a fix for the vulnerability. Further privacy issues concerning linkability are identified and a framework for their resolution is developed. In addition an optimisation to reduce the number of messages exchanged is proposed. cryptographic protocol, trusted computing, privacy, anonymity # Introduction ## Trusted Computing Trusted computing is a mechanism by which a server can obtain cryptographically-strong guarantees about the state of a remote platform. Such guarantees can include information about the platform’s configuration, the software it is running, the identity of its users and its geographical location. Once in possession of such information the server can make an informed decision as to whether to trust the platform. At the core of the architecture is a hardware device called a Trusted Platform Module (TPM). This chip provides the cryptographic guarantee that the reported data is indeed correct. Applications for trusted computing include *ad hoc* networks, grid computing and corporate digital rights management (DRM). A mobile *ad hoc* network consists of a number of mobile nodes. Unlike traditional network topologies, *ad hoc* networks do not rely upon a fixed infrastructure. Instead, hosts rely upon each other to become and remain connected. Such technology could be deployed to support a campus network. However nodes may cheat: a selfish user may refuse to forward messages from others, thus becoming a ‘freeloader.’ Trusted computing can force each node to act in a fair manner. In the Grid Computing application, the resources of a large number of systems are used to tackle computationally expensive problems. The *M4 Message Breaking Project* is an example, and has recently deciphered two of the three previously unsolved German ciphers used during World War II. All Grid Computing projects share a similar impediment. The client may abuse the system by running modified software or may simply return fictitious values. Trusted computing addresses this problem by providing a guarantee that the client is running the legitimate program in the correct manner. In the corporate DRM setting, organisations can be assured that machines are running only authorised software which is capable of enforcing strict policies for the control of documents and electronic mail. Restrictions may prevent printing sensitive corporate data, or forwarding it to external sources. ## Privacy concerns with trusted computing The aforementioned grid computing example relies upon the ability of a trusted platform to provide a remote attestation. In a similar scenario a situation could exist where the user demands that their identity be protected. The server must therefore only learn that a platform is trusted and not which particular one. Cryptographers and privacy advocates have voiced concerns. The Trusted Computing Group (TCG) has addressed the issue. The concept of privacy has been widely debated and several taxonomies have been formally proposed (Pfitzmann and Köhntopp 2001, 2005; Reiter and Rubin 1998). For the purposes of this document a privacy preserving protocol is one that satisfies anonymity and unlinkability, the definitions of which have been adopted from Pfitzmann & Köhntopp (Pfitzmann and Köhntopp 2005). *Anonymity* is the state of not being identifiable within a set of agents with the same attributes. The set of agents consists of all those who might cause an action and anonymity becomes stronger as the size of the set increases. Reiter & Rubin (Reiter and Rubin 1998) liken the notion to “blending into a crowd." In the presence of a large crowd, each member of which is equally likely to have performed an action, it is impossible to establish from whom the action originated. *Unlinkability* (also called *relationship anonymity*) specifies that given two or more items originating from the same agent it is not possible to link them. As a counterexample, two documents bearing the handwritten signature of an individual allow the items to be linked. Unlinkability only has meaning once anonymity has been achieved, since actions can always be linked if the identity of the agent is known. Of course, privacy is only achievable in a communications protocol if the channel supports anonymity (Reiter and Rubin 1998; Reed, Syverson, and Goldschlag 1998). ## Addressing privacy concerns The solution first adopted by the TCG (TCG 2002) required a trusted third party, namely a *privacy certification authority* (privacy CA). Each TPM has an embedded RSA 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 AIK, signed by EK, to the privacy CA who checks its validity and issues a certificate for the AIK. The host/TPM is now able to authenticate itself with respect to the certificate. This approach permits two possibilities for the detection of rogue TPMs: firstly the privacy CA should maintain a list of EKs known to be rogue and reject requests from them, secondly if a privacy CA receives too many requests from a particular EK it may reject them. The number of permitted requests should be subject to a risk management exercise and goes beyond the scope of this paper. This solution is problematic since the privacy CA must take part in every transaction which makes use of a new AIK, and thus must provide high availability whilst remaining secure. Furthermore privacy requirements may be violated if the privacy CA and verifier collude. The Direct Anonymous Attestation (DAA) (Brickell, Camenisch, and Chen 2004) scheme draws upon techniques developed for group signatures, identity escrow and credential systems. The protocol allows the remote authentication of a trusted platform whilst preserving the privacy of the system’s user. It eliminates the need for a trusted third party and has been adopted by the TCG in the current TPM specification (TCG 2005). The approach can be seen as a group signature scheme without the ability to revoke anonymity, with an additional mechanism to detect rogue members. In broad terms the *host* contacts an *issuer* and requests membership to a group. If the issuer wishes to accept the request, it grants the host/TPM an *attestation identity credential*. The terms *credential* and *certificate* will be used interchangeably hereafter to mean attestation identity credential. The host is now able to anonymously authenticate itself as a group member to a *verifier* with respect to the certificate. The platform need only contact the issuer once, if the host chooses to use a single DAA key associated with this issuer, alleviating the previously discussed bottleneck. ## Contribution This paper shows a weakness of the DAA protocol which allows an adversarial issuer and verifier to collude in order to violate the user’s privacy. Subsequently, the paper describes how the vulnerability can be fixed. Further privacy issues with regards verifier-linkability are identified and a framework for their resolution is developed. In addition, an optimisation to the protocol is proposed. The paper presents the DAA protocol in an accessible format which we believe is easier to understand than the original paper. #### Structure of paper. The remainder of this paper is structured as follows. Section 2 introduces the mathematical and cryptographic primitives used by this work. The DAA protocol is explained in Section 3. In Section 4 an informal security analysis of the protocol is conducted, as a result of which a vulnerability is discovered and subsequently corrected. In Section 5 the privacy problems concerning verifier-linkability are identified and a solution is presented. In Section 6 optimisations are proposed to reduce the number of messages exchanged and to improve the efficiency of rogue tagging. An appraisal of the work is presented in Section 7 and future research is considered in Section 8. Finally for completion, the DAA protocol is provided in its entirety, including the security fixes discussed, in the appendices (the appendices can be found in the extended version of this paper). # Preliminaries ## Protocols to prove knowledge Various protocols which prove knowledge of and relations among discrete logarithms are used by DAA. These protocols will be described using the notation introduced by Camenisch & Stadler (Jan Camenisch and Stadler 1997). The example below has been adapted from Camenisch *et al.* (Brickell, Camenisch, and Chen 2004): $$PK\{(\alpha,\beta,\gamma) : y = g^\alpha h^\beta \wedge \tilde{y} = \tilde{g}^\alpha \tilde{h}^\gamma \wedge \alpha \in [u,v]\}$$ It denotes a *“zero knowledge *P*roof of *K*nowledge of integers $\alpha,\beta,\gamma$ such that $y = g^\alpha h^\beta$ and $\tilde{y} = \tilde{g}^\alpha \tilde{h}^\gamma$ holds, where $\alpha \in [u,v]$."* The values $y,g,h,\tilde{y},\tilde{g}$ and $\tilde{h}$ are elements of some groups $G = \langle g \rangle = \langle h \rangle$ and $\tilde{G} = \langle\tilde{g}\rangle = \langle\tilde{h}\rangle$. Greek letters are used for quantities of the knowledge that is being proved and values kept secret by the prover, while all other values are known to the verifier. The Fiat-Shamir heuristic (Fiat and Shamir 1987) allows an interactive zero knowledge scheme to be converted into a signature scheme. A signature acquired in this way is termed a **S*ignature *P*roof of *K*nowledge* and is denoted, for example, as $SPK\{(\alpha) : y = g^\alpha\}(m)$. # High level overview This section describes the DAA protocol at a high level. For simplicity in presentation, when the TPM is said to have sent or received a value, the message should be assumed to have been delivered by way of the host. The scheme requires that each issuer and verifier has a unique name, termed a basename, denoted $bsn_I$ and $bsn_V$ respectively. The TPM is a small chip with limited resources. DAA therefore aims to minimise the operations that it must perform. This is achieved by outsourcing computation to the host whilst maintaining security. A corrupt host should not of course be able to authenticate without the TPM. However, privacy properties need only be guaranteed if the host is not corrupt. Since a corrupted host can always reveal its identity as it controls all external communication. The low level distinction between computation conducted by the host and TPM are described in the appendices (see the extended version of this paper). The protocol is initiated when a host wishes to obtain a credential. This is known as the join protocol and is shown in Figure 1. The TPM creates a secret $f$ value and a blinding factor $v'$. It then constructs the blind message $U := blind(f,v')$ and $N_I := \zeta_I^f$, where $\zeta_I := (hash(1 \| bsn_I))^{(\Gamma-1)/\rho} \pmod{\Gamma}$ and $\Gamma,\rho$ are components of the issuer’s public key. The $U$ and $N_I$ values are submitted to the issuer $I$. The issuer creates a random nonce value $n_e$, encrypts it with the public key $PK_{EK}$ of the host’s TPM and returns the encrypted value. The TPM decrypts the message, revealing $n_e$, and returns $hash(U \| n_e)$. The issuer confirms that the hash is correctly formed and is convinced that it is communicating with a valid host/TPM. The issuer checks whether the $N_I$ value stems from a rogue TPM or if it has been seen previously (the issuer might chose to reissue the credential in this case). Rogue tagging will be detailed later. The issuer generates a nonce $n_i$ and sends it to the host. The host/TPM constructs a signature proof of knowledge that the messages $U$ and $N_I$ are correctly formed. The issuer verifies the proof and generates a blind signature on the message $U$. It returns the signature along with a proof that a covert channel, which could violate privacy, has not been used (for more detail see the appendices of the extended version of this paper ). The host verifies the signature and proof and the TPM unblinds the signature revealing a secret credential $v$ (the signed $f$). Once the host has obtained an anonymous attestation credential from the issuer it is able to produce a signature proof of knowledge of attestation on a message. This is known as the sign/verify protocol and is shown in Figure 2. Intuitively if a verifier is presented with such a proof it is convinced that it is communicating with a trusted platform and the message is genuine. The message $m$ may be either a public part of an Attestation Identity Key (AIK) produced by the TPM or an arbitrary message. If $m$ is an AIK, the key can later be used to sign PCR data or to certify a non-migratable key. Where $m$ is arbitrary its purpose is application dependent. It may for example be a session key. To distinguish between these two modes of operation a variable $b$ is defined. When $b = 0$ the message was generated by the TPM and when $b = 1$ the message was input to the TPM. The process of convincing a verifier that a host has obtained attestation will now be more precisely described. The host engages in communication with the verifier, during which the verifier requires the host to demonstrate that it is indeed a trusted platform. The host and verifier negotiate whether the verifier is able to link transactions and the verifier sends nonce $n_v$ to the host. The host/TPM produce a signature proof of knowledge of attestation on the message $(n_t\|n_v\|b\|m)$, where $n_t$ is a nonce defined by the TPM and $m$ is a message. In addition the host computes $N_V := \zeta^f$, where $\zeta := (hash(1 \| bsn_V))^{(\Gamma-1)/\rho} \pmod{\Gamma}$ or $\zeta$ is chosen randomly. The value $N_V$ allows for rogue tagging. In addition, if $\zeta$ is not random the $N_V$ value can be used to link different transaction made by the same TPM while not identifying it, and possibly to reject a $N_V$ where it has appeared too often.

[msc diagram omitted]

Join Protocol

[msc diagram omitted]

Sign/Verify Protocol
## Rogue tagging The DAA protocol is designed so that a known rogue TPM can be prevented from obtaining certification or making a successful claim of attestation to a verifier. A rogue TPM is defined as one that has been compromised in such a way that its secret $f$ value has been extracted. Once a rogue TPM is discovered, the secret $f$ values are distributed to all potential issuers/verifiers who add the value to their rogue list. On receipt of $N_I$ and $N_V$ values the issuer/verifier can check if the originating TPM is rogue by ensuring the $N_I,N_V$ value is not equal to $\zeta^{\tilde{f}} \pmod{\Gamma}$ for all values $\tilde{f}$ that are known to stem from rogue TPMs. This check can be done efficiently since the rogue list can be expected to be short and the exponents are relatively small (Brickell, Camenisch, and Chen 2004). # Security analysis ## DAA security properties The objective of DAA is to provide a mechanism for the remote authentication of a trusted platform whilst preserving the privacy of the system’s user. The DAA protocol (Brickell, Camenisch, and Chen 2004) defines the following security properties: 1. Only a trusted platform is able to authenticate. 2. Privacy of non-corrupt host is guaranteed by the sign/verify protocol: 1. Interactions are anonymous. 2. Linkability (of transactions) is controlled by the user. 3. Privacy is restored to a corrupted host if malicious software is removed. Brickell, Camenisch & Chen (Brickell, Camenisch, and Chen 2004) have shown DAA to be secure in the provable security model under the decisional Diffie-Hellman and strong RSA assumption in the random oracle model. Such proofs are an important part of protocol analysis, but they are insufficient. Showing that breaking the scheme is *“essentially as difficult as solving a well-known and supposedly difficult problem"* (Menezes, Oorschot, and Vanstone 2001) is a limited view of security and fails to anticipate the majority of attacks on cryptographic systems (Meadows 2003; Koblitz and Menezes 2004). Koblitz & Menezes (Koblitz and Menezes 2004) argue that *“throughout the history of public-key cryptography almost all of the effective attacks on the most popular systems have not *\[been solving difficult problems (for example integer factorisation)\]*, but rather by finding a weakness in the protocol."* Koblitz & Menezes go on to suggest that *“formalistic proofs *\[are\]* so turgid that other specialists don’t even read *\[them\]*. As a result, proof-checking *\[is\]* a largely unmet security objective, leaving *\[protocols\]* vulnerable to attack."* This forms the motivation for an informal security analysis of the DAA scheme. ## Violation of privacy in the presence of corrupt administrators It is now shown that a colluding issuer and verifier can conspire to break anonymity when linkable transactions are used, violating security properties [secPropPrivAnon] and [secPropPrivLink]. The verifier and issuer conspire to use the same basename, i.e. $bsn_V = bsn_I$. This will result in the host computing $\zeta$ = $\zeta_I$. Recall that $\zeta_I = (hash(1 \| bsn_I))^{(\Gamma-1)/\rho} \pmod{\Gamma}$ and $\zeta = (hash(1 \| bsn_V))^{(\Gamma-1)/\rho} \pmod{\Gamma}$. The issuer learnt the identity of a host and which $N_I$ value the host used during the join protocol. The verifier receives $N_V$ during the execution of the sign protocol. The host identity is revealed, since $N_I = N_V = \zeta_I^{f_0+f_1 2^{l_f}} = \zeta^{f_0+f_1 2^{l_f}} \pmod{\Gamma}$ and the issuer is able to link the hosts identity with $N_I$. The privacy violation relies upon the assumption that an issuer and verifier share the same basename (i.e. $bsn_I$ = $bsn_V$). For example, this assumption holds in the following scenario. An online service provider could act as an issuer during the registration process and a verifier during service usage. This use case is in fact presented[^5] by Camenisch *et al.* in earlier work on the idemix (identity mixer) system (Jan Camenisch and Lysyanskaya 2001; Jan Camenisch and Herreweghen 2002) which forms the basis of the DAA protocol. Under these conditions the issuer and verifier are the same entity and thus it makes logical sense for them to share a single basename. In fact, not doing so could cause confusion. Requiring the user to distinguish between $bsn_I$ and $bsn_V$ values places unnecessary burden on the user and will inevitably lead to their incorrect use. Furthermore, putting in place a procedure for obtaining a unique basename would ultimately require a worldwide governing body. At best this is undesirable since interaction with an authority reintroduces the bottleneck DAA aims to avoid. At worst, such a body is infeasible. It is simply not economic to setup an organisation for the sole purpose of issuing basenames. In addition such a body is likely to charge for its services. ## Fix The values $\zeta_I$ and $\zeta$ need not be computed in such a similar manner. It is therefore proposed that the join protocol uses $\zeta_I := (hash(0 \| bsn_V))^{(\Gamma-1)/\rho} \pmod{\Gamma}$ and the sign/verify protocol uses $\zeta := (hash(1 \| bsn_V))^{(\Gamma-1)/\rho} \pmod{\Gamma}$. The collusion between issuer and verifier to break privacy is no longer possible, regardless of whether $bsn_V = bsn_I$. Basenames may now be selected from a single name space as the distinction between issuer and verifier is no longer required. ## Revised DAA protocol The appendices, of the extended version of this paper, present the complete DAA protocol. The presentation attempts to provide clarity to the reader, incorporates the security fix (Section 4.3) and includes the observation made by Camenisch & Groth (J. Camenisch and Groth 2004) for increased efficiency (Brickell, Camenisch, and Chen 2005). We believe our presentation is in a more accessible format which is easier to understand than the original paper. To avoid over-complication the optimisations described in Section 6.1 and the construction/use of basenames (Section 5) are not shown; making these changes is trivial. # Overcoming problems with DAA basenames The DAA protocol provides user controlled linkability (security property [secPropPrivLink], Section 4.1). More precisely two modes of operation are defined: verifier-linkable and verifier-unlinkable. Verifier-linkability is controlled by the construction of $N_V := \zeta^f$, where $\zeta$ is either derived from a basename or selected randomly (see Section 3). The former construction allows linkability, whereas the latter prevents it. By design DAA therefore provides provisions to link transactions which use the same basename. There are three types of linkable transactions: 1. **Single application linkability** A verifier providing a single application is able to link transactions. 2. **Cross application linkability** A verifier providing multiple applications which share the same basename is able to link transactions between different applications. 3. **Cross verifier linkability** Different verifiers offering several applications which share the same basename are able to link transactions. These forms of linkability are shown under various operating conditions in Figure 3. We note that cross issuer linkability - that is linkability between applications with different issuers - is not possible. Since the construction of $N_V$ contains the TPM’s secret $f$ value, which in turn incorporates the issuer’s public key. Different issuers must use different public keys, thus cross issuer linkability is not possible.
Linkability in various scenarios
The DAA protocol does not define the security requirements of basenames nor does it specify how basenames should be implemented. This presents two potential problems: 1. **Security properties.** In order to ensure the user controlled linkability, the user must be assured as to which verifier(s) will use a basename and for what application(s). DAA does not provide adequate provisions for this. Thus the host may inadvertently allow linkability between verifiers and/or applications, violating user controlled linkability. 2. **Implementation.** The protocol does not specify how to implement user controlled linkability. A naïve solution is that the host maintains a list of basenames associated with its communicating partners, including DAA issuers and a DAA verifiers, who have been associated with a basename. However, if a DAA key is used for a long time and for many different applications, which is the DAA scheme designed for, maintaining such a list is infeasible for most ordinary users. Subsection 5.1 defines a technique which will resolve these two issues and Section 5.2 will discuss its use in practice. ## Constructing a basename The host must be able to uniquely identify with whom a basename should be used and for what application. It is therefore proposed that the basename is constructed from application, verifier and issuer specific data. An example of such information is shown in Table [tab:BasenameContent]. The host is then able to check a basename prior to its use, thus preserving user controlled linkability. The construction of the basename may be undertaken by either the verifier or the host. Alternatively it could be created through negotiation. This decision is left to application developers. When the host is responsible for construction, it may be pre-programmed in the host’s software, or determined by the user at run-time for example. ## Using a basename The host will be required to maintain the information used for constructing basenames as shown in Table [tab:BasenameContent] and a blacklist of basenames which the host does not want to be used any more. When a new basename is required, the host (and the verifier) will create it based on the particular application. When an existing basename is given it is selected from the list and the host checks that it matches the application specification. The host’s blacklist will then be consulted to ensure that the basename has not previously been blacklisted. If desired the verifier will be asked to authenticate to the host. This process is presented in Figure 4.
The proposed solution.
#### Motivating authentication of the verifier. To ensure that a user’s affiliations are not learnt by an adversary the host must authenticate the verifier. Although the DAA protocol does not require verifier authentication it is expected that this will be the case in real applications. Standard authentication techniques can be used. #### Manageability of basename list. The framework makes basenames more manageable. Basenames are constructed from application specific data and prior to use the host may authenticate the verifier. This means that the host need not maintain a complete list of basenames, since checks can be made to ensure that the basename is suitable for use with a specific application/verifier. This will ensure the list is relatively short. The host need only keep a blacklist if it wishes to avoid certain basenames. Expired basenames can be removed from either list. # Optimisations ## Reduction in messages An optimisation of the join protocol, which reduces the number of messages exchanged from seven to four, is shown in Figure 5. A formal analysis of the optimisation is beyond the scope of this paper, but an informal discussion is given. The optimisation allows the host to learn $n_i$ earlier than the original protocol. Since this value provides the host with no advantage the protocol is believed to remain secure. The three subsequent messages are all passed from the host to the issuer in succession, it therefore makes no difference to the security of the protocol to concatenate these messages into a single message. It is claimed the optimisation reduces the number of messages whilst maintaining security.

[msc diagram omitted]

Optimised Join Protocol
## Rogue tagging The rogue tagging checks can be optimised. Since $\zeta_I$ is a constant in the join protocol the issuer is able to precompute $\zeta_I^{\tilde{f}_0+\tilde{f}_1 2^{l_f}} \pmod{\Gamma}$ for all $(\tilde{f}_0,\tilde{f}_1)$ on the rogue list. This technique can also be applied to the join protocol when $\zeta$ is fixed. In the case where $\zeta$ is random Brickell, Camenisch & Chen (Brickell, Camenisch, and Chen 2004) propose that a considerable speedup can be achieved using the batch verification techniques defined by Bellare, Garay & Rabin (Bellare, Garay, and Rabin 1998a, 1998b). # Conclusion In this paper a weakness of the Direct Anonymous Attestation protocol is presented. The weakness allows an issuer and verifier to collude to violate the privacy of the host. The vulnerability is fixed by making a minor alteration to the scheme. It is noted that the modification only affects the host part of the protocol (i.e. no modifications need be made to the hardware TPM). The fix is believed to be safe. Proving this formally is the topic of current research. Further privacy issues surround verifier-linkability. The DAA protocol provides inadequate provisions to enable the host to identify with whom, and for which application, a basename may be used. This may result in a privacy violation. The problem is resolved by the development of a framework which facilitates the correct construction/use of basenames. In addition, optimisations to reduce the number of messages exchanged and to improve the efficiency of rogue tagging are presented. # Further work This paper used informal techniques to identify an inadequacy of the DAA scheme. Such methods are not complete and thus formal verification techniques must be applied to give assurance that the protocol is indeed secure. The applied pi calculus is a formalism suitable for modelling DAA which allows us to verify properties using automatic tools. The verification of the scheme remains the topic of future research. The strength of a security system is inversely proportional to its complexity. DAA provides a esoteric solution to a seemingly simply problem. This work has discovered a vulnerability in its design. Inevitably, implementation will result in intrinsic weaknesses. Further research should aim to establish simpler solutions, ultimately producing systems with greater security and efficiency. Cryptographers can create secure systems which deliver provably strong security properties. Society, however, is unwilling to accept such systems. Chaum introduced digital cash in the 1980s offering powerful properties including anonymity and unlinkability. Digital cash attracted little attention and was essentially rejected by society over concerns of *“taxation *\[evasion\]* and money laundering, instability of the exchange rate, disturbance of the money supply, and the possibility of a Black Monday in cyberspace"* (Tanaka 1996). DAA addresses society’s concerns using linkability, an impurity which appears undesirable, but is demanded by the real world. Further research should look to enable a more fine-grained approach to the level of privacy provided to the user. Revocable unlinkability could for example be provided. This would provide absolute privacy in normal operation but would allow linkability to be revoked by the collaboration of the issuer and $n$ verifiers. # References
Bellare, Mihir, Juan A Garay, and Tal Rabin. 1998a. “Fast Batch Verification for Modular Exponentiation and Digital Signatures.” In *EUROCRYPT ’98: Advances in Cryptology, Lecture Notes in Computer Science (LNCS)*, 1403:236–50. Berlin, Germany: Springer-Verlag.
———. 1998b. “Fast Batch Verification for Modular Exponentiation and Digital Signatures.” Cryptology ePrint Archive, Report 1998/007. .
Brickell, Ernie, Jan Camenisch, and Liqun Chen. 2004. “Direct Anonymous Attestation.” In *CCS ’04: 11th ACM Conference on Computer and Communications Security*, 132–45. New York, United States of America: ACM Press.
———. 2005. *The DAA Scheme in Context, in Chris Mitchell (eds) Trusted Computing*. The Institute of Electrical Engineers (IEE).
Camenisch, Jan, and Els Van Herreweghen. 2002. “Design and Implementation of the Idemix Anonymous Credential System.” In *CCS ’02: Proceedings of the 9th ACM Conference on Computer and Communications Security*, 21–30. New York, NY, USA: ACM Press.
Camenisch, Jan, and Anna Lysyanskaya. 2001. “An Efficient System for Non-Transferable Anonymous Credentials with Optional Anonymity Revocation.” In *EUROCRYPT ’01: Proceedings of the International Conference on the Theory and Application of Cryptographic Techniques*, 93–118. London, UK: Springer-Verlag.
Camenisch, Jan, and Markus Stadler. 1997. “Efficient Group Signature Schemes for Large Groups (Extended Abstract).” In *CRYPTO ’97: 17th Annual International Cryptology Conference on Advances in Cryptology, Lecture Notes in Computer Science (LNCS)*, 410–24. London, UK: Springer-Verlag.
Camenisch, J., and J. Groth. 2004. “Group Signatures: Better Efficiency and New Theoretical Aspects.” In *SCN ’04: Fourth Conference on Security in Communication Networks, Lecture Notes in Computer Science (LNCS)*, 3352:120–33. Springer-Verlag.
Fiat, Amos, and Adi Shamir. 1987. “How to Prove Yourself: Practical Solutions to Identification and Signature Problems.” In *CRYPTO ’86: Advances in Cryptology, Lecture Notes in Computer Science (LCNS)*, 186–94. London, UK: Springer-Verlag.
Koblitz, Neal, and Alfred J. Menezes. 2004. “Another Look at “Provable Security".” Cryptology ePrint Archive, Report 2004/152. .
Meadows, Catherine. 2003. “Formal Methods for Cryptographic Protocol Analysis: Emerging Issues and Trends.” *Selected Areas in Communications* 21 (1): 44–54.
Menezes, A J, P C van Oorschot, and S A Vanstone. 2001. *Handbook of Applied Cryptography*. 5th ed. CRC Press.
Pfitzmann, Andreas, and Marit Köhntopp. 2001. “Anonymity, Unobservability, and Pseudeonymity — a Proposal for Terminology.” In *International Workshop on Designing Privacy Enhancing Technologies*, 1–9. New York, USA: Springer-Verlag.
———. 2005. “Anonymity, Unlinkability, Unobservability, Pseudonymity, and Identity Management – a Consolidated Proposal for Terminology. Version 0.26.” Department of Computer Science, Technische Universität Dresden.
Reed, Michael G., Paul F. Syverson, and David M. Goldschlag. 1998. “Anonymous Connections and Onion Routing.” *Selected Areas in Communications* 16 (4): 482–94.
Reiter, Michael K., and Aviel D. Rubin. 1998. “Crowds: Anonymity for Web Transactions.” *ACM Transactions on Information and System Security (TISSEC)* 1 (1): 66–92.
Tanaka, Tatsuo. 1996. “Possible Economic Consequences of Digital Cash.” In *INET ’96: Proceedings of the 6th Annual Internet Society Conference*. Montreal, Canada: ISOC.
TCG. 2002. “Trusted Computing Platform Alliance (TCPA) Main Specification Version 1.1b.” Trusted Computing Group. .
———. 2005. “TCG TPM Specification Version 1.2 Revision 85.” Trusted Computing Group. .
[^1]: An extended version of this paper can be found at http://www.cs.bham.ac.uk/\char126bas/ [^2]: This research was funded by the Engineering and Physical Sciences Research Council (EPSRC) under the WINES initiative as part of the UbiVal project. [^3]: An extended version of this paper can be found at http://www.cs.bham.ac.uk/\char126bas/ [^4]: This research was funded by the Engineering and Physical Sciences Research Council (EPSRC) under the WINES initiative as part of the UbiVal project. [^5]: See (slide 10).