Talk:Direct Anonymous Attestation

Untitled

Should there be a seperate entry for basic attestation? Should this entry be a sub-part of that entry? Also, I think would it be more accurate to say that DAA is a cryptographic protocol rather than a digital signature scheme.

What do you mean by `basic attestation'? I do not believe that it should be a subsection regardless, since DAA is a particular means of attestation. More precisely it enables the remote authentication of a trusted host, whilst preserving the privacy of user.

Personally I would define DAA as a cryptographic protocol. Although more precisely DAA is a group signature scheme without the ability to revoke anonymity.--Bah23 17:02, 24 January 2007 (UTC)

Article badly written

Personally I feel this article is badly written and contains numerous errors. I suggest a complete rewrite. If I get time I will make the necessary changes. As a note to myself:

``Direct anonymous attestation is a digital signature scheme which allows anonymous signing. This works by allowing verifiers to verify that a message was signed by an authorized signer without revealing who the specific signer was."

See above. Direct Anoymous Attestation (DAA) is a cryptographic protocol which enables the remote authentication of a trusted platform (trusted platform = one that contains a TPM).

``This is to be used in relation to a trusted platform module where the module would generate a session key, have the key signed anonymously by an external certificate authority, and then present the key to the verifier. If the verifier trusts the CA to only sign session keys from correct TPMs, then the verifier can trust the session key and trust the computer on which the TPM is installed.

By using a trusted third party one obtains anonymity against the verifying site. Had one just signed the session key with the secret TPM key, then the site could identify revisiting visitors, something which would lessen their anonymity."

I believe this refers to previously adopted protocol, defined in version 1.1 of the TPM specs. There is NO privacy CA in DAA (adopted in version 1.2 of the specs). In DAA a host convinces an issuer that it is indeed a trusted platform and the issuer provides an attestation credential. This can then be used to convince a verifier that the host obtained attestation.

``Anonymity can be complete or partial. One of the parameter of the Sign step is a name that is computed both from the platform and verifier. If the name is computed from a random number, the anonymity is complete, otherwise, if the name is computed from a number chosen by the verifier, the verifier is able to track the platform throughout successive attestations always without affecting privacy. In this case the verifier is only able to track that the same platform has performed successive attestation, but he's not able to know the identity of the platform or track attestations done with other verifiers."

Swap anonymity for privacy. DAA always ensures anonymity but can allow linkability by the above.

``The DAA protocol may also involve a Revocation Authority (RA). In this scenario, the platform encodes its identity with RA's public key and sends it to the verifier. The verifier can ask the RA to reveal the real identity or just if it is a trusted party depending on the policy. In this way, the DAA can detect a rogue TPM , that is , a TPM whose EK has been blacklisted ."

There is no RA. There is however a mechanism to detect rogue TPMs

I will endeavor to do a rewrite at some point....--Bah23 17:13, 24 January 2007 (UTC)

I have rewritten the article. Sorry if I have stepped on anyone's toes, but given the aforementioned reasons I believe the rewrite was necessary. A small portion of the old article remains. The article still needs work, in particular the actual Join/Sign/Verify protocols need to be specified. I have these written elsewhere but need to check whether its okay to publish them on wp.--Bah23 16:52, 30 January 2007 (UTC)

It might be reasonable to note that "Interdomain.." paper seems to suggest signing AIKs "by using DAA technique" and platform "sending public part of EK" with Issuer "verifying" TPM using a list of known keys. It seems there are no AIKs with DAA and authentication should be done using private part of EK. Vadymf 12:41, 31 January 2007 (UTC)

I don't think you've read the paper properly?

Extract: This mechanism, called `Direct Anonymous Attestation' (DAA), does not require an authority to certify each AIK. Instead, the TPM is required to obtain a digital `attestation certi¯cate' from an Issuer (typically the TPM or TP manufacturer) only once. This certi¯cate can then be used by the TPM to digitally sign an arbitrary message in such a way that (a) the veri¯er is convinced that the message was generated by a TCG conformant TPM, and (b) the resulting signature cannot be linked to any other DAA signature that was previously generated by this particular TPM. By using this DAA technique to sign subsequently generated AIKs (instead of arbitrary messages) veri¯ers can be given assurance that these AIKs are genuine (i.e. that they were generated by a TCG conformant TPM), in a way that preserves their unlinkability, i.e. so that two AIKs associated with the same TPM cannot be linked.

Incidently I do not believe the TPM is required to obtain a digital `attestation certi¯cate' from an Issuer (typically the TPM or TP manufacturer) only once to be correct. DAA was designed to enable issuing to occur outside of a secure environment, i.e. the Issuer would not be a TPM or TP manufacturer.--Bah23 13:28, 31 January 2007 (UTC)

"Interdomain.." paper

I am not convinced that this paper provides a good explanation of DAA.

Prior to transmission to the TP, the signature is encrypted using the public part of the EK; as a result it can only be decrypted by the TPM it is destined for.

Is quite frankly incorrect. The issuer authenticates the TP as follows: On receipt of the bling message U, the issuer creates a nonce n_i encrypts it with the public endorsement key of the TPM and returns the encrypted value. The TP computes hash(U||n_i) and sends it to the issuer. The issuer checks the value is correct and is convinced that it is communicating with a valid TP.

The description of rogue tagging is confusing and quite probably wrong - although I am unable to tell because it doesn't quite make sense... The paper does not distinguish between the zeta value which is used during the Join protocol and the zeta value used during the Sign/Verify protocols. —The preceding unsigned comment was added by Bah23 (talk • contribs) 13:39, 31 January 2007 (UTC).

idemix

idemix should be discussed somewhere in the main body of the text in order to explain its relevance. —The preceding unsigned comment was added by Bah23 (talk • contribs) 11:12, 6 February 2007 (UTC).

No anonymity revocation

I believe that the claim about anonymity revocation is incorrect. The principle referenced paper by Brickell et. al. states that "... our scheme can be seen as a group signature scheme without the capability to open signatures (or anonymity revocation)...".

This problem is touched on in a separate discussion above, but was not addressed.

Perhaps the author was confusing the notion of anonymity revocation with the blacklisting capability, which exists, but still preserves anonymity.

I'm removing the claim from the article.

Leotohill (talk) 03:06, 28 June 2009 (UTC)

On zero knowledge, tracking and signing keys

I would suggest to remove reference to zero knowledge. Challenges are generated at DAA Join and Sign with a hash and not by a Verifier. Zero knowledge requires a simulator that was never introduced for DAA. Choosing a challenge with a hash makes simulator (almost) impossible. A general reference to proofs of knowledge still may be acceptable.

A DAA Verifier colluding with a DAA Issuer can always track DAA Users that have specific credentials issued, as explained in IACR 2008/277 preprint.

Signing keys (like RSA) with DAA may be considered pointless because of easy linking all signatures produced with that keys. In may be advised to sign messages instead. 132.204.53.187 (talk) 20:17, 30 June 2010 (UTC)