Copyright © 2013-2021 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 Privacy-CA [TPMv1-2-Part1]. Translated to FIDO, this approach would require one Privacy-CA interaction for each Uauth key. This means relatively high load and high availability requirements for the Privacy-CA. Additionally the Privacy-CA aggregates sensitive information (i.e. knowing the relying parties the user interacts with). This might make the Privacy-CA an interesting attack target.
Another alternative is the Direct Anonymous Attestation [BriCamChe2004-DAA]. 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 DAA-Sign protocol with each relying party. The DAA scheme has been adopted by the Trusted Computing Group for TPM v1.2 [TPMv1-2-Part1].
In this document, we specify the use of an improved DAA scheme based on [CamDriLeh16-DAA] [CCDLNU2017-DAA] 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 NON-INFRINGEMENT, 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.
denotes scalar multiplication (with scalar x) of a (elliptic) curve point P.
RAND(x) denotes generation of a random number between 0 and x-1.
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 .
The ECPoint2 has two affine coordinates each having two components of type BigNumber
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. 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 non-normative.
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 ECDAA-Sign.
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. [BriCamChe2004-DAA] or [BFGSW-2011].
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 ECDAA-Join step are out-of-scope 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 ECDAA-Sign and ECDAA-Verify 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 [BFGSW-2011]. The algorithm was modified in order to fix security weaknesses (e.g. as mentioned by [ANZ-2013] and [XYZF-2014]). 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 right-aligned 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 ,
see section 4.1 Supported Curves for ECDAA.
Each ECPoint2 is represented by a pair (a, b) of elements of .
We always assume normalized (non-zero) ECPoint2 values (i.e. cz = 1) before encoding them.
Non-zero 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 , Pairings, hash function \)
See section 4.1 Supported Curves for ECDAA.
The ECDAA Issuer public key ipk MUST be dedicated to a single authenticator model.
We use the element of ipk as an identifier for the ECDAA Issuer public key (called ECDAA Issuer public key identifier).
One ECDAA-Join 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 ECDAA-Join operation. This operation needs to be performed a single time (before the first credential registration can take place). After the ECDAA-Join, the authenticator will use the ECDAA-Sign 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 in-factory, 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.
;
;
This section is non-normative.
If this join is not in-factory, 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 . They should persist even in the case of a factory reset.
This section is non-normative.
The Endorsement key credential (EK-C) and TPM2_ActivateCredentials are used for supporting the remote Join.
This description is based on the principles described in [TPMv2-Part1] section 24 and [Arthur-Challener-2015], page 109 ("Activating a Credential").
TPMT_PUBLIC [TPMv2-Part2]
(including the public key in field unique) to the ASM.
TPMT_PUBLIC (including in field unique),
to the ECDAA Issuer.objectAttributes in TPMT_PUBLIC [TPMv2-Part2]
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 [TPMv2-Part1], section 16.
One ECDAA-Sign operation is required for the client-side 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 non-normative.
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 MUST be unguessable and unique, e.g. compute H(RAND(p), AppID, ++seqCntr) if in doubt about RAND quality, where seqCntr counts the ECDAA-Sign operations performed by this ASM.
This section is non-normative.
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 [CCDLNU2017-DAA]).
Algorithm outline
This section is normative.
One ECDAA-Verify operation is required for the FIDO Server as part of each FIDO Registration.
Parameters
Algorithm outline
and
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 : over with .Definition of G2
G2 is the p-torsion subgroup of where E' is a sextic twist of E. With E' : .An element of is represented by a pair (a,b) where a + bX is an element of . We use angle brackets to signify the ideal generated by the enclosed value.
In the literature the pair (a,b) is sometimes also written as a complex number .
Definition of GT
GT is an order-p subgroup of .Pairings
We propose the use of Ate pairings as they are efficient (more efficient than Tate pairings) on Barreto-Naehrig curves [DevScoDah2007].Supported BN curves
We use pairing-friendly Barreto-Naehrig [BarNae-2006] [ISO15946-5] elliptic curves.
The curves TPM_ECC_BN_P256 and
TPM_ECC_BN_P638 curves are defined in [TPMv2-Part4].
BN curves have a Modulus [ISO15946-5] and a related order of the group [ISO15946-5].
TPM_ECC_BN_P256 is a curve of form E(F(q)), where q is the field modulus
[TPMv2-Part4] [BarNae-2006]. This curve is identical to the P256 curve defined in [ISO15946-5] 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 [TPMv2-Part4] uses
ECC_BN_DSD_P256 [DevScoDah2007] section 3 uses
ECC_BN_ISOP512 [ISO15946-5] section C.3.7 uses
Spaces are used inside numbers to improve readability.
Hash Algorithm
Depending on the curve, we use H(x) = SHA256(x) mod p or
H(x) = SHA512(x) mod p as hash algorithm H:.
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 IHF1-SHA 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 | ; 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 | ; 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: , see 3.4.1 ECDAA-Join Algorithm. |
| UINT8[] ECDAA_Signature_T | 2*N+1 | ; 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 | ; computed by the ASM or the authenticator at
FIDO registration encoded as byte string according to ECPointToB.
Where is computed by the ECDAA Issuer at Join (see 3.4.1 ECDAA-Join Algorithm). |
This section is non-normative.
A detailed security analysis of this algorithm can be found in [CamDriLeh16-DAA].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 to-be-signed 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 of an authenticator has been leaked, it can be revoked by adding its value to a RogueList.
The ECDAA-Verifier (i.e. FIDO Server) check for such revocations. See section 3.6 ECDAA-Verify 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=() may be performed by the ASM running on the FIDO user device (as opposed to inside the authenticator). See section 3.5.2 ECDAA-Sign 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 byte-wise 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 (fixed-length) 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 [TPMv2-Part4] 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) | [CamDriLeh16-DAA] |
| Algorithm Name | "ED512" |
| Algorithm Description | ECDAA algorithm based on ECC_BN_ISOP512 [ISO15946-5] 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) | [CamDriLeh16-DAA] |
| Algorithm Name | "ED638" |
| Algorithm Description | ECDAA algorithm based on TPM_ECC_BN_P638 [TPMv2-Part4] 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) | [CamDriLeh16-DAA] |