language-icon Old Web
English
Sign In

Direct Anonymous Attestation

Direct Anonymous Attestation (DAA) is a cryptographic primitive which enables remote authentication of a trusted computer whilst preserving privacy of the platform's user. The protocol has been adopted by the Trusted Computing Group (TCG) in the latest version of its Trusted Platform Module (TPM) specification to address privacy concerns (see also Loss of Internet anonymity). ISO/IEC 20008 specifies DAA, as well, and Intel's Enhanced Privacy ID (EPID) 2.0 implementation for microprocessors is available for licensing RAND-Z along with an open source SDK. Direct Anonymous Attestation (DAA) is a cryptographic primitive which enables remote authentication of a trusted computer whilst preserving privacy of the platform's user. The protocol has been adopted by the Trusted Computing Group (TCG) in the latest version of its Trusted Platform Module (TPM) specification to address privacy concerns (see also Loss of Internet anonymity). ISO/IEC 20008 specifies DAA, as well, and Intel's Enhanced Privacy ID (EPID) 2.0 implementation for microprocessors is available for licensing RAND-Z along with an open source SDK. In principle the privacy issue could be resolved using any standard signature scheme (or public key encryption) 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 global secret. One only needs to look at the precedent of Content Scramble System (CSS), an encryption system for DVDs, 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. The solution first adopted by the TCG (TPM specification v1.1) required a trusted third-party, namely a privacy certificate 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 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 a priori, or b) the TPM's manufacturer must have provided an endorsement certificate.) 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 blacklist 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.

[ "Authentication", "Trusted Computing", "Trusted service manager", "Trusted Execution Technology", "Trusted client", "Hengzhi chip", "Forward anonymity" ]
Parent Topic
Child Topic
    No Parent Topic