Copyright © 20132021 FIDO Alliance All Rights Reserved.
The FIDO Basic Attestation scheme uses attestation "group" keys shared across a set of authenticators with identical characteristics in order to preserve privacy by avoiding the introduction of global correlation handles. If such an attestation key is extracted from one single authenticator, it is possible to create a "fake" authenticator using the same key and hence indistinguishable from the original authenticators by the relying party. Removing trust for registering new authenticators with the related key would affect the entire set of authenticators sharing the same "group" key. Depending on the number of authenticators, this risk might be unacceptable high.
This is especially relevant when the attestation key is primarily protected against malware attacks as opposed to targeted physical attacks.
An alternative approach to "group" keys is the use of individual keys combined with a PrivacyCA [TPMv12Part1]. Translated to FIDO, this approach would require one PrivacyCA interaction for each Uauth key. This means relatively high load and high availability requirements for the PrivacyCA. Additionally the PrivacyCA aggregates sensitive information (i.e. knowing the relying parties the user interacts with). This might make the PrivacyCA an interesting attack target.
Another alternative is the Direct Anonymous Attestation [BriCamChe2004DAA]. Direct Anonymous Attestation is a cryptographic scheme combining privacy with security. It uses the authenticator specific secret once to communicate with a single DAA Issuer and uses the resulting DAA credential in the DAASign protocol with each relying party. The DAA scheme has been adopted by the Trusted Computing Group for TPM v1.2 [TPMv12Part1].
In this document, we specify the use of an improved DAA scheme based on [CamDriLeh16DAA] [CCDLNU2017DAA] that uses elliptic curves and bilinear pairings.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current FIDO Alliance publications and the latest revision of this technical report can be found in the FIDO Alliance specifications index at https://fidoalliance.org/specifications/.
This document was published by the FIDO Alliance as a Review Draft. This document is intended to become a FIDO Alliance Proposed Standard. If you wish to make comments regarding this document, please Contact Us. All comments are welcome.
This is a Review Draft Specification and is not intended to be a basis for any implementations as the Specification may change. Permission is hereby granted to use the Specification solely for the purpose of reviewing the Specification. No rights are granted to prepare derivative works of this Specification. Entities seeking permission to reproduce portions of this Specification for other uses must contact the FIDO Alliance to determine whether an appropriate license for such use is available.
Implementation of certain elements of this Specification may require licenses under third party intellectual property rights, including without limitation, patent rights. The FIDO Alliance, Inc. and its Members and any other contributors to the Specification are not, and shall not be held, responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights.
THIS FIDO ALLIANCE SPECIFICATION IS PROVIDED “AS IS” AND WITHOUT ANY WARRANTY OF ANY KIND, INCLUDING, WITHOUT LIMITATION, ANY EXPRESS OR IMPLIED WARRANTY OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Type names, attribute names and element names are written as code
.
String literals are enclosed in “”, e.g. “ED256”.
In formulas we use “” to denote byte wise concatenation operations.
$X = P^x$ denotes scalar multiplication (with scalar x) of a (elliptic) curve point P.
RAND(x) denotes generation of a random number between 0 and x1.
RAND(G) denotes generation of a random number belonging to Group G.
Specific terminology used in this document is defined in [FIDOGlossary].
The type BigNumber
denotes an arbitrary length integer value.
The type ECPoint
denotes an elliptic curve point with its affine coordinates x and y.
The type ECPoint2
denotes a point on the sextic twist of a BN elliptic curve over $F(q^2)$.
The ECPoint2 has two affine coordinates each having two components of type BigNumber
As well as sections marked as nonnormative, all authoring guidelines, diagrams, examples, and notes in this specification are nonnormative. Everything else in this specification is normative.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].
This section is nonnormative.
FIDO uses the concept of attestation to provide a cryptographic proof of the authenticator [FIDOGlossary] model to the relying party. When the authenticator is registered to the relying party (RP), it generates a new authentication key pair and includes the public key in the attestation message (also known as key registration data object, KRD). When using the ECDAA algorithm, the KRD object is signed using 3.5 ECDAASign.
For privacy reasons, the authentication key pair is dedicated to one RP (to an application identifier AppID [FIDOGlossary] to be more specific). Consequently the attestation method needs to provide the same level of unlinkability. This is the reason why the FIDO ECDAA Algorithm doesn't use a basename (bsn) often found in other direct anonymous attestation algorithms, e.g. [BriCamChe2004DAA] or [BFGSW2011].
The authenticator encapsulates all user verification operations and cryptographic functions. An authenticator specific module (ASM) [FIDOGlossary] is used to provide a standardized communication interface for authenticators. The authenticator might be implemented in separate hardware or trusted execution environments. The ASM is assumed to run in the normal operating system (e.g. Android, Windows, ...).
This document describes the FIDO ECDAA attestation algorithm in detail.
The technical implementation details of the ECDAAJoin step are outofscope for FIDO. In this document we normatively specify the general algorithm to the extent required for interoperability and we outline examples of some possible implementations for this step.
The ECDAASign and ECDAAVerify steps and the encoding of the related ECDAA Signature are normatively specified in this document. The generation and encoding of the KRD object is defined in other FIDO specifications.
The algorithm and terminology are inspired by [BFGSW2011]. The algorithm was modified in order to fix security weaknesses (e.g. as mentioned by [ANZ2013] and [XYZF2014]). Our algorithm proposes an improved task split for the sign operation while still being compatible to TPMv2 (without fixing the TPMv2 weaknesses in such case).
This section is normative.
We need to convert BigNumber
and ECPoint
objects to
byte strings using the following encoding functions:
BigNumber
values as byte strings (BigNumberToB)n
will be copied rightaligned into the buffer area b
.
The unused bytes will be set to 0. Negative values will not occur due to the construction of the algorithms.
b0 b1 b2 b3 b4 b5 b6 b7 0 0 n0 n1 n2 n3 n4 n5
ByteArray BigNumberToB( BigNumber inVal, // IN: number to convert int size // IN: size of the output. ) { ByteArray buffer = new ByteArray(size); int oversize = size  inVal.length; if (oversize < 0) return null; for (int i=oversize; i > 0; i) buffer[i] = 0; ByteCopy( inVal.bytes, &buffer[oversize], inVal.length); return buffer; }
ECPoint
values as byte strings (ECPointToB)(x, y) = ECPointGetAffineCoordinates(P) len = G1.byteLength byte string = 0x04  BigIntegerToB(x,len)  BigIntegerToB(y,len)
ECPoint2
values as byte strings (ECPoint2ToB)
The type ECPoint2
denotes a point on the sextic twist of a BN elliptic curve over $F(q^2)$,
see section 4.1 Supported Curves for ECDAA.
Each ECPoint2
is represented by a pair (a, b)
of elements of $F(q)$.
We always assume normalized (nonzero) ECPoint2 values (i.e. cz = 1) before encoding them.
Nonzero values are encoded using the expanded format (i.e. 0x04 for expanded)
followed by the cx followed by the cy value.
This leads to the concatenation of 0x04 followed by the first element (cx.a
) and
second element (cx.b
) of the pair of cx followed by the
first element (cy.a
) and second element (cy.b
) of the pair of cy.
All individual numbers are padded to the same length
(i.e. the maximum byte length of all relevant 4 numbers).
(cx, cy) = ECPointGetAffineCoordinates(P2) len = G2.byteLength byte string = 0x04  BigIntegerToB(cx.a,len)  BigIntegerToB(cx.b,len)  BigIntegerToB(cy.a,len)  BigIntegerToB(cy.b,len)
Definition of $G_1, G_2, G_T$, Pairings, hash function $H$\)
See section 4.1 Supported Curves for ECDAA.$H(P_2^{s_x} \cdot X^{c}  P_2^{s_y} \cdot Y^{c}  P_2  X  Y) \stackrel{?}{=} c$
$P_2^{s_x} \cdot X^{c} = P_2^{r_x + c x} \cdot P_2^{c x} = P_2^{r_x} = U_x$
$P_2^{s_y} \cdot Y^{c} = P_2^{r_y + c y} \cdot P_2^{c y} = P_2^{r_y} = U_y$
The ECDAA Issuer public key ipk MUST be dedicated to a single authenticator model.
We use the element $c$ of ipk as an identifier for the ECDAA Issuer public key (called ECDAA Issuer public key identifier).
One ECDAAJoin operation is required once in the lifetime of an authenticator prior to the first registration of a credential.
In order to use ECDAA, the authenticator must first receive ECDAA credentials from an ECDAA Issuer. This is done by the ECDAAJoin operation. This operation needs to be performed a single time (before the first credential registration can take place). After the ECDAAJoin, the authenticator will use the ECDAASign operation as part of each FIDO Registration. The ECDAA Issuer is not involved in this step. ECDAA plays no role in FIDO Authentication / Transaction Confirmation operations.
In order to use ECDAA, (at least) one ECDAA Issuer is needed. The approach specified in this document easily scales to multiple ECDAA Issuers, e.g. one per authenticator vendor. FIDO lets the authenticator vendor choose any ECDAA Issuer (similar to his current freedom for selecting any PKI infrastructure/service provider to issuing attestation certificates required for FIDO Basic Attestation).
There are two different implementation options relevant for the authenticator vendors (the authenticator vendor can freely choose them):
In the first case, physical proximity is used to locally establish the trust between the ECDAA Issuer and the authenticator (e.g. using a key provisioning station in a production line). There is no requirement for the ECDAA Issuer to operate an online web service.
In the second case, some credential is required to remotely establish the trust between the ECDAA Issuer and the authenticator. As this operation is performed once and only with a single ECDAA Issuer, privacy is preserved and an authenticator specific credential can and should be used.
Not all ECDAA authenticators might be able to add their authenticator model IDs (e.g. AAGUID) to the registration assertion (e.g. TPMs). In all cases, the ECDAA Issuer will be able to derive the exact the authenticator model from either the credential or the physically proximiate authenticator. So the ECDAA Issuer root key MUST be dedicated to a single authenticator model.
This section is normative.
If this join is not infactory, the value Q must be authenticated by the authenticator. Upon receiving this value, the ECDAA Issuer must verify that this authenticator did not join before.
$B^{s_1} \cdot Q^{c_1} = B^{r_1 + c_1 sk} \cdot Q^{c_1} = B^{r_1 + c_1 sk} \cdot B^{c_1 sk} = B^{r_1} = U_1$
$e(A, Y) = e(B^{1/y}, P_2^y) = e(B, P_2^{y/y}) = e(B, P_2)$;
$e(C, P_2) = e((A \cdot Q)^x, P_2)$; $e(A \cdot D, X) = e(A \cdot Q, {P_2}^x) = e((A \cdot Q)^x, P_2)$
This section is nonnormative.
If this join is not infactory, the value Q must be authenticated by the authenticator. Upon receiving this value, the ECDAA Issuer must verify that this authenticator did not join before.
These values belong to the ECDAA secret key $sk$. They should persist even in the case of a factory reset.
This section is nonnormative.
The Endorsement key credential (EKC) and TPM2_ActivateCredentials are used for supporting the remote Join.
This description is based on the principles described in [TPMv2Part1] section 24 and [ArthurChallener2015], page 109 ("Activating a Credential").
TPMT_PUBLIC
[TPMv2Part2]
(including the public key $P_1$ in field unique
) to the ASM.
TPMT_PUBLIC
(including $Q$ in field unique
), $c_1, s_1, n$
to the ECDAA Issuer.objectAttributes
in TPMT_PUBLIC
[TPMv2Part2]
matches the following flags:
fixedTPM
= 1; fixedParent
= 1; sensitiveDataOrigin
= 1;
encryptedDuplication
= 0;
restricted
= 1; decrypt
= 0; sign
= 1.
The parameter name in KDFa is derived from
TPMT_PUBLIC
, see [TPMv2Part1], section 16.
One ECDAASign operation is required for the clientside environment whenever a new credential is being registered at a relying party.
This section is normative.
(signature, KRD) = EcdaaSign(String AppID)Parameters
Algorithm outline
This section is nonnormative.
This split requires both the authenticator and ASM to be honest to achieve anonymity. Only the authenticator must be trusted for unforgeability. The communication between ASM and authenticator must be secure.
Algorithm outline
All values $l$ MUST be unguessable and unique, e.g. compute H(RAND(p), AppID, ++seqCntr) if in doubt about RAND quality, where seqCntr counts the ECDAASign operations performed by this ASM.
This section is nonnormative.
This algorithm is for the special case of a TPMv2 as authenticator. This case requires both the TPM and ASM to be honest for anonymity. Only the TPM must be trusted for unforgeability (see [CCDLNU2017DAA]).
Algorithm outline
This section is normative.
One ECDAAVerify operation is required for the FIDO Server as part of each FIDO Registration.
Parameters
Algorithm outline
$B = A^y = P_1^{l y}$
$D = Q = B^{sk}$
$S = B^l$ and $W = D^l$
$U = S^r$
$S^s \cdot W^{c} = S^{r + c sk} \cdot W^{c} = U \cdot S^{c sk} \cdot W^{c}$
$= U \cdot B^{l c sk} \cdot D^{l c} = U \cdot B^{l c sk} \cdot B^{l c sk} = U$
$e(R, Y) = e(A^l, P_2^y); e(S, P_2) = e(B^l, P_2) = e(A^{l y}, P_2)$
$e(T, P_2) = e(C^l, P_2) = e(A^{x l} \cdot Q^{x l y l_J}, P_2); e(A^l \cdot D^l, X) = e(A^l \cdot Q^{l y l_J}, P_2^x)$
TPMS_ATTEST
object. In this case the
verifier must check whether the TPMS_ATTEST
object starts
with TPM_GENERATED
magic number and whether its field
objectAttributes
contains the flag fixedTPM
=1
(indicating that the key was generated by the TPM).
This section is normative.
Definition of G1
G1 is an elliptic curve group E : $y^2 = x^3 + ax + b$ over $F(q)$ with $a=0$.Definition of G2
G2 is the ptorsion subgroup of $E'(F_{q^2})$ where E' is a sextic twist of E. With E' : $y'^2 = x'^3 + b'$.An element of $F(q^2)$ is represented by a pair (a,b) where a + bX is an element of $F(q)[X] / <X^2+1>$. We use angle brackets $<Y>$ to signify the ideal generated by the enclosed value.
In the literature the pair (a,b) is sometimes also written as a complex number $a+b*i$.
Definition of GT
GT is an orderp subgroup of $F_{q^{12}}$.Pairings
We propose the use of Ate pairings as they are efficient (more efficient than Tate pairings) on BarretoNaehrig curves [DevScoDah2007].Supported BN curves
We use pairingfriendly BarretoNaehrig [BarNae2006] [ISO159465] elliptic curves.
The curves TPM_ECC_BN_P256
and
TPM_ECC_BN_P638
curves are defined in [TPMv2Part4].
BN curves have a Modulus $q = 36 \cdot u^4 + 36 \cdot u^3 + 24 \cdot u^2 + 6 \cdot u + 1$ [ISO159465] and a related order of the group $p = 36 \cdot u^4 + 36 \cdot u^3 + 18 \cdot u^2 + 6 \cdot u + 1$ [ISO159465].
TPM_ECC_BN_P256
is a curve of form E(F(q)), where q is the field modulus
[TPMv2Part4] [BarNae2006]. This curve is identical to the P256 curve defined in [ISO159465] section C.3.5.
According to cryptographic research, this curve provides approx. 96 bits of security (see Crypto and CHES 2016) and hence should NOT be used any longer.
TPM_ECC_BN_P638
[TPMv2Part4] uses
ECC_BN_DSD_P256
[DevScoDah2007] section 3 uses
ECC_BN_ISOP512
[ISO159465] section C.3.7 uses
Spaces are used inside numbers to improve readability.
Hash Algorithm $H$
Depending on the curve, we use H(x) = SHA256(x) mod p
or
H(x) = SHA512(x) mod p
as hash algorithm H:$\{0, 1\}^* \rightarrow Z_p$.
The argument of the hash function must always be converted to a byte string using the appropriate
encoding function specific in section 3.1 Object Encodings, e.g. according to section
3.1.3 Encoding ECPoint2 values as byte strings (ECPoint2ToB) in the case of ECPoint2
points.
We don't use IEEE P1363.3 section 6.1.1 IHF1SHA with security parameter t (e.g. t=128 or 256) as it is more complex and not supported by TPMv2.
TPM_ECC_BN_P256
curve, using SHA256 as hash algorithm H.ECC_BN_DSD_P256
curve, using SHA256 as hash algorithm H.ECC_BN_ISOP512
curve, using SHA512 as hash algorithm H.TPM_ECC_BN_P638
curve, using SHA512 as hash algorithm H.The fields c and s both have length N. The fields R, S, T, W have equal length (2*N+1 each).
In the case of BN_P256 curve (with key length N=32 bytes), the fields R, S, T, W have length 2*32+1=65 bytes. The fields c and s have length N=32 each.
The ecdaaSignature object is a binary object generated as the concatenation of the binary fields in the order described below (total length of 356 bytes for 256bit curves):
Value  Length (in Bytes)  Description 

UINT8[] ECDAA_Signature_c  N  The c value, c = H(n  c2)
as returned by EcdaaSign encoded as byte string according to BigNumberToB.
Where

UINT8[] ECDAA_Signature_s  N  The s value, s=r + c * sk (mod p), as returned by EcdaaSign encoded
as byte string according to BigNumberToB.
Where

UINT8[] ECDAA_Signature_n  N  The Nonce value n, as returned by EcdaaSign encoded as byte string according to BigNumberToB. 
UINT8[] ECDAA_Signature_R  2*N+1  $R = A^l$; computed by the ASM or the
authenticator at FIDO registration; encoded
as byte string according to ECPointToB. Where

UINT8[] ECDAA_Signature_S  2*N+1  $S = B^l$; computed by the ASM or the authenticator at
FIDO registration encoded as byte string according to ECPointToB.
Where B has been provided by the ECDAA Issuer on Join: $B= (H(m),yc)$, see 3.4.1 ECDAAJoin Algorithm. 
UINT8[] ECDAA_Signature_T  2*N+1  $T = C^l$; computed by the ASM or the authenticator
at FIDO registration encoded as byte string according to ECPointToB.
Where

UINT8[] ECDAA_Signature_W  2*N+1  $W = D^l$; computed by the ASM or the authenticator at
FIDO registration encoded as byte string according to ECPointToB.
Where $D = Q$ is computed by the ECDAA Issuer at Join (see 3.4.1 ECDAAJoin Algorithm). 
This section is nonnormative.
A detailed security analysis of this algorithm can be found in [CamDriLeh16DAA].The proposed algorithms and key sizes are chosen such that compatibility to TPMv2 is possible.
Some authenticators (e.g. TPMv2) do not have the ability to include their model (i.e. vendor ID and model name) in attested messages (i.e. the tobesigned part of the registration assertion). The TPM's endorsement key certificate typically contains that information directly or at least it allows the model to be derived from the endorsement key certificate.
In FIDO, the relying party expects the ability to cryptographically verify the authenticator model.
We require the ECDAA Issuers public key (ipk=(X,Y,c,sx,sy)) to be dedicated to one single authenticator model (e.g. as identified by AAID or AAGUID).
If the private ECDAA attestation key $sk$ of an authenticator has been leaked, it can be revoked by adding its value to a RogueList.
The ECDAAVerifier (i.e. FIDO Server) check for such revocations. See section 3.6 ECDAAVerify Operation.
The ECDAA Issuer is expected to check revocation by other means:
The pairing algorithm e
needs to be used by the ASM as part of the Join process and by the
verifier (i.e. FIDO relying party) as part of the verification (i.e. FIDO registration) process.
The result of such a pairing operation is only compared to the result of another pairing operation computed by the same entity. As a consequence, it doesn't matter whether the ASM and the verifier use the exact same pairings or not (as long as they both use valid pairings).
For performance reasons the calculation of Sig2=($R, S, T, W$) may be performed by the ASM running on the FIDO user device (as opposed to inside the authenticator). See section 3.5.2 ECDAASign Split between Authenticator and ASM.
The cryptographic computations to be performed inside the authenticator are limited to G1. The ECDAA Issuer has to perform two G2 point multiplications for computing the public key. The Verifier (i.e. FIDO relying party) has to perform G1 operations and two pairing operations.
We use a simple bytewise concatenation function for the different parameters, i.e. H(a,b) = H(a  b).
This approach is as secure as the underlying hash algorithm since the authenticator controls the length of the (fixedlength) values (e.g. U, S, W). The AppID is provided externally and has unverified structure and length. However, it is only followed by a fixed length entry  the (system defined) hash of KRD. As a consequence, no parts of the AppID would ever be confused with the fixed length value.
Algorithm Name  "ED256" 
Algorithm Description  FIDO ECDAA algorithm based on TPM_ECC_BN_P256 [TPMv2Part4] curve using SHA256 hash algorithm. 
Algorithm Usage Location(s)  "alg", i.e. used with JWS. 
JOSE Implementation Requirements  Optional 
Change Controller  FIDO Alliance, Contact Us 
Specification Documents  Sections 3. FIDO ECDAA Attestation and 4. FIDO ECDAA Object Formats and Algorithm Details of [FIDOEcdaaAlgorithm]. 
Algorithm Analysis Document(s)  [CamDriLeh16DAA] 
Algorithm Name  "ED512" 
Algorithm Description  ECDAA algorithm based on ECC_BN_ISOP512 [ISO159465] curve using SHA512 algorithm. 
Algorithm Usage Location(s)  "alg", i.e. used with JWS. 
JOSE Implementation Requirements  Optional 
Change Controller  FIDO Alliance, Contact Us 
Specification Documents  Sections 3. FIDO ECDAA Attestation and 4. FIDO ECDAA Object Formats and Algorithm Details of [FIDOEcdaaAlgorithm]. 
Algorithm Analysis Document(s)  [CamDriLeh16DAA] 
Algorithm Name  "ED638" 
Algorithm Description  ECDAA algorithm based on TPM_ECC_BN_P638 [TPMv2Part4] curve using SHA512 algorithm. 
Algorithm Usage Location(s)  "alg", i.e. used with JWS. 
JOSE Implementation Requirements  Optional 
Change Controller  FIDO Alliance, Contact Us 
Specification Documents  Sections 3. FIDO ECDAA Attestation and 4. FIDO ECDAA Object Formats and Algorithm Details of [FIDOEcdaaAlgorithm]. 
Algorithm Analysis Document(s)  [CamDriLeh16DAA] 