Direct Anonymous Attestation
ARDA ARSLAN
We are trying to develop an authentication tool and we are confused about an issue about direct anonymous attestation. Since we don't want to use in-factory attestation method, we can't embed a private key to the authenticator device. How can we verify that the authenticator is not compromised without using an embedded private key? We are using FIDO ECDAA Algorithm document to implement DAA. Any code about DAA would be really helpful.
Thanks,
Arda Arslan
Rolf Lindemann
Hi Arda,
in the case of ECDAA, there is a Join function. This Join function runs between the DAA Issuer and the authenticator. This function relies on an established trust relationship between the authenticator and the DAA Issuer.
It can be performed in a factory, or in the field before first use. However in the latter case it still requires some secret in the authenticator (having been injected in the factory). However, the requirements for this "some secret" are less constrained than the one for the ECDAA private key (unlinkability is not an issue as this secret is only used with the DAA Issuer).
In general it is required for an authenticator to “somehow” protect its own integrity. FIDO doesn’t mandate specific measures here. However, we are working on a security certification scheme. Such scheme will likely define some requirements (depending on the targeted security level).
In addition we are working on a reference implementation for the FIDO ECDAA Algorithm.
Do you have crypto background in the DAA space (e.g. bilinear pairing algorithms)?
Kind regards,
Rolf
-----Ursprüngliche Nachricht-----
Von: fido...@fidoalliance.org [mailto:fido...@fidoalliance.org] Im Auftrag von ARDA ARSLAN
Gesendet: Mittwoch, 17. August 2016 15:53
An: FIDO Dev (fido-dev)
Betreff: [FIDO-DEV] Direct Anonymous Attestation
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/26acec79-a794-4043-a0ee-2376d9d3949b%40fidoalliance.org.
ARDA ARSLAN
Since we are developing an authenticator which will be used in mobile phones, the secret may be captured by a third party by decompiling our code. How can we be sure that this third party will not be able to use this secret to generate the same private key? In which part of the ECDAA should we use this secret?(Join, Sign or Verify)
When will this reference implementation for the FIDO ECDAA Algorithm be published? Actually we don't have a strong crypto background in the DAA space.
Thank you for your answer,
Arda
17 Ağustos 2016 Çarşamba 17:19:33 UTC+3 tarihinde Rolf Lindemann yazdı:
Hi Arda,
in the case of ECDAA, there is a Join function. This Join function runs between the DAA Issuer and the authenticator. This function relies on an established trust relationship between the authenticator and the DAA Issuer.
It can be performed in a factory, or in the field before first use. However in the latter case it still requires some secret in the authenticator (having been injected in the factory). However, the requirements for this "some secret" are less constrained than the one for the ECDAA private key (unlinkability is not an issue as this secret is only used with the DAA Issuer).
In general it is required for an authenticator to “somehow” protect its own integrity. FIDO doesn’t mandate specific measures here. However, we are working on a security certification scheme. Such scheme will likely define some requirements (depending on the targeted security level).
In addition we are working on a reference implementation for the FIDO ECDAA Algorithm.
Do you have crypto background in the DAA space (e.g. bilinear pairing algorithms)?
Kind regards,
Rolf
-----Ursprüngliche Nachricht-----
Von: fido...@fidoalliance.org [mailto:fido...@fidoalliance.org] Im Auftrag von ARDA ARSLAN
Gesendet: Mittwoch, 17. August 2016 15:53
An: FIDO Dev (fido-dev)
Betreff: [FIDO-DEV] Direct Anonymous Attestation
Hello,
We are trying to develop an authentication tool and we are confused about an issue about direct anonymous attestation. Since we don't want to use in-factory attestation method, we can't embed a private key to the authenticator device. How can we verify that the authenticator is not compromised without using an embedded private key? We are using FIDO ECDAA Algorithm document to implement DAA. Any code about DAA would be really helpful.
Thanks,
Arda Arslan
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+unsubscribe@fidoalliance.org.
ARDA ARSLAN
Can someone answer the questions I asked in my previous message?
Thanks,
Arda
18 Ağustos 2016 Perşembe 11:08:50 UTC+3 tarihinde ARDA ARSLAN yazdı:
Rolf Lindemann
Hi Arda,
> the secret may be captured by a third party by decompiling our code
If you are not using meaningful white-box crypto+obfuscation in your code you should use surrogate attestation (see https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-protocol-v1.0-ps-20141208.html#surrogate-basic-attestation).
> How can we be sure that this third party will not be able to use this secret to generate the same private key?
There are two mechanisms in general:
1) ECDAA Join is performed as part of the device production process where physical proximity is used as security binding or
2) ECDAA Join is performed in the field. In this case some other key (e.g. a device specific symmetric key) needs to be used as security binding between the device and the ECDAA-Issuer.
These processes typically cannot be implemented on an App level.
> In which part of the ECDAA should we use this secret?(Join, Sign or Verify)
This “other key” would be used as part of the ECDAA Join process.
The ECDAA Sign process which is used as part of the FIDO Registration uses the ECDAA Key to sign the attestation object.
> When will this reference implementation for the FIDO ECDAA Algorithm be published?
Not fully clear yet. I hope later this year.
Again: If you are implementing an authenticator as a mobile App running in Android or iOS and your do not use meaningful white-box crypto+obfuscation, you should use surrogate attestation (see link above).
Kind regards,
Rolf
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/26acec79-a794-4043-a0ee-2376d9d3949b%40fidoalliance.org.
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/fce9eb68-3af2-4dba-ae1f-85d8caf699ef%40fidoalliance.org.
ARDA ARSLAN
Thank you very much for your detailed answer.
Best regards,
Arda
24 Ağustos 2016 Çarşamba 11:56:16 UTC+3 tarihinde Rolf Lindemann yazdı: