# How many FIDO protocols are needed? Surveying the design, security and
market perspectives

Anna Angelogianni  University of Piraeus80, M. Karaoli & A. Dimitriou
St.PiraeusGreece<EMAIL_ADDRESS>,  Ilias Politis  University of
Piraeus80, M. Karaoli & A. Dimitriou St.PiraeusGreece<EMAIL_ADDRESS>and  Christos Xenakis  University of Piraeus80, M. Karaoli & A. Dimitriou
St.PiraeusGreece<EMAIL_ADDRESS>
(2021)

###### Abstract.

Unequivocally, a single man in possession of a strong password is not enough
to solve the issue of security. Studies indicate that passwords have been
subjected to various attacks, regardless of the applied protection mechanisms
due to the human factor. The keystone for the adoption of more efficient
authentication methods by the different markets is the trade-off between
security and usability. To bridge the gap between user friendly interfaces and
advanced security features, the Fast Identity Online (FIDO) alliance defined a
number of authentication protocols. Although FIDO’s biometric based
authentication is not a novel concept, still daunts end users and developers,
which maybe a contributor factor obstructing FIDO’s complete dominance of the
digital authentication market.This paper traces the evolution of FIDO
protocols, by identifying the technical characteristics and security
requirements of the FIDO protocols throughout the different versions while
providing a comprehensive study on the different markets (e.g., digital
banking, social networks, e-government, etc.), applicability, easy of use,
extensibility and future security considerations. From the analysis we
conclude that there is currently no dominant version of a FIDO protocol and
more importantly, earlier FIDO protocols are still applicable to emerging
vertical services.

FIDO, authentication, passwordless

††copyright: acmcopyright††journalyear: 2021††doi:
10.1145/1122445.1122456††ccs: Security and privacy Security protocols

##  1\. Introduction

It is a truth universally acknowledged that a single man in possession of a
strong password is not enough to solve the issue of security. Literature
proves that the classic username and password scheme has been subjected to
various attacks, regardless of the applied protection mechanisms. Indeed,
either due to limited security awareness from the user’s side (i.e., weak or
reused passwords etc.) or due to server side vulnerabilities (i.e, vulnerable
hash scheme), most data breaches of 2019 have been caused by password-related
vulnerabilities. One of the most famous attacks of 2020, affecting the Solar
Wings was caused by a weak password in the update server, resulting to huge
financial costs apart from the reputational damage (The Guardian, [n.d.]).
Phishing attacks are also wider nowadays with an estimated number of 8.3
million attacks for 2019 while during 2020 there was a 667% increase in
phishing scams in only 1 month during the COVID-19 pandemic (ENISA, 2020).
This fact dictates that even in cases where the users have chosen relatively
strong passwords, it is highly plausible that they might still fall victims of
credential theft. To overcome some of the issues caused by passwords, Multi-
Factor Authentication (MFA) has been proposed. Nevertheless, according to
literature (Siadati et al., 2017) neither MFA has established a secure
alternative as short message service (SMS) and voice protocols, that are
typically used to send the One Time Password (OTP) to the user, are not
encrypted. To this extend, SIM swapping attacks became popular in latest
years, leading to second factor authentication (2FA) bypassing (Europol, 2020)
(Yahoo Finance, 2020).

Different authentication schemes have been proposed throughout the years
however, all of them have failed to replace the existing username and
password. There are many reasons behind this failure nevertheless, the most
essential is the trade-off between security and usability. Even though modern
users are more familiar with the concept of security, therefore desire an
elevated level of protection, they are not willing to sacrifice their comfort.
This is where FIDO protocol arrives. FIDO comes to combine both security and
usability in a proven secure thus fast authentication scheme.

The concept of biometric authentication is not new. Nevertheless, until recent
years users were not familiar with these solutions. Furthermore, it is proven
by the existing literature that the same notion applies to developers too as
due to the lack of experience with such advanced security concepts, they tend
to implement them rather unsafely i.e., through faulty implementation of the
Android fingerprint API (Bianchi et al., 2018). Therefore, a protocol such as
the one suggested by the FIDO Alliance, proposes thus validates through its
certification process, a common set of requirements (FIDO Alliance, 2020b).
The FIDO protocol suggests a passwordless as well as a 2FA scheme that may use
biometric data or security keys instead of passwords. Although the idea of
biometric data has been broadly investigated by the existing literature, the
FIDO protocol has achieved to encompass it in a modern solution that manages
to verify both the user and the server side, preventing phishing among other
common attacks (FIDO Alliance, 2020a).

The first FIDO specifications were released during 2014, including i)
Universal 2nd Factor (U2F) and ii) Universal Authentication Framework (UAF)
definition. Since then, U2F has released two updated versions; v1.1 and v1.2
(Alliance, [n.d.]d) while UAF has also released two updated versions; v1.1
(Alliance, [n.d.]e) and v1.2 (Alliance, [n.d.]f) with the deviation that in
UAF v1.2 remains a review draft since 2017. The first working draft from W3C
concerning the API for WebAuthn (Balfanz and Lundberg, [n.d.]), was released
in 2016 while the FIDO Alliance rolled out the Client To Authenticator
Protocol (CTAP2) (Alliance, [n.d.]c) in 2018. There are working drafts that
support an alignment between UAF’s v1.2 and FIDO2 metadata nevertheless, the
two protocols remain distinct. Even though UAF was released prior to FIDO2, it
presents a limited applicability, whereas FIDO2 protocol has been successfully
coupled with Internet applications, with seemingly identical security
requirements nonetheless. It remains ambiguous though, whether FIDO2 replaces
the first FIDO protocols (i.e., UAF and U2F).

Stemming from this ambiguity and in order to identify the role of the various
FIDO protocols within the emerging 6G ecosystem, this paper comprehensively
studies and compares the technical and security design and implementation
characteristics of the FIDO protocols, including their message flows, message
formats and applications, focusing on their security attributes. This analysis
lies the foundations of a in depth critique on the adoption of the different
FIDO protocols from different markets and business sectors, the current and
future trends and the factors that fuel or prevent their faster adoptions. The
paper delves into possible drawbacks or difficulties in the implementation of
the FIDO protocols and presents the outlook for future directions that
different versions of FIDO should aim for. Focusing on the security aspects of
the FIDO implementations, the paper identifies the benefits of FIDO UAF and
FIDO2 protocols for application developers and security engineers and
underlines the importance of the different FIDO protocols for secure and
privacy preserving implementations over the future mobile and IoT networks
(i.e., 6G, factories of the future, Industry 4.0/5.0, Industrial IoT, etc.)

The rest of the paper is organised as follows. Sections 3, 4 and 5 detail the
technical and security characteristics of FIDO2 (WebAuthn & CTAP2), FIDO UAF
and FIDO U2F (CTAP1) protocols, respectively. In Section 6 a comprehensive
survey of the role of FIDO protocols in different markets and industries is
presented, while the technical, security and business factors affecting FIDO’s
adoption is discussed in Section 7. The paper concludes with Section 8.

##  2\. Related Work

Although the research over authentication protocols, multi-factor and
passwordless authentication including FIDO, is extensive, there are limited
studies focusing on the implementation aspects of FIDO protocols, their
applicability in real-world scenarios and the differences they reveal when
integrated in services across different verticals (i.e., digital banking,
e-governments, mobile applications, etc.). FIDO protocols are present in
almost every modern research work that deals with secure and user friendly
authentication.

In (Barbosa et al., [n.d.]) and (Guirat and Halpin, 2018) the overall security
guarantees provided by FIDO2/WebAuthn protocol are analyzed, exploring the
cryptographic dimension. Usability studies for FIDO2 passwordless scheme have
been conducted in (Ghorbani Lyastani et al., 2020) and (Farke et al., 2020)
including real participants. The results of (Ghorbani Lyastani et al., 2020)
demonstrated that most users evaluated passwordless authentication as a both
usable and secure alternative to passwords nevertheless the participants of
this study were particularly concerned about the case where their security key
gets lost, stolen or simply damaged. The authors in (Farke et al., 2020)
further deduced that despite the advanced level of security and usability
provided by key-based login, several participants switched back to password
manager solutions, built-in their browsers, which were faster. In addition,
not all browsers and operating systems supported WebAuthn in the time of the
conducted studies therefore some participants could not truly experience
passwordless authentication.

The first versions of FIDO protocols have been also widely studied throughout
the years. In (Feng et al., 2021) and (Panos et al., 2017) an analysis of the
UAF protocol from a cryptographic and security perspective is respectively
provided. Vulnerabilities and attacks against UAF have been researched in (Hu
and Zhang, 2016), (Panos et al., 2017), (Feng et al., 2021) and (Li et al.,
2020). In (Ciolino et al., 2019), (Das et al., 2018) and (Reese et al., 2019)
usability studies of U2F with external participants are performed.

The research works focusing on the identification and analysis of the
differences (protocol design, security provisions, etc.) are limited. The
study more closely related to this paper is presented in (Alam et al., 2019),
where the authors analyse the pitfalls of FIDO2/WebAuthn protocol for
developers, indicating that lack of sufficient understanding of the protocol,
insecure or incomplete of libraries and privacy concerns are pivotal issues
for the community. Nevertheless, the aforementioned study focuses solely on
FIDO2/WebAuthn while, this work tries to understand the reasons that led to
multiple FIDO protocols and the differences between these versions. The
hypothesis this work is based on is that none of the FIDO protocols have been
depreciated, in light of the newer releases, yet FIDO2/WebAuthn appears as the
most popular.

##  3\. FIDO2/WebAuthn and CTAP2 Overview

FIDO2 comprises of the latest addition in the FIDO group of protocols.
Although it resembles the first versions of the FIDO protocols (UAF and U2F),
FIDO2 is devoted to web browsers that act as FIDO clients. W3C in
collaboration with the FIDO Alliance released the WebAuthn API (Jones et al.,
2021), which is addressed to web app, user agent and authenticator developers
intending to support FIDO2 passwordless authentication. Authenticators could
be i) bound to the device or ii) external (i.e., security keys). In order to
cover the communication between the FIDO client and the external
authenticator, the FIDO Alliance released Client To Authenticator Protocol
(CTAP2) specifications.

WebAuthn supports more than one attestation methods to verify the model
identity of the authenticator:

  * •

Basic Full Attestation, where authenticators of the same model share a common
attestation private key and attestation certificate. This approach conceals
user’s identity in the event of a certificate revocation due to private key
compromise.

  * •

Basic Surrogate, also referred to as Self Attestation where the authenticator
does not have an attestation key therefore it uses the same private key as the
one generated for the authentication to the relying party. Basic Surrogate
does not provide any cryptographic proof of the authenticator’s security
characteristics.

  * •

Attestation CA, where the TPM holds the authenticator-specific ”endorsement
key” (EK) used to communicate with a trusted third party, the Attestation or
Privacy CA. The Attestation CA issues an Attestation Identity Key (AIK)
certificate for each key pair limiting the distribution of the EK to the
relying parties and adding a layer of privacy.

  * •

Anonymisation CA, where the CA dynamically generates per-credential
attestation certificates which however cannot be used to track the user.

  * •

Elliptic Curve Direct Anonymous Attestation (ECDAA) even though ECDAA was
developed by the members of the FIDO Alliance and was extensively mentioned in
the FIDO UAF as well as the first version of the WebAuthn specifications due
to its privacy benefits, nevertheless it was omitted from the level 2 version
of the WebAuthn API since it did not receive the analogous support from web
browsers.

  * •

None, where the relying party indicates that it does not wish to receive
attestation information.

The overall architecture of WebAuthn is based on the first version of the
protocols (i.e., UAF and U2F). On the relying party’s (RP) side there is the
server that maintains the requested service and handles the authentication
procedure. The relying party server may also communicate with the FIDO
Alliance Metadata Service (MDS) in order to assess the authenticators
(Alliance, [n.d.]k). Nevertheless, this communication is optional and out of
scope for WebAuthn. On the client’s side there is i) the relying party’s
JavaScript application, ii) the browser which acts as the FIDO client (alike
the one described in FIDO UAF), iii) the platform (corresponding to UAF’s
Authenticator Specific Module) and iv) the authenticator. The authenticator
may support a variety of user verification methods such as fingerprint, hand-
print, voice-print, face-print, eye-print, pattern, passcode or even location.
User verification and user presence are treated as two distinct procedures in
FIDO. In addition, silent authenticators, which neither authenticate the user
nor verify the user’s presence, are described. A main difference of between
WebAuthn and UAF, is that in WebAuthn, the messages exchanged between the
browser (FIDO client) and the platform (ASM), are not declared in the
specifications. The proposed API provides a level of abstraction.
Nevertheless, judging by UAF, the nature of this messages is focused on error
codes indicating specific problems from the authenticator’s side and FIDO
supported version statements. WebAuthn specifications further declare that the
discovery of the transports supported by a given authenticator is outside the
scope of the protocol for user agents.

The fundamental idea is that the credentials that belong to a specific user
are managed by a trusted authenticator, with which the WebAuthn relying party
interacts through the client platform. Relying party scripts can (with the
user’s consent) request the browser to create a new credential for future
authentication to the relying party. Registration and authentication are
performed in the authenticator and mediated by the client platform. The client
platform does not have access to the credentials, it can only access
information regarding the form or type of the objects. Similarly the relying
party does not possess the user verification information (i.e., fingerprint)
just the signed response produced by the authenticator. The authenticator may
also implement a user interface for the management of the credentials (reset
password, history, saved passwords, cookies or even credential deletion).
WebAuthn does not explicitly define the deregistration flow.

###  3.1. Authenticator Registration (Credentials Create)

The scope of registration is to enroll the authenticator to the relying party
and verify the validity of its attestation private key as well as its security
characteristics.

  1. (1)

Public key Credential Creation - navigator.credentials.create: The user
navigates to the website that offers the requested service in a browser and
chooses to “register a security key”. The registration operation is initiated
by the relying party which calls the navigator.credentials.create function to
request the creation of a new public key credential source. The
navigator.credentials.create includes

     * •

the origin of the relying party (e.g., domain, ip, host)

     * •

the sameOriginWithAncestors which is set to ”true” if the execution
environment is the same with the caller’s and ”false” for cross-origin

     * •

the options. The options object for the creation of the public key credentials
include data about i) the RP entity information (RPid and name), ii) the user
id, and the displayed name, iii) the random challenge, iv) the public key
credential parameters which denote the type (currently only one credential
type is defined, and that is ”public-key”) and the algorithm (i.e., ECDSA,
RSA) that must be used for the credentials, v) the timeout denoted the time
that the rp awaits for a response though this can be overwritten by the
client, vi) the exclude credentials which if present, then the type (“public-
key”), the id plus the transport, meaning the communication protocol with the
authenticator (e.g., USB, NFC, BLE or internal authenticator) of the excluded
credentials are defined, vii) the authenticator selection criteria, indicating
the relying party’s requirements on the authenticator. More specifically the
authenticantor attachment which indicates if the relying party prefers the
authenticator to be internal or cross-platform, the resident key if required
by the relying party, if the relying party requires to firstly identify the
user to provide the user’s credential IDs during authentication, or if it
requires user verification viii) the attestation preference regarding the
authenticator’s attestation statements (i.e., “none”, ”direct” as generated
from the authenticator, or “indirect” to protect user’s privacy or
”enterprise” for controlled deployments) and lastly, ix) the extensions.

The user agent checks on the presence and validity of the received information
and creates the ClientData instance which includes i) the type which is
“webauthn.create”, ii) the RP’s challenge, iii) the origin and iv) the token
binding which is optional and indicates the protocol used for the
communication of the user agent with the relying party. If the client supports
token binding, then its status is “present” and the id is set to a valid
string. Up to this day, no major browser has implemented the token binding
feature though (Grimes, 2020). The client data is serialized in JSON format
and hashed in ClientDataHash using SHA-256. Afterwards, the user agent starts
the timer from the timeout parameter, locates the available authenticators and
checks which ones match the authenticatorSelection. The user agent selects the
first authenticator in the list that matches the criteria and it is not
included in the excludeCredentialDescriptionList. The authenticator will be
appended in the issuedRequests until the process is finished.

  2. (2)

Authenticator Make Credential: The authenticator make credential operation is
initiated by the FIDO client which sends to the authenticator the
ClientDataHash and all the information that it received from the relying party
except for the timeout and the authenticator selection criteria as this
information is managed exclusively by the client. More specifically, the
following parameters are sent for the client to the authenticator:

     * •

the ClientDataHash

     * •

the id of the relying party (RPEntity)

     * •

the user entity, meaning the id and the display name of the user

     * •

whether the client satisfies the requirement of the relying party on a
resident key

     * •

the requirement on user presence. Currently not present in the latest version
of CTAP2.

     * •

whether the client satisfies the requirement of the relying party regarding
the user verification (i.e., required, preferred or discouraged)

     * •

the public key credential types and the algorithms as requested by the relying
party

     * •

the exclude credential descriptor list as provided by the relying party and

     * •

the extensions created by the client based on the extensions requested by the
relying party.

     * •

lately in the Level 2 version of the WebAuthn API, the Enterprise Attestation
Possible was added to cover individually-identifying attestations

In CTAP2 protocol i) pinAuth and ii) pinProtocol are included. The
authenticator confirms the validity of the received information and prompts
the user to give his/her consent displaying in parallel the id and the name of
the relying party as well as the name and the display name of the user’s
account.

  3. (3)

Attestation Object:  Once the user’s consent is acquired, either by verifying
the user or by testing his/her presence, the authenticator creates the public
key pair (public and private) and the user handle, which is a unique id
specified by the relying party per user account and facilitates the management
of the credentials. The authenticator will initialise the signature counter
and replies to the client by sending the attestation object which contains:

     * •

the authenticator data. The authenticatior data more specifically, contain i)
the hashed RPid, ii) the flags which signify the user presence, verification
and if the attested data or extensions are included, iii) the signature
counter, iv) the extensions and v) the attested credential. The attested
credential refer to the AAGUID, the credential id and its credential’s length
as well as the credential’s public key.

     * •

the attestation statement format

  4. (4)

Authenticator Attestation Response:  The FIDO Client after receiving the
response from the authenticator, constructs the clientDataJSON object which
includes: i) the type of the request (i.e., webautn.create), ii) the
challenge, iii) the origin of the relying party and iv) the tokenBinding
between the origin and the client. The FIDO Client will forward to the relying
party the following data:

     * •

the attestation object as received from the authenticator

     * •

the clientDataJSON object

     * •

the transport protocol used by the authenticator (i.e., NFC, BLE etc.)

     * •

the client extensions

The RP, after receiving the publicKeyCred object, will verify the clientData
as well as the hash of the clientDataJson and decode the attestation Object to
verify its validity. The flow is illustrated in Fig. 1.

Figure 1. FIDO2 Authenticator Registration Message Flow

###  3.2. User Authentication (Credentials Get)

  1. (1)

Make an Assertion - navigator.credentials.get:  There are 2 functions that can
be used in order to retrieve previously registered credentials:
[CollectFromCredentialStore] or [DiscoverFromExternalStore] depending on the
authenticator, whether it is external or not. In both cases, the functions
contain the same parameters (origin, options, sameOriginWithAncestors) the
difference is that in the case of the external authenticator, both functions
will be needed when the credentials will not be found within the device. The
message sent from the FIDO Server to the FIDO Client includes

     * •

the origin (i.e., domain). The options for the creation of the public key
credentials include data about i) the RP, such as the name, ii) the user such
as the user’s id, its name and displayed name iii) the random challenge, iv)
the public key credential parameters which denote the type (“public-key”) and
the algorithm (i.e., ECDSA) that must be used for the credentials, v) the
timeout, vi) the exclude credentials which if present, they define the type
(“public-key”), the id plus the transport, meaning the communication protocol
with the authenticator (i.e., usb, nfc, Bluetooth or internal authenticator),
vii) the authenticator selection criteria, indicating the requirements on the
authenticator type for example if it’s an internal authenticator or if the
client device requires a wrapped resident key in order to offload the
authenticator or if it requires user verification, viii) the attestation
preference on the authenticator attestation statements which can be set to
“none”, “indirect” for privacy or “direct” and lastly, ix) the extensions.

     * •

the sameOriginWithAncestors which indicates the execution environment (i.e.,
browsing context, navigation request)

     * •

the options

The User Agent will check the presence and validity of the values received and
create the ClientDataJSON (ClientData in JSON format) instance will be later
hashed. Afterwards, the User Agent will start the lifitimeTimer from the
timeout parameter, find the available authenticators and check their options
to determine whether any public key credentials are bound to this
authenticator. This validation is achieved using the RPId and appending it to
the authenticator’s issuedRequests. Authenticator Get Assertion:  The FIDO
Client will send the autthenticatorMakeCredential to the authenticator which,
includes:

     * •

the hashed clientData,

     * •

the id of the relying party,

     * •

the user entity,

     * •

the requirement of the device on the user presence,

     * •

the requirement on user verification,

     * •

the public key credential types and the algorithms,

     * •

the exclude credential descriptor list and

     * •

the extensions of the client

The authenticator will prompt the user to enter his/her credentials (i.e.,
fingerprint), check the received parameters and if no error code is reported,
it will increase the counter.

  2. (2)

Assertion : The authenticator will send its response to the client which
encapsulates:

     * •

the selected credential id,

     * •

the authenticator data

     * •

the signature and

     * •

the user handle of the selected credential

The authenticator data more specifically, contain the hashed RPid, the flags,
the signature counter, the extensions and the attested credential. The
attested credential refer to the AAGUID, the the credential id and its length
as well as the credential’s public key. The signature on the other hand refers
to the signed disjunction of the authenticator data with the client data hash.

  3. (3)

Assertion Response:  The FIDO Client forwards the information received from
the authenticator adding the

     * •

the clientData

     * •

the client extensions

The RP, after receiving the response will verify the clientData, the hashed
clientData, the challenge, the origin, the type of the request, the token
binding, the RPId, the user verification and user presence flags as well as
the counter and if the received data are indeed valid, then the authentication
ceremony will continue else it will fail. The flow is demonstrated in Fig. 2.

Figure 2. FIDO2 User Authentication Flow

###  3.3. Advanced Security

The request from the relying party to the client contains information
regarding the relying party, whether or not it is a cross origin object as
well as information regarding the user. This fact suggests that the credential
is issued for a specific username and origin (i.e., relying party) therefore,
phishing attacks will be rejected by the authenticator. Similarly, the
randomly generated challenge protects from replay attacks. It is of utmost
importance that the relying party has the option to choose the characteristics
of the authenticator (authenticatorSelection) hence, it may exclude
authenticators that do not match the chosen criteria or even revoke
authenticators where vulnerabilities have been discovered. To this extend a
certain security background is required by the developing and maintenance
team. During step (2), as demonstrated in the Fig. 1 and Fig.2, the FIDO
Client forwards most of the information received from the relying party to the
authenticator with the exception of the clientData, which is send as a hashed
object. The signature counter provides both synchronisation and protection
from replicated authenticators. The clientDataHash as well as the counter
provide protection in the case of a cloned authenticator or credential
disclosure. Additionally, as the RPid is hashed after exiting the
authenticator, and the client forwards it within the attestationObject, the
relying party may also verify the validity of the client, indicating round-
trip integrity. Lastly, the relying party will assure that the authenticator
matches indeed the desired criteria by inspecting the (AAGUID).

During the authentication, the credential id and user handle is also forwarded
from the authenticator to the relying party in order to verify that these
values match the stored ones (send during the registration of the
authenticator). Moreover, the authenticator sends a signed object containing
the authenticatorData and the hashed clientData, while the client also sends
the clientData to the relying party. As a result, the relying party may
compare the received values with the expected values and even identify whether
a modification took place either in the authenticator-level or in the FIDO
client-level, achieving round-trip integrity.

##  4\. FIDO Universal Authentication Framework (UAF) Overview

In UAF the supported authenticator attestation methods methods, include, the
Basic Full Attestation, the Basic Surrogate and the Elliptic Curve Direct
Anonymous Attestation (ECDAA). Similar to FIDO2, UAF communication has two
sides: i) the client and ii) the server. In FIDO UAF, the client is composed
of: i) the RP’s web application (i.e., frontend), ii) the FIDO Client, iii)
the ASM (Authenticator Specific Module) and iv) the authenticator. In
comparison with the FIDO2 where the ASM is omitted in view of a more granular
approach, UAF defines it as a distinct component. The server on the other hand
contains the relying party’s web application server (backend) and the FIDO
Server. The client side is responsible for the generation, storage and
handling of the credentials while the server’s obligation contains the
generation of the challenge as well as the validation and storage of the
information received from the client.

The FIDO Client implements the client’s side FIDO UAF protocol and acts as a
midpoint between the server and the authenticator. The ASM is the translator
between the FIDO Client and the authenticator that interprets the FIDO UAF
messages to authenticator commands. One of the most essential actors in FIDO
UAF is the authenticator. It can be an embedded, bound or an external device
(roaming authenticator) while it may support first or/and second factor
authentication. The difference between an external and a roaming authenticator
is that while in the external the keys and the counter will be stored within
the authenticator, in the roaming, the keys will be stored in the ASM. The
relying party contains the web server with the service that the user has
requested access to and the FIDO Server which handles the authentication
procedure.

FIDO UAF defines four processes i) authenticator registration, ii) user
authentication, iii) transaction confirmation and iv) authenticator
deregistration.

###  4.1. Authenticator Registration in FIDO UAF

If the user is already registered to the relying party’s web server he/she
will enter its credentials and they are verified then the latter will send a
header to the FIDO Server which includes information on i) the UAF version
(upv), ii) the operation (op) which in this case is registration, iii) the ID
of the application (appID) and iv) the serverData which is a session
identifier created by the relying party (i.e., expiration times for the
registration session).

Figure 3. FIDO UAF Authenticator Registration Message Flow

  1. (1)

Registration Request: After receiving the header from the server of the
relying party, the FIDO Server will create the Registration Request message
that it will be forwarded to the FIDO Client. The Registration Request
encloses:

     * •

the header as sent from the web server of the relying party

     * •

the username (used to distinguish the different accounts in the event that the
user has more than one accounts in the same relying party)

     * •

a randomly generated challenge

     * •

the policy which contains both allowed and disallowed criteria for the
authenticators, ordered by highest priority. Among the allowed criteria i)
authenticator attestation id (aaid) which refers to the specific authenticator
model, the ii) vendorID which refers to the authenticator’s vendor, the iii)
key ID (unique for each aaid, which is null at this point, since it refers to
the user authentication private key which has not been produced yet, the
method used for iv) user verification (i.e., fingerprint, PIN, etc.), v) the
mechanisms used for key protection (i.e., Trusted Execution Environment,
Secure Element, etc.) or vi) the method used for the matcher protection method
which matches the user inserted verification method to the previously stored,
the vii) attachmentHint indicating the communication protocol between the
authenticator and the user device (i.e., internal, Bluetooth, NFC, etc.), the
viii) tcDisplay designating whether the display is secure therefore it can
support Transaction Confirmation, the ix) supported authentication algorithms
(i.e., ECDSA), the x) supported assertion scheme (i.e., KRD for the
authenticator registration and signed data for the authentication map to
UAFV1TLV), the xi) supported attestation types (i.e., Basic Full), the xii)
authenticator version and the xiii) extensions. While, keyID is unique per
aaid but not per user account. This is the reason why UAF includes the
personna notion to cover different user accounts on the same relying party.

  2. (2)

Get Info ASM Request: The FIDO Client checks the policy and communicate with
all available authenticators to find the one that better matches the policy.
In order to achieve this, the FIDO Client first sends an ASM Request to the
ASM which, contains the type of the request (in this case it is a GetInfo
request), the ASM version indicating the supported FIDO version (i.e., 1.2)
and the extensions (exts). Normally ASM Requests also include the
authenticator index and the arguments but in this execution point, these
variables are null.

  3. (3)

Get Info Command: The ASM sends the GetInfo Command to the authenticator and
the latter responds to the ASM with the Get Info Command Response which
contains

     * •

the status code indicating a specific code in case of failure

     * •

the API version which verifies the supported api version of the authenticator
and

     * •

the authenticatorInfo which includes information regarding i) the
authenticator index enlisting all available authenticators discovered, ii) the
aaid and iii) the authenticator metadata. The authenticator metadata
encapsulates i) the authenticator type indicating whether the authenticator is
bound or external, first of second factor, ii) the maximum key handles that
can be processed in a single command, iii) the user verification method (i.e.,
fingerprint), the iv) key protection method, v) the matcher protection method,
vi) the tcDisplay designating whether the display is secure therefore it can
support Transaction Confirmation, vii) the supported authentication algorithm,
viii) the supported assertion scheme (i.e., KRD for versions 1.0 and 1.1. or
signed data available for v1.2) and ix) attestation type (i.e., Basic Full),
optionally the authenticator may return information on the supported
extensions and the tcDisplay type and characteristics.

  4. (4)

Get Info ASM Response: The ASM sends the ASM Response to the FIDO Client
containing, the status code, the responseData (of GetInfoOut type in this
case), which encloses the authenticatorInfo as send from the authenticator in
step (3), showcased in Fig. 3 and the extensions. The FIDO Client filters the
accepted authenticators according to the policy that where retrieved through
the GetInfo request and it verifies that facetID of the application is
authorized for the appID. The facetID could be cached in the FIDO Client’s
memory or it can be retrieved from the FIDO Server. Afterwards the FIDO Client
computes the final challenge parameters (fcp) which include: i) the challenge,
ii) the appID, iii) the facedID, and iv) the channelBinding, which contains
TLS information concerning the communication of the FIDO client with the FIDO
server such as the hashed TLS server certificate, the TLS server certificate
and the channel’s public key (cid_pubkey).

In UAF v1.2 ClientData has been proposed as an alternative to the fcp for
platforms that support WebAuthn and CTAP2. ClientData includes i) the
challenge, ii) the origin mapped to UAF’s facetID, iii) hashAlgorithm, iv)
tokenBinding mapped to UAF’s cid_pubkey of the channelBinding, and v) the
extensions

  5. (5)

Register ASM Request: The FIDO Client sends to the ASM, an ASM Request
indicating

     * •

the type of the request, which in this case is “Register”

     * •

the supported ASM version

     * •

the index of the chosen authenticator (authenticatorIndex), which refers to
all discovered authenticators

     * •

the args, which in this case is set to RegisterIn and contains information
such as i) the appID, ii) the username, iii) the fcp, iv) the facetID, v) the
channel binding data containing information regarding the TLS ChannelID
(cid_pubkey) and certificate and vi) the extensions.

The ASM locates the authenticator, by using the authenticatorIndex parameter,
checks if the user is already enrolled and requests either for user
verification (waiting to receive a UserVerificationToken) or user enrollment.
Next, it hashes the fcp and computes and hash the KHAccessToken which includes
i) the appID and if the authenticator is bound ii) the personnaID (obtained by
the operating system for each user account), iii) the ASMToken, which is a
random and unique ID generated by the ASM and iii) the CallerID which
specifies the platform (i.e., IOS).

  6. (6)

Register Command: Subsequently, the ASM sends the Register Command to the
authenticator which includes: i)the authenticatorIndex, ii)the appID, iii) the
hashed fcp, iv)the username, v) the attestationType, vi) the hashed
KHAccessToken and vii) the UserVerifyToken. The authenticator generates a new
key pair, the keyHandle and the keyID and then creates the key registration
data (KRD) structure which contains i) the aaid, ii) the assertionInfo, iii)
the hashed fcp, iv) the keyID, v) the signCounter, vi) the RegCounter and vii)
the UAuth.pub key. Successively, the authenticator sends the Register Command
Response to the ASM which contains the statusCode, the KRD for UAF v1.0 and
1.1, the signed KRD (with the UAuth.priv) for UAF v1.0 and 1.1, the
attestation certificate (for Basic Full attestation) and the keyHandle.

  7. (7)

Register ASM Response: The ASM will store the callerID, the appID, the
keyHandle, the keyID, the currentTimestamp if the authenticator is bound and
create the ASM Response comprising of

     * •

the statusCode

     * •

the responseData which in this case is set to RegisterOut containing the
assertion (signifying the KRD, the signed KRD and the attestation certificate
if the attestation scheme is Basic Full) as well as the assertionScheme.

  8. (8)

Registration Response: The UAF Client will create and send to the FIDO Server
the Registration Response holding

     * •

the header

     * •

the fcp or ClientData introduced in UAF v1.2

     * •

the assertionScheme

     * •

the KRD for UAF v1.0 and 1.1

     * •

the signed KRD for UAF v1.0 and 1.1

     * •

the attestation certificate (if applicable)

The FIDO Server will check all components of the Registration Response message
and afterwards it will hash the fcp and to if it matches with the hashed fcp
included in the KRD. Then, it will store the UAuth.pub, keyID, signCounter,
authenticatorVersion and the aaid. The FIDO Server may return the result to
the web server in order to let it inform the user. The flow is demonstrated in
Fig. 3.

###  4.2. User Authentication in FIDO UAF

As described in the authenticator registration, the process is initiated by
the user that wants to access a service and the web server that contains it
prompts the user for authentication by forwarding the header to the FIDO UAF
Server similarly to the Registration procedure including i) the supported UAF
version (upv), ii) the operation (op) which in this case is authentication,
iii) the appID and the iv) serverData, signifying the TLS information. The
flow is depicted in Fig. 4.

  1. (1)

Authentication Request: The FIDO Server generates the Authentication Request
which encloses:

     * •

the header

     * •

the randomly generated challenge

     * •

the policy which contains the allowed and disallowed criteria for the
authenticators, ordered by highest priority, as described in the Registration
step 1) with the only exception that the keyID is not null. The Relying Party
forwards the information to the FIDO Client.

  2. (2)

Get Info and Authenticate ASM Request: The FIDO Client obtains the facetID and
check if it is authorized for the specific appID. Afterwards it initiates a
GetInfo procedure, as described in the Registration (steps 2,3), in order to
discover all available authenticators and choose the one suitable according to
the policy. After choosing the authenticator, the FIDO Client computes the fcp
as thorougly presented in the step 4) of the Registration and subsequently
sends an ASM Request to the ASM containing:

     * •

the requestType, which is set to “Authenticate”

     * •

the asmVersion

     * •

the authenticatorIndex which defines the index of the selected authenticator

     * •

the args which is set to AuthenticateIn and incorporates i) the appID, ii) the
keyID and the iii) the fcp, iv) the facetID, v) the channel binding data and
vi) the extensions.

The ASM locates the authenticator, using the authenticatorIndex parameter, as
well as the keyHandle associated with the specific appID and keyID. Next, it
requests for user verification (UserVerificationToken) and if this step is
successfully completed then the ASM hashes the fcp and calculated the hash of
the KHAccessToken which includes the same information as described in
Registration’s step 5).

  3. (3)

Sign Command: The ASM sends the Sign Command to the authenticator which
includes:

     * •

the authenticatorIndex

     * •

the appID (optional)

     * •

the hashed fcp

     * •

the hashed KHAccessToken

     * •

the UserVerifyToken (optional)

     * •

the key handle

The authenticator verifies the user (using the retrieved
UserVerificationToken), locates the keyHandle and use it to validate the
KHAccessToken. If the user has more than one accounts, he/she will be asked to
choose the username. Next the authenticator prepares the Sign Command Response
which will be send to the ASM. The Sign Command Response encompasses:

     * •

the status code and either,
Option_1:

     * •

the username

     * •

the key handle or
Option_2:

     * •

data structure which includes: i) the aaid, ii) the assertionInfo (e.g., the
authenticator version, the authentication mode indicating whether user
explicitly verified, the signature and public key algorithm and encoding
format), iii) an authenticator nonce, iv) the hashed fcp, v) the keyID, vi)
the signCounter and

     * •

the data structure signed using the Uauth.priv.

  4. (4)

Authenticate ASM Response: The ASM creates the ASM Response which contains

     * •

the statusCode

     * •

responseData meaning the AuthenticateOut structure which includes the
assertion meaning the data and signed data) for option 2 of Authentication’s
step 3) and the assertionScheme

  5. (5)

Authentication Response: After receiving this message, the UAF Client will
send the Authentication Response to the FIDO UAF Server including the

     * •

the header

     * •

the fcp

     * •

the assertionScheme

     * •

the data

     * •

the signed data

The FIDO Server inspects all the components of the Authentication Response
message, hashes the fcp in order to compare it with the one included in the
data structure and checks whether the UAuth.pub key, the signCounter, the
authenticatorVersion and the aaid match the ones stored during the
registration and verifies the signature. Lastly, the FIDO Server returns an
allow-access-to-content message to the web server of the relying party.

###  4.3. Transaction Confirmation in FIDO UAF

Transaction Confirmation has the same message flow as Authentication however
some messages consist of additional information that refer mainly to the type
of the message, the display characteristics and the transaction content. The
flow is illustrated in Fig. 4 in green color.

  1. (1)

Authentication Request:  In addition to the messages included for the
Authentication procedure, in order to provide Transaction Confirmation
support, the FIDO Server further includes a transaction object which specifies
i) the content type, ii) the content and iii) the display characteristics
which is sent to the FIDO Client. It should be noted that the policy also
includes information on the tcDisplay.

  2. (2)

Get Info and Authenticate ASM Request The FIDO Client forwards the information
related to the transaction to the ASM

  3. (3)

Sign Command: The ASM further includes to the Sign Command the transaction
content or the hashed transaction content to the authenticator, which will be
verified and signed. In the Sign Command Response of option 2 the hashed
transaction content or the  transaction content are appended, while the
authentication mode object of the assertionInfo further describes if
transaction content has been shown on the display and user confirmed it by
explicitly verifying with authenticator.

  4. (4)

Authenticate ASM Response: The signed data containing the information on the
transaction content will be later sent back to the FIDO Client.

  5. (5)

Authentication Response: The relying party checks the hash of the transaction
content for the received and the cached object.

Figure 4. FIDO UAF User Authentication and Transaction Confirmation Message
Flow

###  4.4. Deregistration in FIDO UAF

  1. (1)

Deregistration Request: The deregistration process is required when the user
account is removed from the relying party. The later can trigger the
deregistration by asking the authenticator to delete the associated UAF
credentials that are bound to the user account. The flow is illustrated on
Fig. 5. To achieve that, the FIDO UAF Server will send a message to the FIDO
UAF Client containing the

     * •

the header (upv, op, appID, serverData, exts)

     * •

the information on the authenticator to be deleted, signifying the aaid and
the keyID

  2. (2)

Deregister ASM Request: The FIDO Client will create an ASM Request

     * •

the requestType which is set to “deregistration”

     * •

asmVersion

     * •

authenticatorIndex

     * •

args of “DeregisterIn” which contains the appID and the keyID.

  3. (3)

Deregister Command: The ASM will locate the authenticator using the
authenticatorIndex, construct the KHAccessToken and afterwards it will send to
the authenticator a message which includes

     * •

the authenticatorIndex

     * •

the appID (optionally)

     * •

the keyID

     * •

the hashed KHAccessToken (appID and if the authenticator is bound personnaID,
ASMToken, callerID)

  4. (4)

Deregister Response: The authenticator will delete the keys related to the
specific appID and user account and it will send back to the ASM

     * •

a status code indicating success or failure

Figure 5. FIDO UAF Deregistration Message Flow

###  4.5. Differences between versions 1.0, 1.1 and 1.2

The first generation of FIDO UAF specifications, 1.0 defined Basic Full and
Basic Surrogate as attestation types. ECDAA algorithm was introduced for the
first time in v1.1. Modifications have been introduced in v1.2 though, in
order to overcome the Diffie-Hellman oracle of TPM (Camenisch et al., 2017).

Since the upv and the asmVersion parameters indicate the supported UAF
version, their value is altered in different versions of the protocol.
Additionally, more codes were added in the authenticatorType, the
attestationType, the authenticationAlgorithm and the statusCode dictionaries
between v1.0 and v1.1. The length of the display characteristics information
was attached in the display characteristics parameter. In v1.2 the Metadata
Statement includes more information than the previous version such as the
alternativeDescriptions, operatingEnvironment as well as the cryptoStrength.
Additions were also applied in the authenticatorStatus in order to include
more information regarding the certification. The extensions parameter has
been also more thoroughly explained in the latest specifications.

###  4.6. Advanced Security

Alike FIDO2, UAF provides protection against phishing attacks by linking keys
to relying parties (using the appID and channelBinding information). The
randomly generated challenge provides protection against replay attacks while
UAF provides round-trip integrity. The communication between client and server
is performed via https protocol. Additionally, UAF offers a wide choice of
options regarding the security policy criteria. Apart from User
Authentication, Transaction Confirmation is also covered, leveraging of What
You See Is What You Sign (WYSIWYS) option offered by a Trusted User Interface
(TUI), fact that makes the protocol a perfect candidate for online
marketplaces. The signature counter provides synchronisation as well as
resilience against cloned authenticators.

###  4.7. FIDO UAF vs FIDO2

Both FIDO UAF and FIDO2 offer passwordless authentication. Nevertheless there
are some differences between the two. The obvious differences is that each
protocol serves a different scope. While FIDO2 aspires to be a web framework
dedicated to web browsers via W3C, FIDO UAF is mainly dedicated to the mobile
experience. On the other hand there are differences introduced from past
experience. For example, FIDO2 defines a timer for the client timeout of the
request while the notion of token binding as well as ECDAA attestation is not
included probably due to implementation difficulties and limited acceptance
from the developer’s side. In the place of ECDAA, Privacy CA has been
introduced as a solutions that offers privacy to the user but is also easier
to implement. The latest CTAP2 specifications mention fingerprint enrollment.
In general, the issue of privacy seems to be of major importance for WebAuthn
since the specifications dedicate a section to privacy enhancing mechanisms.
Compatibility between UAF and FIDO2 is achieved though through the clientData
object which is also included in the latest UAF v1.2 specifications as a
substitute to fcParams.

On the other hand, UAF seems to be more specific when it comes to the
communication of the client application with the authenticator in order to
identify all available authenticators GetInfo while the notion of bound and
silent authenticators is explicitly defined. Extensions in UAF’s versions v1.0
and v1.1 are processed by the client while in UAF v1.2 and FIDO2 the
extensions are also processed by the authenticator through the clientData
object. Additionally, UAF specifies two different counters: one for i)
registration (attestation) and another for ii) authentication (assertion)
while the server’s policy includes various criteria compared to FIDO2 plain
AAGUID which in UAF is equivalent to the AAID. UAF defines the notion of
personna which in FIDO2 is not discussed. Lastly UAF does not offer to the
client the option to choose a different hash algorithm between registration
and authentication. A summary of the major differences between FIDO UAF and
FIDO2 is demonstrated on Table 1.

Table 1. Differences between FIDO UAF and FIDO2. FIDO UAF |  FIDO2
---|---
Usually developed as an SDK |  API
Mostly used for mobile applications |  Used for the Web
appID as well as facetID for every “subdomain” or “facet” of the app (i.e., Android, iOS ). appID is RPID in FIDO2 |  Origin to facilitate the implementation as in UAF every subdomain (due to implementation difficulties) would need separate registration
Limited support |  Wider support, more open source works, browsers and OS have implemented their side
The timeout refers to the authenticator, if the authenticator takes too long then it will return a timeout error message to the client. Nevertheless the client is not instructed to set a desired timeout time. A timer does not exist for the client. |  The client initiates a Timer related to the timeout of the request
Specify federation namely |  Does not specify federation namely and describes that future work is needed in order to specify the tokens to add some form of manifest format with properties that declare the authentication type which the provider supports (in credential management document not in the WebAuthn).
Fingerprint enrolment was not part of the UAF spec. |  Fingerprint enrolment among with other parameters such as token PIN is described in CTAP2
Based on the notion of token binding |  No token binding up to this day
ECDAA was the major option |  ECDAA was rejected in the WebAuthn L2 specs since it was never implemented
The specifications define Basic surrogate |  Privacy CA was added
Did not take the issue of privacy under consideration in the first versions of UAF specs |  WebAuthn has a separate section for privacy consideration (i.e., deanonymisation techniques)
In the first versions of UAF fcParams (appID; challenge; facetID; channelBinding) was only the parameter for validation while clientData (challenge; origin; hashAlg; tokenBinding; extensions) was added in 1.2 • This challenge in clientData plays a similar role as the challenge field in FinalChallengeParams. • This origin plays a similar role as the the facetID field in FinalChallengeParams. • The hashAlg allows the client can freely select the hash algorithm - unlike FinalChallengeParams, where the authenticator must use the same algorithm as for signing the assertion. • This tokenBinding in clientData plays a similar role as the channelCinding field in FinalChallengeParams. |  clientData is the only the parameter for FIDO2
FIDO UAF defines every communication (i.e., Get Info, Transaction Confirmation and Deregistration) |  FIDO 2 does not define communication between browser and OS or the OS with the authenticator
UAF clearly explains what is saved in the authenticator and in the ASM |  WebAuthn mostly analyses what is stored in the authenticator
Silent authenticator are discussed |  Silent authenticators are not discussed but do exist when it comes to disable them
Extensions in older versions (1.0 and 1.1) were processed only by the client. |  In FIDO 1.2 and FIDO2 extensions, through the clientData stracture the extensions can be also processed by the authenticator
Registration and sign counter |  Sign counter only. Possibly because the registration counter was not so meaningful in terms of security.
The server’s policy includes acceptance criteria with many subcategories |  More “relaxed” using the AAGUID to exclude authenticators
AAID |  AAGUID
Defines the notion of personna |  Clearly defined how the user can choose among different accounts at the same site
In v1.0 and v1.1 the fcParams the client cannot choose the hash algorithm as the authenticator must use the same algorithm used during registration. In v1.2 due to the addition of the clientData, the client may also choose the hash algorithm. |  The client may select the hash algorithm

##  5\. FIDO U2F/CTAP1

One Time Passwords (OTP) are not considered safe alternatives compared to U2F,
since numerous attacks have been launched over the last years. SMS OTP have
proven a significant and simple attack vector due to the cellular network’s
vulnerabilities. FIDO’s Universal Second Factor Authentication (U2F) protocol
allows online services to augment the security of their existing username and
password scheme by adding a strong second factor. The user after providing the
username and password to the requested service, will also have to present an
additional information (i.e., a device). U2F’s focus on defining the
JavaScript API which allows the communication between the server, the FIDO
client (i.e., browser) and the authenticator. The FIDO U2F supports two
operations: i) registration and ii) authentication.

###  5.1. U2F Registration

The communication between the FIDO client and the relying party starts with
the first requesting to register. The U2F API may be exposed to web pages
either on low or high level, which is built on top of the MessagePort API. It
is generally recommended to use the high-level JavaScript API. Depending on
the implementation of the API, some of the exchanged messages differ.
Nevertheless, the relying party performs some common operations, as depicted
in Fig. 6.

  1. (1)

U2f Register Request: The relying party creates the Registration Request which
implies that it decides the U2F version to be used and the appID.
Additionally, the relying party generates the random challenge and stores all
the information related to the registration request.

  2. (2)

MessagePort API U2F Request

     * •

Option_1: Low-level The relying party sends to the FIDO client the U2fRequest
containing the i) type of the request implying a u2f_register_request in this
case, ii) the appID, iii) the timeoutSeconds and iv) the requestID. The
u2f_register_request dictionary further contains the v) register requests
which indicate the version and the challenge and the vi) registered keys which
indicate the version, the key handle, the transports (Bluetooth, NFC, USB) and
the appID related to the specific key handle.

     * •

Option_2: High-levelThe FIDO client upon receiving the registration request
(either on low-level or on high-level MessagePort API), creates the client
data object which includes the i) type, ii) the server challenge, iii) the
origin and iv) the public key of the TLS channel. Afterwards it generates the
challenge parameter which is the hashed client data object using SHA-256 and
sends it among with the application parameter, which is the hashed appID, to
the U2F device.

  3. (3)

U2F Register Raw Message: The U2F device after receiving the message from the
FIDO client, ensures the user’s presence and generates a key pair (k.pub and
k.priv) and the corresponding key handle which facilitates the detection of
the key pair if there are several. Next, the U2F device creates the response
message which is addressed to the FIDO client and contains i) a reserved byte
which is set to 0x05 for legacy reasons, ii) the public key, iii) the length
of the key handle, iv) the key handle, v) the attestation certificate and vi)
the signature of the reserved byte, the application parameter, the challenge
parameter, the key handle and the user’s public key.

  4. (4)

U2f Register Response:

     * •

Option_1: Low-level MessagePort API U2F Response  The FIDO client creates the
U2f response U2fResponse including i) the type of message, which is register,
ii) the response data, containing the version of the U2F protocol supported by
the device, the registration data that is the U2F register raw message (as
described in 4.1.2) and the client data object and iii) the requestID . The
U2f response is send from the FIDO client to the relying party.

     * •

Option_2: High-level MessagePort API U2F Response  This API provides a u2f
object with an interface for the register and sign operations. The interface
for register contains i) the appID, ii) the register request (version,
challenge), iii) the registered key (version, key handle, transports, appID),
iv) the register response containing the version of the U2f device, the U2f
register raw message and the client data or an error handler and v) the
timeout seconds.The relying party after receiving the registration response
either accepts or declines the registration.

Figure 6. U2F Registration

###  5.2. Authentication

Similarly to the registration, the authentication features the low and the
high-level definition of the API. The detailed flow is showcased in Fig. 7.

  1. (1)

MessagePort API U2f Sign Request The relying party sends a sign request to the
FIDO client in order to authenticate the user. As presented for the
registration process, the FIDO client may choose to support either the low-
level or the high-level MessagePort API.

     * •

Option_1: Low-level  The relying party sends to the FIDO client the U2fRequest
containing the i) type of the request implying a u2f_sign_request in this
case, ii) the appID, iii) the timeoutSeconds and iv) the requestID. The
u2f_sign_request dictionary further contains v) the server’s challenge and the
vi) registered keys which indicate the version, the key handle, the transports
(Bluetooth, NFC, USB) and the appID related to the specific key handle.

     * •

Option_2: High-level This API provides a u2f object with an interface for the
register and sign operations. The interface for register contains i) the
appID, ii) the challenge, iii) the registered keys (version, key handle,
transports, appID), iv) the sign response which is null at this point and v)
the timeout seconds.

The FIDO client verifies the appID of the caller and uses the challenge to
create the client data object. Later, it constructs the authentication request
message destined to the U2F device. This message contains i) a control byte,
ii) the challenge parameter, which is the hash of the client data, iii) the
application parameter that is the hashed appID, iv) the key handle and its
length.

  2. (2)

U2f Authenticate Raw Message:  The U2F device upon receiving the
authentication request creates the authentication response message which
includes i) a user presence message, ii) a counter and iii) the signature of
the application parameter, the user presence byte, the counter and the
challenge parameter. In parallel, the U2f device increments the counter in
each authentication operation.

  3. (3)

U2f Sign Response: The FIDO client after receiving the message from the U2F
device, creates the sign response addressed for the relying party which
contains i) the key handle, ii) the signature data that refers to the U2F
device’s raw message (as described in 4.2.2) and iii) the client data.

Figure 7. U2F Authentication

###  5.3. Advanced Security

Similarly to FIDO2 and FIDO UAF, U2F checks the validity of the authenticator
as well as, the relying party information therefore round-trip integrity is
achieved in U2F as well. The randomly generated challenge protects from replay
attacks while the counter protects from cloned authenticators. The main
difference that only user presence is needed while the relying party does not
define the policy as in UAF.

##  6\. Market penetration and applicability

###  6.1. Survey methodology

The work in (The FIDO Alliance, [n.d.]) and (CAN, [n.d.]) offer an overview
the browsers that support WebAuthn. It is evident that all major browsers
(i.e., Mozilla, Chrome, Opera, Safari and Edge) provide WebAuthn support at
least for their desktop version. Regarding the underlying operating systems,
Microsoft’s desktop version is currently the one with the wider support
allowing all types of authenticators. MacOS 14 enables users to use Touch ID
and Face ID for web logins, while it supports external authenticators as well
with the exception of NFC protocol that is not supported by macOS browsers in
general, and Firefox CTAP2 support which is not yet compatible. For in Linux
FIDO is available only through USB authenticators (Yubico, [n.d.]a), (Apple,
[n.d.]b). Mobile platforms such as Android 7.0 (“Nougat”) is certified as
compatible with FIDO2 since February 2019 (FIDO Alliance, 2019), which means
that most of the recent Android devices are FIDO-ready supporting CTAP2 for
both bound/internal and external authenticators, with the only exception of
NFC in Firefox. In iOS, WebAuthn and CTAP2 are offered only Safari browser
with the exception of BLE for authenticator transport protocol.

In (USB, [n.d.]) and (Yubico, [n.d.]b) services and websites that leverage of
WebAuthn and U2F are enlisted. Although the majority of the aforementioned
services have yet to completely opt-out of the username and password scheme,
FIDO constitutes a popular second factor authentication option. To this day
though, there are not many options from completely passwordless
authentication. The most widely-adopted passwordless experience has been
rolled out by Microsoft, supporting both User Presence and User Verification
as well as Resudenty Key(Yubico, [n.d.]a). The Windows 10 Hello for Business
allows corporate users to authenticate to an Active Directory or Azure Active
Directory using FIDO2 passwordless authentication. The user has priory
enrolled to Windows Hello through a two-step verification method. After the
initial enrollment the user may authenticate to the device using a
passwordless method such as a gesture or a fingerprint. Microsoft advises
administrators, apart from identifying the password usage and plan and
mitigation, to define the different work personas as a mean to manage the
different levels of privileges between the multiple departments of an
organisation. As described in (Microsoft, 2020), Windows Hello lets users
authenticate to:

  * •

a Microsoft account

  * •

an Active Directory account

  * •

a Microsoft Azure Active Directory (Azure AD) account

  * •

Identity Provider Services or Relying Party Services that support FIDO v2.0
authentication (in progress)

Samsung Pass, using Samsung Knox, is a FIDO-enabled service that enables
strong authentication across applications using biometrics and combined with a
cloud-based service provided by Samsung (Snyder, [n.d.]). With Samsung Pass,
smartphone users can lock up multiple sets of authentication credentials (from
both public and private enterprise services) with biometrics (Samsung,
[n.d.]). It is not clearly elaborated though whether Samsung Pass supports
FIDO2 or UAF or both.

The existing literature does not cover the UAF’s level of penetration from the
industry. In order get an indication of UAF’s applicability, we chose to
investigate the FIDO UAF certified showcases with a commercial deployment, as
appeared in (FIDO Alliance, 2020d). In (Li et al., 2020), researchers have
chosen a set of applications to examine for UAF nevertheless, their dataset
was focused on the Asian market, while it did not include the certified
showcases, use cases or products that are enlisted as FIDO2/U2F enabled. The
main objective was to prove whether FIDO UAF certified clients are still
supported or they have been replaced by FIDO2/WebAuthn, and answer the
question of whether FIDO UAF has become obsolete, or not.

The survey focused on commercial, FIDO UAF certified, applications available
at Google Play Store, as Android is the most popular operating system in
mobile devices at a global scale (StatCounter, 2020), while there are more
open-source tools available for reverse engineering the applications (i.e.,
apktool). Additionally, regarding native application development, due to the
openness of the Android platform in comparison with the iOS, it was presumed
as more a likely scenario to find Android applications that support FIDO as i)
there are more projects available as examples of a FIDO UAF Clients on GitHub
and dated older than the respective iOS ones (eBay, 2016) and ii) Android was
the first platform to offer FIDO2 OS-level support (FIDO Alliance, 2019).
Similarly to previous work (Kitsaki et al., 2018), our methodology for reverse
engineering and processing the applications was the following:

  1. (1)

Acquire the .apk file of the application to-be-investigated

  2. (2)

Use apktool and process the AndroidManifest.xml to discover any dependencies
with FIDO

  3. (3)

Use dex2jar tool to investigate for FIDO in the .jar classes

The survey which spanned a period from November to May 2021 was aided by the
reverse_apks 111https://github.com/AnnaAnge/reverse_apks, which automates the
above-mentioned procedures. Although the research methodology, applied for the
survey, returns results regarding the applications found to support FIDO with
high certainty, it is different for applications in which FIDO was not
discovered. This is due to two main reasons, namely,i) the .apk file may have
mechanisms that prevent reverse engineering and ii) the application may
support FIDO but through third-party libraries. In particular, the .apk files
were acquired from either apkmonk 222https://www.apkmonk.com or apkpure
333https://apkpure.com websites.

In addition to the enlisted services in (USB, [n.d.]) and (Yubico, [n.d.]b),
the certified products (FIDO Alliance, 2020d) and the performed reverse
engineering of Android applications, we ran a keyword search for the FIDO
protocols, utilising the GitHub API, in order to identify the level of
acceptance as well as the languages preferred by developers. The statistical
results from the keyword search queries that we applied are illustrated in
Table Tab. 4. From the retrieved results, it is safe to assume that there is
active interest on the FIDO protocols from the developer’s side. Currently
there are 331 and 135 public repositories that include the word ”FIDO” and
”FIDO2” respectively in their description. Delving into more detail, WebAuthn
seems to be the leading FIDO protocol (295 public repositories) with U2F
behind (86 public repositories) followed by CTAP (26 public repositories) and
UAF (17 public repositories).

###  6.2. FIDO applicability

FIDO2/WebAuthn and U2F covers a wider market. Among digital services that use
FIDO, Google (U2F and FIDO2), Dropbox, Github, Twitter, Yahoo Japan are
included. Usually FIDO2 is used as a second factor authentication, as an
upgrade to a pre-existing U2F implementation. Passwordless authentication via
FIDO2 or UAF was found to be less common, with the exception of Windows Hello
login.

UAF was discovered to be a less popular option. From our analysis we concluded
that i) Paypal, ii) Line Pay, iii) SoftBank, iv) Bank of America, v) Bank of
China, vi) Shinhan Bank, vii) Revolut, viii) National Health Service (NHS) ix)
T-Mobile, x) NokNok, xi) HYPR, xii) ReCred 444https://www.recred.eu/, xiii)
1Password, xiv) Google Play, xv) Cloudflare, xvi) 11st and xvii) TW FidO
supported FIDO in their mobile applications. More specifically, Bank of
America and Line Pay supported FIDO2 while the rest supported FIDO UAF
protocol. Therefore, it was presumed that for Financial Services & Banking as
well as Online markets & Retail that require a higher level of security both
for authentication and for transaction confirmation, UAF was the preferred
option, in the mobile application version. Interestingly enough, NHS which
belongs in the Health sector was also found to support UAF, indicating that
applications that handle sensitive data, trust UAF.

###  6.3. Survey of FIDO-related scientific publications

In order to identify and analyse the research works with interest to FIDO, a
survey was performed leveraging of the dblp API
555http://dblp.org/search/publ/api, for six keywords: i) FIDO, ii) FIDO2,
iii)UAF, iv) U2F, v) WebAuthn and vi) CTAP. The retrieved results from the
dblp API are illustrated in Fig. 2. We have further processed the results in
order to exclude duplicates. For example if a paper contained both ”FIDO2” and
”WebAuthn” in its title, we kept it only once (i.e., in WebAuthn since it was
more specific). After the initial process of the results, we manually
identified whether the title ”FIDO” or ”FIDO2” was dedicated to specific
version of the protocol.

Judging from the retrieved results, ”FIDO” and ”FIDO2” is the most commonly
found keyword in titles. Nevertheless after thoughtful study on the documents,
U2F was found to be the most popular FIDO protocol among research works
followed by UAF and FIDO2. Additionally, most research works have been
published for the first version of the FIDO protocols than the second.

Table 2. Numerical results from the keyword search in DBLP database CTAP | WebAuthn | U2F | UAF | FIDO2 | FIDO
---|---|---|---|---|---
0 | 3 | 7 | 6 | 6 | 1

This result is particularly interesting considering the deviation between the
research/academic field and the industry. While the first version of the
protocols (i.e., U2F and UAF) is broadly investigated by academia, in the
commercial world, the second version of the protocols (i.e., WebAuthn and
CTAP) is the most prominent, as in Section 7.4. It has to be underlined that
CTAP was not found as the main subject in any research work.

  1. (1)

FIDO - In (Kim et al., 2020) FIDO is used for user authentication in a smart
energy environment.The exact version of FIDO is not implicitly specified.

  2. (2)

UAF - Both (Feng et al., 2021) and (Panos et al., 2017) provide an analysis of
the UAF protocol from a cryptographic and security perspective respectively.
In (Li et al., 2020) an attack against the protocol is performed whereas
(Laborde et al., 2020) and (Zhen et al., 2019) explore the protocol’s
applicability, leveraging of UAF in order to provide authentication as well as
identification. (Zhang et al., 2018) discusses a TEE-based implementation of
the UAF’s Transaction Confirmation feature.

  3. (3)

U2F - The authors in (Ulqinaku et al., 2020) performed a study on user’s
susceptibility on phishing attacks even with FIDO enabled. The notion was that
FIDO could be downgraded to weaker 2FA alternatives. In (Ciolino et al.,
2019), (Das et al., 2018) and (Reese et al., 2019) usability studies of U2F
with external participants are performed. A U2F based protocol is presented in
(Fan et al., 2017) for mobile payments using the mobile phone’s UMTS
Subscriber Identity Module (USIM) and Secure Element (SE) while in (Reimair et
al., 2016) an extension of U2F is proposed in order to support smart cards and
mobile phones as authenticators. (Chang et al., 2017)

  4. (4)

FIDO2 - The work in (Barbosa et al., [n.d.]) provides a cryptographic security
analysis of the protocol, while (Klieme et al., 2020) proposes an extension to
the protocol in order to enable continuous authentication. In (Ghorbani
Lyastani et al., 2020) and (Farke et al., 2020) usability studies are
presented. (Wagner et al., 2021) and (Guo et al., 2020) suggest remote and
external FIDO2 authentication respectively, using QR codes. In (Chakraborty
and Bugiel, 2019) a sim TPM FIDO authenticator is presented.

  5. (5)

WebAuthn - A theoretical framework for a remote FIDO2 authentication, in cases
where specialised hardware is unavailable is presented in (Wagner et al.,
2021). Authors in (Alam et al., 2019) focus on the pitfalls of WebAuthn for
developers indicating that lack of sufficient understanding of the protocol,
insecure or incomplete of libraries and privacy concerns are pivotal issues
for the community. A novel cryptographic primitive is proposed in (Frymann et
al., 2020) in order to enable asynchronous key generation as well as account
recovery for WebAuthn.

  6. (6)

CTAP - To this day, there is no research work solely devoted on CTAP.

Table 3. Summary of business sectors and companies that use FIDO Business Sector | Company | Country | Web App | Mobile App
---|---|---|---|---
Backup & sync | Dropbox | US | ✓ | X
Files.com | US | ✓ | N/A
Google Drive | US | ✓ | X
Cloud Computing | Amazon Web Services, Google Cloud Platform | US | ✓ | X
Cryptocurrencies | Bitfinex | Hong Kong | ✓ | X
Coinbase | US | ✓ | X
Gemini | US | ✓ | X
Developer | Bitbucket | Australia | ✓ | N/A
Github | US | ✓ | X
Gitlab | US | ✓ | N/A
PyPI |  | ✓ | N/A
Sentry | US | ✓ | N/A
Domains | Gandi, Namecheap, Porkbun | US | ✓ | X
Education | University of Miami | US | ✓ | X
SUNET (University Computer Network) | Sweden | ✓ | N/A
Email | Fastmail, Gmail, Yahoo | US | ✓ | X
Mail.de, Tutanote | Germany | ✓ | X
Entertainment | Google Play | US | ✓ | ✓
Financial Services & Banking | Bank of America | US | ✓ | ✓FIDO2
Bank of China | China | X | ✓UAF 1.0
Google Pay | US | ✓ | X
Line Pay | Japan | ✓ | ✓FIDO2&U2F
Paypal | US | TBD | ✓
Revolut | US | X | ✓does not open .jar
Shinhan Bank | Korea | X | ✓
SoftBank Corp. | Japan | X | ✓
Stripe | US | ✓ |  X (not in .xml, jar was obfuscated)
Government | gov.uk | UK | ✓ | X
login.gov | US | ✓ | N/A
Ministry of Interior (TW FidO) | Taiwan | No info | ✓
Electronic Transactions Development Agency (ETDA) | Thailand | No info |  TBD (FIDO Alliance, 2020c)
Canadian Digital Service (CDS) | Canada | ✓ | N/A
Korea National Intelligence Service (KCIA) | Korea | ✓ | N/A
CZ.NIC | Czech Republic | ✓ | N/A
| SUNET (eduID) | Sweden | ✓ | N/A
Health and insurance | National Health Service (NHS) | UK |  TBD (Alliance, [n.d.]l) | ✓
Google Fit | US | ✓ | X
Hosting | Nitrado | Germany | ✓ | X
OVH | US | ✓ | X
| GoDaddy | US | ✓ | X
| Opalstack | US | ✓ | X
Identity Management | 1Password | US | ✓ | ✓FIDO2&U2F
Bitium | US | ✓ | N/A
Bitwarden | US | ✓ | X
Dashlane | US | ✓ |  X (not in .xml, jar was obfuscated)
Keeper | US | ✓ | X
| RSA SecurID Access | US | ✓ | X
| okta | US | ✓ | X
Investing | Vanguard | US | ✓ | N/A
Online markets / Retail | 11st | US |  | ✓UAF 1.0
Shopify | Canada | ✓ |  X (not in .xml, jar was obfuscated)
Ebay | US | ✓ | Neither .xml or .jar files were readable
Other | Office365 | US | ✓ | X
Security | Boxcryptor | Germany | ✓ | X
Cloudflare | US | ✓ | ✓UAF 1.0
dmarcian | US | ✓ | N/A
HYPR | US | ✓ | ✓
NokNok | US | ✓ | ✓
Self-hosted | Authelia |  | ✓ | N/A
Gluu | US | ✓ | N/A
GreenRADIUS | US | ✓ | N/A
LinOTP | Germany | ✓ | X
Nextcloud | Germany | ✓ | X
phpMyAdmin |  | ✓ | N/A
privacyIDEA |  | ✓ | N/A
Wordpress (software) | US | ✓ | X
Social media | Facebook | US | ✓ | X
Twitter | US | ✓ | X
Research Projects | H2020-DS-02-2014-ReCred | EU | X | ✓UAF 1.0
Telecom & Mobile | NTT DOCOMO | Japan | X | X (samsung auth sdk)
TMobile | US | X | ✓
✓:FIDO Enabled, X:FIDO not found, N/A:Web version only, TBD:To Be Developed |

##  7\. Critique on FIDO protocols adoption

The critique on FIDO adoption across the various markets, according to the
performed survey, is organised around 4 main pillars. The first pillar of the
analysis includes the developer perspective. Specifically, the discussion is
focusing on the aspects that render UAF and FIDO2 more popular and developer
friendly (i.e., wider support from the open source communities, etc.,) for the
service developers and providers. Second pillar of the analysis is
concentrated on the security shortcomings and known vulnerabilities that still
remain open. The third pillar is focusing on the emerging markets and services
in the Next Generation Internet and 6G era. Such landscape includes areas such
as IoT+AI, Industry 4.0 and beyond, etc. More complex privacy requirements
(AI-based decision making for sensitive services: healthcare, personal data,
etc.).

###  7.1. Compliance to standards and regulations (NIST 800-63, KYC, PSD2,
PCI-DSS and GDPR

Arguably, cybersecurity attacks may have irreversible consequences for the
vitality of an organisation therefore usually security thus privacy
requirements are dictated by regulations and standards, apart from the
organisation’s internal strategy. DevOps and security engineers are usually
mandated to comply and follow certain frameworks. FIDO is a fast, scalable and
extensible authentication framework that supports NIST 800-63, GDPR (Alliance,
[n.d.]m), PSD2(Alliance, [n.d.]i), KYC (Laborde et al., 2020) and PCI-DSS
compliance. Especially in the case of the latest release of NIST 800-63
guidelines, where different levels of authenticator assurance are introduced,
the Authenticator Assurance Levels (AAL), FIDO’s stakeholders such as Yubico,
identiv and queraltinc released new authenticators in order to reach AAL3 and
receive FIPS 140-2 validation, which is the optimal in terms of security. Most
of the FIDO authenticators are rated as AAL2 due to the fact that browsers do
not support token binding to deliver Verifier Impersonation Resistance, as in
Fig. 8.

Figure 8. FIDO requirements according to certification levels per NIST

###  7.2. Extensibility

FIDO protocol architecture is aiming towards a decentralised solution by
bringing the authentication into the user’s equipment, minimising the account
recovery requests. Nevertheless, the FIDO server is responsible for verifying
the result of the authenticator. For the purposes of identification and
authorisation though, FIDO is usually combined and used with federated
identity and authorisation protocols such as OpenID Connect and OAuth. FIDO
has been deployed with different themes that provide a linkage with a real
identity. K-FIDO is an example of an integration widely adopted and accepted
by end users to perform daily tasks. Several EU countries also suggest an
integration with eIDAS while there was a research for the implementation of
FIDO for the Brazilian eGov Program(Menegazzo Verzeletti et al., 2018). Due to
the latest travel restrictions with COVID, even digital passports (Politis et
al., 2021) or mobile driver’s licence and car keys that use FIDO have been
proposed (Blog, [n.d.]a).

These solutions though imply the co-existance with a third-party, which is not
an optimal solution in terms of privacy. Therefore, the integration of
Decentralised ID’s seems to be the next step in the authentication as well as
the identity and access management (IAM) ecosystem. The latest W3C
specifications of WebAuthn dedicate a section to privacy issues that may
occur. To this extend, IBM Security Verify solution proposes a set of
authenticator extensions for enhancing FIDO’s authentication capabilities and
allowing ID-less and passwordless authentication with QRCodes and FIDO, using
Keycloak and/or RedHat SSO (Security, [n.d.]). In (Othman and Callahan, 2018)
a Decentralised ID (DID) system is proposed which is UAF compatible. A FIDO-
based, privacy preserving solution is proposed in (Papadamou et al., 2020)
while (Farao et al., 2021) demonstrates how a solution as such could be used
in the future smart grid.

FIDO UAF although has not undergo a major update since 2017, is still
applicable in a variety of applications and services, according to the survey.
In particular, in (Chifor et al., 2018b) an authentication and authorization
flow for Wi-Fi enterprise networks, using FIDO UAF, is suggested. Nevertheless
it is limited to mobile phones with Tursted Execution Environment (TEE)
(Chifor et al., 2018b) while both (Togan et al., 2017) and (Chifor et al.,
2018a) propose FIDO UAF, IoT device support, leveraging of a smartphone.
Samsung has offered an API (Broadcom, 2020) for FIDO support. Even though
Samsung’s Tizen brings FIDO UAF clients to devices such as mobiles and
smartwatches (Developers, [n.d.]a),(Developers, [n.d.]b) it hasn’t been
implemented yet to support Smart TV’s (Developers, [n.d.]c).

The future of machine-to-machine authentication is expected to be
intrinsically linked to FIDO(Luo et al., 2021). Hints have been given though
in UAF specifications which have introduced the concept of silent
authenticators. Although there was a draft of FIDO IoT since 2020, the
standard was not released released till March 2021 (Geoffrey Cooper, [n.d.]).
The FIDO IoT specification covers both devices with IP and without IP
capabilities that contain Rendezvous information and Ownership voucher.
Although, the Fido Device Onboard (FDO) is designed for efficient, secure and
resource aware onboarding of restricted IoT devices, it limits its
applicability to device and network specific vertical applications, since it
does not reuse the existing FIDO authenticators, excluding most of the current
mobile devices used by home users. The conducted survey, clearly showcases
that the FIDO protocol suite, includes a variety of authentication mechanism
suitable for the rapidly evolving requirements of the Beyond 5G era, spanning
heterogeneous vertical industries and satisfying stringent security
requirements.

###  7.3. Browser and OS-level support

Microsoft Azure is the most complete FIDO2 solution to this day. It has been
successfully integrated in various use cases especially in the corporate
ecosystem Citrix and Okta workspace, leverage of the Microsoft Azure Active
Directory to offer passwordless authentication through FIDO2 (Citrix, 2020)
(Okta, [n.d.]). Microsoft advises developers that want to support FIDO2 in
their desktop applications to use either the "Microsoft Authentication Library
(MSAL)" with the "Windows Authentication Manager (WAM)" or the WebView2 in an
embedded browser (Microsoft, [n.d.]b). Microsoft’s native iOS and Android
support is under development.

Apple offers WebAuthn API’s since iOS & iPadOS 14 and macOS Big Sur 1,
announced in July 2020, focusing on the privacy aspect by adopting anonymous
attestation. Apple’s attestation format has been added in the latest WebAuthn
API Level 2 specification (Jones et al., 2021). In the Apple statement format
the AAGUID is all zeros, to conceal user’s privacy (Blog, [n.d.]b). In Safari,
NFC, USB, and Lightning FIDO2-compliant security keys are available via
"SFSafariViewController" and "ASWebAuthenticationSession"(Apple, [n.d.]a).
Regarding UAF support for iOS & iPadOS, apple has not relaeased any
documentation up to this day. There are though commercial SDK’s that
developer’s may use.

In Linux FIDO is provided by "libfido2" library, developed by Yubico and
"OpenSSH" which offer U2F and CTAP2 support(Wiki, [n.d.]b). In addition,
Yubico has developed a module for passwordless authentication via the
"Pluggable Authentication Module (PAM)" framework for system-wide user
authentication (Wiki, [n.d.]a). A FIDO package, based on "libfido2" library,
is available in popular Linux distributions such as Arch Linux, CentOS,
Fedora, Mageia, openSUSE, Solus as well as Debian and Ubuntu Linux (pkgs.prg,
[n.d.]),(Debian, [n.d.]). Regarding commercial distributions, Red Hat
Enterprise Linux offers UAF and U2F functionality via in RH-SSO and Keycloak
(Hat, [n.d.]),(Security, [n.d.]) while Oracle Linux Yum Server added FIDO2
functionality in within 2021 (Oracle, [n.d.]).

Android developers experienced a time advantage since it was the first mobile
OS to release FIDO2 platform support for bound/internal authenticators on
2019. The Android API for FIDO client currently supports U2F and FIDO2
(WebAuthn client) (Google, 2017), while CTAP2 support for external multi-
factor authenticators is yet to be released. For CTAP2 external authenticator
support, developers are still working with workarounds although it is
speculated that updates will be released in 2021.

###  7.4. Implementation difficulties

Although FIDO UAF was released prior to FIDO2/WebAuthn, there is no reference
to UAF support by Android. Mobile application developers have been
implementing UAF client through the com.uaf.fidoalliance package whose tag in
the .xml file is: "org.fidoalliance.uaf.permissions.FIDO_CLIENT". While there
are specialised SDK’s to enable the communication between the client
application and the authenticator, these solutions are not open source. The
performed reverse engineering confirmed that many services with certified FIDO
UAF clients, do not use them with the latest version of their application. One
possible explanation for the degradation of UAF could be the wider adaptation
of FIDO2. To this extend, numerous services are shifting towards the support
of FIDO2, which is the newest protocol. The reasons behind this wider
acceptance of FIDO2 vary. Firstly, many services, such as government
applications, do not offer specialised mobile applications therefore FIDO UAF
is, by default, not an option. Secondly, the integration of FIDO UAF seems to
be more challenging for developers, while FIDO2, due to its client support by
all major web browsers, seems to be a more tangible option. Before the release
of FIDO2, developers had to write a threefold code to cover i) the
communication of the firmware with the FIDO client application, ii) the
communication of the latter with the client application as well as iii) the
overall communication with the server. FIDO2 introduced a standards-based
approach which is supported by the major browsers as well as some OS. To this
extend, the work of developers has been limited to a twofold communication
between i) the authenticator and the client application and ii) the latter
with the server, which is supported by standardised API’s. This level of
abstraction allows less assumptions to be made by developers who are often
non-security experts while it reassures frequent updates and patches as well
as continuous support both from the developer’s side through a wide
developer’s community and from the end-user’s side since browsers provide
support to older devices as well. This assumption is also backed up by the
search performed on GitHub. UAF public repositories were limited whereas for
WebAuthn the list of public projects was extended.

Studying Table 4 one may deduce that languages used mainly for back-end web
programming (i.e., JavaScript, Java, Python, PHP, Ruby) are more popular for
FIDO development. This finding applies to WebAuthn’s search as well, in
alignment with WebAuthn’s scope that is the support of web applications
running on FIDO-enabled clients which are the browsers. Languages that are
essentially used for system programming, such as Rust and C, seem to be more
popular in CTAP than WebAuthn, which is in-line with the protocol’s
description. U2F search results contained both high and low level languages
which is explained by the fact that U2F is not separated into two sub-
protocols such as FIDO2 with WebAuthn and CTAP2. For UAF, Java was the leading
language, followed by other languages mainly used for web development. Here
the fact that low-level programming languages were missing is particularly
interesting. Even though Android does not support UAF in its API, Java is very
popular while our findings demonstrate insufficient support by the open source
community when it the communication with the authenticator, which is by
default a low-level system procedure. Another interesting finding is that
Swift, which is mainly used for iOS programming, was present in the WebAuthn
and UAF queries. It was observed that, in absolute values, the number of
projects between U2F and CTAP that use C or C++, which are considered as
unsafe languages due to memory issues, was decreased. On the contrary, the use
of Rust language was increased from version 1 to version 2 of the protocols,
dictating a turn to safer programming languages (Gaynor, 2021).

A further drawback in the implementation of the FIDO protocols is the account
recovery process. In order to overcome this issue, the FIDO Alliance
recommends either enrolling more authenticators or re-running identity
proofing. Relying parties, apart from encouraging users to enroll more than
one authenticators, should provide a reporting option in case of theft or
damage while they should revoke the stolen or lost credentials (Alliance,
[n.d.]n).

###  7.5. Other challenges for developers

A recent study by Votipka et al. (Votipka et al., 2020) enlists some important
factors that influence secure programming from the developers’ side. This work
concludes that i) improving the API documentation, ii) developing
vulnerability-finding tools, and iii) educating the developers, could provide
effective solution towards more reliant and secure programming. Even though
FIDO specifications are generally detailed enough, certain improvements would
admittedly facilitate developers as proven in the FIDO dedicated forum for
developers (see 666https://groups.google.com/a/fidoalliance.org/g/fido-
dev/c/OznyLnSA4Z0/m/UnT7_isXAgAJ).

Additionally, the CTAP2 specifications have been updated in order to cover
biometric authentication for external authenticators that desire an assurance
level such as AAL3 per NIST, as described in section 7.1. The biometric is
used to verify the user and unlock the private key to sign the server
challenge. Nevertheless, the updated and presumably more detailed CTAP version
2.2 has yet to be made accessible to the public; fact that poses an ”unfair”
advantage to the members of the Alliance.

In line with previous works, this study supports that solely a well-written
API documentation is not enough to engage developers with the FIDO solutions.
Vulnerabilities caused by implementation faults due to misunderstanding, API
misuse or limited security background, should be mitigated. Developers need to
have a basic knowledge of the protocols as well as where they may intervene
and configure parts of the communication and what configurations should be
chosen depending on the security and privacy needs of their organisation and
the service provided. Tools which aim to help developers in elevating their
knowledge of the protocol and finding bugs should be offered as well.
Accordingly to this educational need from the developer’s side, (Athanasios
Vasileios Grammatopoulos and Xenakis, 2021) presents a tool that analyses the
WebAuthn traffic of applications, aiming to to speed up the debugging process
and provide a direct insight into the WebAuthn requests and responses.

Table 4. Number of public Github repositories per language for the FIDO
protocols

.  Language Protocol U2F UAF WebAuthn CTAP FIDO FIDO2 JavaScript 17 0 81 5 57
21 TypeScript 0 0 33 1 2 2 PHP 6 1 32 0 13 6 Go 7 1 21 0 13 5 None 6 3 20 4 56
18 Java 7 8 19 7 36 12 HTML 1 1 18 1 10 9 Python 8 1 16 3 28 13 Ruby 5 0 10 0
10 1 C# 3 0 9 1 6 3 Elixir 1 0 6 0 3 0 CSS 1 0 4 0 6 4 Rust 7 0 4 2 7 5 C 6 0
3 1 13 6 Kotlin 0 1 3 1 5 7 C++ 2 0 3 0 9 3 Vue 0 0 3 0 1 0 Swift 1 1 2 0 5 0
PLpgSQL 0 0 2 0 0 0 Perl 2 0 0 0 3 0 Lua 1 0 0 0 1 0 Dockerfile 1 0 0 0 2 0
XLST 1 0 0 0 1 0 Objective C 1 0 0 0 2 0 Clojure 1 0 1 0 1 0 Nim 1 0 0 0 1 0
Haskell 0 0 1 0 0 1 Tex 0 0 1 0 1 2 Scala 0 0 1 0 0 0 Jupyter Notebook 0 0 1 0
2 0 Pascal 0 0 0 0 1 0 Makefile 0 0 0 0 1 2 TSQL 0 0 0 0 1 0 Shell 0 0 0 0 1 0
Dart 0 0 1 0 1 0 Vala 0 0 0 0 1 0 Total 86 17 295 26 331 135

Even though FIDO can be considered legacy authentication protocol, it has yet
to become the dominate authentication protocol, eliminating the use of
passwords, due to the inability of the computer science community to convince
users and stakeholders that personal biometric data will remain private and
the sovereignty of their ID information will be ensured.

###  7.6. Discovered Vulnerabilities and Mitigation Techniques

The FIDO Alliance advises developers to align with standards and programming
best practices such as the ones documented by OWASP(OWASP, [n.d.]) and acquire
FIDO Certification to guarantee compliance with FIDO’s security and privacy
requirements (Alliance, [n.d.]b). Google offers an educational environment,
where developers may build and test their first WebAuthn app (Google,
[n.d.]a). The FIDO Alliance provides a tool for ”conformance self‐validation
testing” prior to the certification process in order to assess the conformance
to the standards. (Alliance, [n.d.]a). An open version of the tool is
accessible in GitHub (Alliance, [n.d.]h). Google has published a CTAP2 testing
tool (Google, [n.d.]b) while Google’s Chrome browser allows developers to use
the ”WebAuthn Tab” for testing their infrastructure, leveraging of virtual
authenticators (Google, [n.d.]c). StrongKey provides material for step-to-step
integration in (Key, [n.d.]).The next step after the self-valitation is the
”interoperability testing” which verifies that different a FIDO client may
work with the FIDO server (Alliance, [n.d.]j). Open versions of the tools can
be found on GitHub (Alliance, [n.d.]g). If these self-validation and
interoperability testing are successfully completed, the certification
procedure takes place.

Undetected weaknesses though might still exist. Theoretical vulnerabilities in
UAF have been presented in (Hu and Zhang, 2016), (Panos et al., 2017) and
(Feng et al., 2021) but only (Li et al., 2020) managed to demonstrate a
feasible attack. Moreover, attacks related to hardware security and side
channel in U2F have been also described throughout the years. Transport
protocols supported by FIDO (i.e., BLE) may also present vulnerabilities. Risk
engines that use machine learning (ML) could be used in order to mitigate
threats as such, by producing a user profile.

TPM attacks are becoming more sophisticated, allowing information theft by
exploiting physical vulnerabilities. Microsoft proposes a novel, hardware root
of trust, implemented by the Pluton security processor which offers password-
less authentication. One of the major security problems solved by Pluton is
keeping the system firmware up to date across the entire PC ecosystem.
Vulnerabilities such as the one described in (Nemec et al., 2017), which
affect the security of RSA algorithm in TPM’s, would be resolved by the
Pluton. A technology such as the one proposed by Microsoft is pivotal for the
enablement of IoT security as well. (Hunt et al., [n.d.]), (Microsoft,
[n.d.]a). TEE is also gaining attention in recent years both for DevOps
Architects and attackers. In (Koutroumpouchos et al., 2021) a thoughtful
analysis of attacks thus measures to enhance TEE security are presented. The
authors in (Li et al., 2020) concluded that the FacetID and CallerID, used by
the UAF protocol to check the User Agent and the UAF Client application
respectively, cannot guarantee integrity during run-time, therefore malicious
attacks can be launched when TEE is employed as an authenticator. Proposed
solutions include an architecture similar to the TrustZone-based Integrity
Measurement Architecture (TIMA) to validate the integrity of the operating
system, third-party verification or application reinforcement and code
obfuscating technology and root detection mechanisms.

##  8\. Conclusion

FIDO protocol has already managed to engage a wide audience of stakeholders
and end-users nevertheless, more work needs to be done in order to be
established as the authentication solution that replaces the unsafe username
and password scheme. The level of penetration of FIDO2 and U2F mainly as
second authentication methods is evident, as indicated from the survey of the
USA and Asian markets. From our analysis we conclude that FIDO2 is easier for
developers to implement due to the browser and OS support and the amount of
public repositories. The integration of FIDO2 allowed developers to understand
the basis and familiarize with the FIDO protocols. At the same time though, we
support that the latest UAF v1.2 uses the previous UAF versions as well as the
lessons learned from FIDO2 to propose strong authentication even for devices
that cannot support browser, such as resource scarce next generation IoT
deployments in factories of the future and connected/autonomous vehicles.
Evidently, FIDO UAF is far from obsolete. On the contrary, this study surveyed
and showcased that FIDO protocols, which extend from FIDO UAF to FDO, can
satisfy the rapidly evolving user and system requirements, security
constraints and time-to-market demands of the different applications and
services of the emerging 6G and Industry 4.0/5.0 era.

## Acknowledgment

The project leading to this application has received funding from the European
Union’s Horizon 2020 research and innovation programme under grant agreement
No 101016608 (H2020-ICT-41-5GPPP-EVOLVED-5G), from the European Union’s
Horizon 2020 Stimulating innovation by means of cross-fertilisation of
knowledge program under the Grant Agreement No 824015 (H2020-MSCA-
RISE-2018-INCOGNITO), and the Greek state funded Operational Programme
Competitiveness, Entrepreneurship and Innovation 2014-2020 (EPAnEK) under the
Grant Agreements NetPHISH-$T1E\Delta K-05112$. We would like to thank Prof.
Xenakis, who with his capacity as coordinator of the H2020-DS-2014-1-ReCred
the first EU funded project aiming to implement FIDO, provided valuable
insight for the completion of this work.

## References

  * (1)
  * CAN ([n.d.]) [n.d.].  Can I use: WebAuthn.  https://caniuse.com/?search=webauthn Last accessed 5 March 2021.
  * USB ([n.d.]) [n.d.].  USB-Dongle Authentication.  https://www.dongleauth.info/ Last accessed 5 March 2021.
  * Alam et al. (2019) Aftab Alam, Katharina Krombholz, and Sven Bugiel. 2019\.  Poster: Let History Not Repeat Itself (This Time) – Tackling WebAuthn Developer Issues Early On. In _Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security_ (London, United Kingdom) _(CCS ’19)_. Association for Computing Machinery, New York, NY, USA, 2669–2671.  https://doi.org/10.1145/3319535.3363283
  * Alliance ([n.d.]a) FIDO Alliance. [n.d.]a.  Conformance Self‐Validation Testing.  https://fidoalliance.org/certification/functional-certification/conformance/ Last accessed 5 March 2021.
  * Alliance ([n.d.]b) FIDO Alliance. [n.d.]b.  FIDO Alliance White Paper: Considerations for Deploying FIDO Servers in the Enterprise.  https://media.fidoalliance.org/wp-content/uploads/2020/10/Considerations-for-Deploying-FIDO-Servers-in-the-Enterprise.pdf Last accessed 5 March 2021.
  * Alliance ([n.d.]c) FIDO Alliance. [n.d.]c.  FIDO CTAP spec.  https://fidoalliance.org/specs/fido-v2.1-rd-20210309/fido-client-to-authenticator-protocol-v2.1-rd-20210309 Last accessed 5 March 2021.
  * Alliance ([n.d.]d) FIDO Alliance. [n.d.]d.  FIDO U2F spec.  https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/ Last accessed 5 March 2021.
  * Alliance ([n.d.]e) FIDO Alliance. [n.d.]e.  FIDO UAF spec.  https://fidoalliance.org/specs/fido-uaf-v1.1-ps-20170202 Last accessed 5 March 2021.
  * Alliance ([n.d.]f) FIDO Alliance. [n.d.]f.  FIDO UAF spec.  https://fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fido-uaf--v1.2-ps-20201020.zip Last accessed 5 March 2021.
  * Alliance ([n.d.]g) FIDO Alliance. [n.d.]g.  Github FIDO2 Interoperability Testing Web App.  https://github.com/fido-alliance/fido2-interop-webapp Last accessed 5 March 2021.
  * Alliance ([n.d.]h) FIDO Alliance. [n.d.]h.  Github Repository for Certification Test Tools Resources.  https://github.com/fido-alliance/conformance-test-tools-resources Last accessed 5 March 2021.
  * Alliance ([n.d.]i) FIDO Alliance. [n.d.]i.  How FIDO standards meet psd2’s regulatory standards requirements on strong customer authentication.  https://media.fidoalliance.org/wp-content/uploads/2019/01/How_FIDO_Meets_the_RTS_Requirements_December2018.pdf Last accessed 5 March 2021.
  * Alliance ([n.d.]j) FIDO Alliance. [n.d.]j.  Interoperability Testing.  https://fidoalliance.org/certification/interoperability-testing/ Last accessed 5 March 2021.
  * Alliance ([n.d.]k) FIDO Alliance. [n.d.]k.  Metadata Service.  https://fidoalliance.org/metadata/ Last accessed 20 April 2021.
  * Alliance ([n.d.]l) FIDO Alliance. [n.d.]l.  National Health Service uses FIDO Authentication for Enhanced Login.  https://fidoalliance.org/national-health-service-uses-fido-authentication-for-enhanced-login Last accessed 20 April 2021.
  * Alliance ([n.d.]m) FIDO Alliance. [n.d.]m.  Privacy Principles.  https://media.fidoalliance.org/wp-content/uploads/2014/12/FIDO_Alliance_Whitepaper_Privacy_Principles.pdf Last accessed 5 March 2021.
  * Alliance ([n.d.]n) FIDO Alliance. [n.d.]n.  Recommended Account Recovery Practices for FIDO Relying Parties.  https://fidoalliance.org/recommended-account-recovery-practices/ Last accessed 5 March 2021.
  * Apple ([n.d.]a) Apple. [n.d.]a.  iOS & iPadOS 13.3 Release Notes.  https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-13_3-release-notes Last accessed 5 March 2021.
  * Apple ([n.d.]b) Apple. [n.d.]b.  Safari 14 Release Notes.  https://developer.apple.com/documentation/safari-release-notes/safari-14-release-notes Last accessed 5 March 2021.
  * Athanasios Vasileios Grammatopoulos and Xenakis (2021) Ilias Politis Athanasios Vasileios Grammatopoulos and Christos Xenakis. 2021\.  A web tool for analysing FIDO2/WebAuthn Requests and Responses. In _The 16th International Conference on Availability, Reliability and Security (ARES 2021), August 17-20, 2021, Vienna, Austria_.  https://doi.org/10.1145/3465481.3469209
  * Balfanz and Lundberg ([n.d.]) Czeskis Alexei Hodges Jeff Jones J.C. Jones Michael Kumar Akshay Liao Angelo Lindemann Rolf Balfanz, D. and Emil Lundberg. [n.d.].  _Web Authentication: An API for accessing Public Key Credentials Level 1_.  Technical Report.
  * Barbosa et al. ([n.d.]) Manuel Barbosa, Alexandra Boldyreva, Shan Chen, and Bogdan Warinschi. [n.d.].  Provable Security Analysis of FIDO2.  ([n. d.]).
  * Bianchi et al. (2018) Antonio Bianchi, Yanick Fratantonio, Aravind Machiry, Christopher Kruegel, Giovanni Vigna, Simon Pak Ho Chung, and Wenke Lee. 2018.  Broken Fingers: On the Usage of the Fingerprint API in Android. In _Proceedings of the Annual Network & Distributed System Security Symposium (NDSS)_.
  * Blog ([n.d.]a) Google Blog. [n.d.]a.  Announcing the Android Ready SE Alliance.  https://security.googleblog.com/2021/03/announcing-android-ready-se-alliance.html Last accessed 25 March 2021.
  * Blog ([n.d.]b) Webkit Project Blog. [n.d.]b.  Meet Face ID and Touch ID for the Web.  https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/ Last accessed 5 March 2021.
  * Broadcom (2020) Broadcom. 2020.  MAG and Samsung SDS Nexsign Integration.  https://techdocs.broadcom.com/us/en/ca-enterprise-software/layer7-api-management/mobile-api-gateway/4-1/solutions-and-integrations/mag-and-samsung-sds-nexsign-integration.html?src=contextnavpagetreemode Last accessed 18 January 2021.
  * Camenisch et al. (2017) Jan Camenisch, Liqun Chen, Manu Drijvers, Anja Lehmann, David Novick, and Rainer Urian. 2017\.  One TPM to Bind Them All: Fixing TPM 2.0 for Provably Secure Anonymous Attestation. In _2017 IEEE Symposium on Security and Privacy (SP)_. 901–920.  https://doi.org/10.1109/SP.2017.22
  * Chakraborty and Bugiel (2019) Dhiman Chakraborty and Sven Bugiel. 2019.  SimFIDO: FIDO2 User Authentication with SimTPM. In _Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security_ (London, United Kingdom) _(CCS ’19)_. Association for Computing Machinery, New York, NY, USA, 2569–2571.  https://doi.org/10.1145/3319535.3363258
  * Chang et al. (2017) Donghoon Chang, Sweta Mishra, Somitra Kumar Sanadhya, and Ajit Pratap Singh1. 2017.  On Making U2F Protocol Leakage-Resilient via Re-keying.  Cryptology ePrint Archive, Report 2017/721.  https://eprint.iacr.org/2017/721.
  * Chifor et al. (2018a) Bogdan-Cosmin Chifor, Ion Bica, Victor-Valeriu Patriciu, and Florin Pop. 2018a.  A security authorization scheme for smart home Internet of Things devices.  _Future Generation Computer Systems_ 86 (2018), 740–749.  https://doi.org/10.1016/j.future.2017.05.048
  * Chifor et al. (2018b) Bogdan-Cosmin Chifor, Sorin Teican, Mihai Togan, and George Gugulea. 2018b.  A Flexible Authorization Mechanism for Enterprise Networks Using Smart-Phone Devices. In _2018 International Conference on Communications (COMM)_. 437–440.  https://doi.org/10.1109/ICComm.2018.8484268
  * Ciolino et al. (2019) Stéphane Ciolino, Simon Parkin, and Paul Dunphy. 2019\.  Of Two Minds about Two-Factor: Understanding Everyday FIDO U2F Usability through Device Comparison and Experience Sampling. In _Fifteenth Symposium on Usable Privacy and Security (SOUPS 2019)_. USENIX Association, Santa Clara, CA.  https://www.usenix.org/conference/soups2019/presentation/ciolino
  * Citrix (2020) Citrix. 2020.  Introducing end-to-end password-less authentication using FIDO2.  https://www.citrix.com/blogs/2020/10/01/introducing-end-to-end-password-less-authentication-using-fido2/ Last accessed 5 January 2021.
  * Das et al. (2018) Sanchari Das, Andrew Dingman, and L. Jean Camp. 2018\.  Why Johnny Doesn’t Use Two Factor A Two-Phase Usability Study of the FIDO U2F Security Key. In _Financial Cryptography and Data Security_ , Sarah Meiklejohn and Kazue Sako (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 160–179.
  * Debian ([n.d.]) Debian. [n.d.].  Package: python3-fido2.  https://packages.debian.org/unstable/python3-fido2 Last accessed 20 April 2021.
  * Developers ([n.d.]a) Samsung Developers. [n.d.]a.  Tizen API: FIDO Client.  https://developer.tizen.org/dev-guide/csapi/api/Tizen.Account.FidoClient.html Last accessed 18 January 2021.
  * Developers ([n.d.]b) Samsung Developers. [n.d.]b.  Tizen Native API: FIDO Client.  https://docs.tizen.org/application/native/api/mobile/5.5/group__CAPI__FIDO__MODULE.html Last accessed 18 January 2021.
  * Developers ([n.d.]c) Samsung Developers. [n.d.]c.  TizenFX API References.  https://developer.samsung.com/smarttv/develop/api-references/tizenfx-api-references.html Last accessed 18 January 2021.
  * eBay (2016) eBay. 2016.  UAF - Universal Authentication Framework.  https://github.com/eBay/UAF Last accessed 18 January 2021.
  * ENISA (2020) ENISA. 2020.  Threat Landscape 2020 - Phishing.  https://www.enisa.europa.eu/publications/phishing Last accessed 5 January 2021.
  * Europol (2020) Europol. 2020.  The SIM Highjackers: How criminals are stealing millions by highjacking phone numbers.  https://www.europol.europa.eu/newsroom/news/sim-highjackers-how-criminals-are-stealing-millions-highjacking-phone-numbers Last accessed 5 January 2021.
  * Fan et al. (2017) Kai Fan, Hui Li, Wei Jiang, Chengsheng Xiao, and Yintang Yang. 2017.  U2F Based Secure Mutual Authentication Protocol for Mobile Payment. In _Proceedings of the ACM Turing 50th Celebration Conference - China_ (Shanghai, China) _(ACM TUR-C ’17)_. Association for Computing Machinery, New York, NY, USA, Article 27, 6 pages.  https://doi.org/10.1145/3063955.3063982
  * Farao et al. (2021) Aristeidis Farao, Eleni Veroni, Christoforos Ntantogian, and Christos Xenakis. 2021.  P4G2Go: A Privacy-Preserving Scheme for Roaming Energy Consumers of the Smart Grid-to-Go.  _Sensors_ 21, 8 (2021).  https://doi.org/10.3390/s21082686
  * Farke et al. (2020) Florian M. Farke, Lennart Lorenz, Theodor Schnitzler, Philipp Markert, and Markus Dürmuth. 2020\.  “You still use the password after all” – Exploring FIDO2 Security Keys in a Small Company. In _Sixteenth Symposium on Usable Privacy and Security (SOUPS 2020)_. USENIX Association, 19–35.  https://www.usenix.org/conference/soups2020/presentation/farke
  * Feng et al. (2021) Haonan Feng, Hui Li, Xuesong Pan, and Ziming Zhao. 2021\.  A Formal Analysis of the FIDO UAF Protocol. In _Proceedings of the Annual Network & Distributed System Security Symposium (NDSS)_.
  * FIDO Alliance (2019) FIDO Alliance. 2019\.  Android Now FIDO2 Certified, Accelerating Global Migration Beyond Passwords.  https://fidoalliance.org/android-now-fido2-certified-accelerating-global-migration-beyond-passwords/ Last accessed 18 January 2021.
  * FIDO Alliance (2020a) FIDO Alliance. 2020a.  Authentication Attitudes, Usage & FIDO Brand Research Report.  https://media.fidoalliance.org/wp-content/uploads/2020/05/FIDO-Consumer-Research-Report.pdf Last accessed 4 December 2020.
  * FIDO Alliance (2020b) FIDO Alliance. 2020b.  Certification Overview.  https://fidoalliance.org/certification/ Last accessed 5 January 2021.
  * FIDO Alliance (2020c) FIDO Alliance. 2020c.  FIDO Government Deployments and Recognitions .  https://fidoalliance.org/fido-government-deployments-and-recognitions/ Last accessed 21 December 2020.
  * FIDO Alliance (2020d) FIDO Alliance. 2020d.  FIDO Showcase.  https://fidoalliance.org/fido-certified-showcase/ Last accessed 21 December 2020.
  * Frymann et al. (2020) Nick Frymann, Daniel Gardham, Franziskus Kiefer, Emil Lundberg, Mark Manulis, and Dain Nilsson. 2020.  Asynchronous Remote Key Generation: An Analysis of Yubico’s Proposal for W3C WebAuthn. In _Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security_. 939–954.
  * Gaynor (2021) Alex Gaynor. 2021\.  Quantifying Memory Unsafety and Reactions to It. USENIX Association.
  * Geoffrey Cooper ([n.d.]) et. al. Geoffrey Cooper. [n.d.].  FIDO Device Onboard Specification.  https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-v1.0-PS-20210323 Proposed Standard, March 23, 2021.
  * Ghorbani Lyastani et al. (2020) S. Ghorbani Lyastani, M. Schilling, M. Neumayr, M. Backes, and S. Bugiel. 2020.  Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless Authentication. In _2020 IEEE Symposium on Security and Privacy (SP)_. 268–285.  https://doi.org/10.1109/SP40000.2020.00047
  * Google ([n.d.]a) Google. [n.d.]a.  Build your first WebAuthn app.  https://codelabs.developers.google.com/codelabs/webauthn-reauth#0 Last accessed 5 March 2021.
  * Google ([n.d.]b) Google. [n.d.]b.  Github CTAP2 test tool.  https://github.com/google/CTAP2-test-tool Last accessed 5 March 2021.
  * Google ([n.d.]c) Google. [n.d.]c.  How we built the Chrome DevTools WebAuthn tab.  https://developer.chrome.com/blog/webauthn-tab/ Last accessed 5 March 2021.
  * Google (2017) Google. 2017.  Google APIs for Android: FIDO .  https://developers.google.com/android/reference/packages#fido Last accessed 21 December 2020.
  * Grimes (2020) Roger A. Grimes. 2020\.  _Hacking Multifactor Authentication_.  Wiley, Hoboken, New Jersey.
  * Guirat and Halpin (2018) Iness Ben Guirat and Harry Halpin. 2018.  Formal Verification of the W3C Web Authentication Protocol. In _Proceedings of the 5th Annual Symposium and Bootcamp on Hot Topics in the Science of Security_ (Raleigh, North Carolina) _(HoTSoS ’18)_. Association for Computing Machinery, New York, NY, USA, Article 6, 10 pages.  https://doi.org/10.1145/3190619.3190640
  * Guo et al. (2020) Chengqian Guo, Quanwei Cai, Qiongxiao Wang, and Jingqiang Lin. 2020.  Extending Registration and Authentication Processes of FIDO2 External Authenticator with QR Codes. In _2020 IEEE 19th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom)_. 518–529.  https://doi.org/10.1109/TrustCom50675.2020.00076
  * Hat ([n.d.]) Red Hat. [n.d.].  Authentication using FIDO Protocol UAF and U2F.  https://access.redhat.com/solutions/3076761 Last accessed 5 March 2021.
  * Hu and Zhang (2016) Kexin Hu and Zhenfeng Zhang. 2016.  Security analysis of an attractive online authentication standard: FIDO UAF protocol.  _China Communications_ 13, 12 (2016), 189–198.
  * Hunt et al. ([n.d.]) Galen Hunt, George Letey, and Edmund B. Nightingale. [n.d.].  The Seven Properties of Highly Secured Devices.  https://www.microsoft.com/en-us/research/uploads/prod/2020/11/Seven-Properties-of-Highly-Secured-Devices-2nd-Edition-R1.pdf Last accessed 5 March 2021.
  * Jones et al. (2021) Michael Jones, Jeff Hodges, Emil Lundberg, J.C. Jones, and Akshay Kumar. 2021.  _Web Authentication: An API for accessing Public Key Credentials - Level 2_.  W3C Recommendation. W3C.  https://www.w3.org/TR/2021/REC-webauthn-2-20210408/.
  * Key ([n.d.]) Strong Key. [n.d.].  Crypto-Based Authentication.  https://encryptedweb.org/authentication/ Last accessed 5 March 2021.
  * Kim et al. (2020) Hyunjin Kim, Dongseop Lee, and Jaecheol Ryou. 2020\.  User Authentication Method using FIDO based Password Management for Smart Energy Environment. In _2020 International Conference on Data Mining Workshops (ICDMW)_. 707–710.  https://doi.org/10.1109/ICDMW51313.2020.00100
  * Kitsaki et al. (2018) Theodoula-Ioanna Kitsaki, Anna Angelogianni, Christoforos Ntantogian, and Christos Xenakis. 2018\.  A Forensic Investigation of Android Mobile Applications. In _Proceedings of the 22nd Pan-Hellenic Conference on Informatics_ (Athens, Greece) _(PCI ’18)_. Association for Computing Machinery, New York, NY, USA, 58–63.  https://doi.org/10.1145/3291533.3291573
  * Klieme et al. (2020) Eric Klieme, Jonathan Wilke, Niklas van Dornick, and Christoph Meinel. 2020.  FIDOnuous: A FIDO2/WebAuthn Extension to Support Continuous Web Authentication. In _2020 IEEE 19th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom)_. 1857–1867.  https://doi.org/10.1109/TrustCom50675.2020.00254
  * Koutroumpouchos et al. (2021) Nikolaos Koutroumpouchos, Christoforos Ntantogian, and Christos Xenakis. 2021.  Building Trust for Smart Connected Devices: The Challenges and Pitfalls of TrustZone.  _Sensors_ 21, 2 (2021).  https://www.mdpi.com/1424-8220/21/2/520
  * Laborde et al. (2020) Romain Laborde, Arnaud Oglaza, Samer Wazan, François Barrere, Abdelmalek Benzekri, David W. Chadwick, and Rémi Venant. 2020.  A User-Centric Identity Management Framework based on the W3C Verifiable Credentials and the FIDO Universal Authentication Framework. In _2020 IEEE 17th Annual Consumer Communications Networking Conference (CCNC)_. 1–8.  https://doi.org/10.1109/CCNC46108.2020.9045440
  * Laborde et al. (2020) R. Laborde, A. Oglaza, S. Wazan, F. Barrère, A. Benzekri, D. W. Chadwick, and R. Venant. 2020.  Know Your Customer: Opening a new bank account online using UAAF. In _2020 IEEE 17th Annual Consumer Communications Networking Conference (CCNC)_. 1–2.  https://doi.org/10.1109/CCNC46108.2020.9045148
  * Li et al. (2020) Hui Li, Xuesong Pan, Xinluo Wang, Haonan Feng, and Chengjie Shi. 2020.  Authenticator Rebinding Attack of the UAF Protocol on Mobile Devices.  _Wireless Communications and Mobile Computing_ 2020 (2020).
  * Luo et al. (2021) H. Luo, C. Wang, H. Luo, F. Zhang, F. Lin, and G. Xu. 2021.  G2F: A Secure User Authentication for Rapid Smart Home IoT Management.  _IEEE Internet of Things Journal_ (2021), 1–1.  https://doi.org/10.1109/JIOT.2021.3050710
  * Menegazzo Verzeletti et al. (2018) G. Menegazzo Verzeletti, E. Ribeiro de Mello, and M. Wangham. 2018.  A Mobile Identity Management System to Enhance the Brazilian Electronic Government.  _IEEE Latin America Transactions_ 16, 11 (2018), 2790–2797.  https://doi.org/10.1109/TLA.2018.8795121
  * Microsoft ([n.d.]a) Microsoft. [n.d.]a.  Meet the Microsoft Pluton processor – The security chip designed for the future of Windows PCs.  https://www.microsoft.com/security/blog/2020/11/17/meet-the-microsoft-pluton-processor-the-security-chip-designed-for-the-future-of-windows-pcs/ Last accessed 5 March 2021.
  * Microsoft ([n.d.]b) Microsoft. [n.d.]b.  Support passwordless authentication with FIDO2 keys in apps you develop.  https://docs.microsoft.com/en-us/azure/active-directory/develop/support-fido2-authentication Last accessed 5 March 2021.
  * Microsoft (2020) Microsoft. 2020\.  How it works: Azure AD Multi-Factor Authentication.  https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks Last accessed 5 January 2021.
  * Nemec et al. (2017) Matus Nemec, Marek Sys, Petr Svenda, Dusan Klinec, and Vashek Matyas. 2017.  The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli. In _24th ACM Conference on Computer and Communications Security (CCS’2017)_. ACM, 1631–1648.
  * Okta ([n.d.]) Okta. [n.d.].  Okta FastPass.  https://www.okta.com/fastpass/ Last accessed 5 March 2021.
  * Oracle ([n.d.]) Oracle. [n.d.].  Packages Released on Oracle Linux Yum Server.  https://yum.oracle.com/whatsnew.html Last accessed 20 April 2021.
  * Othman and Callahan (2018) A. Othman and J. Callahan. 2018.  The Horcrux Protocol: A Method for Decentralized Biometric-based Self-sovereign Identity. In _2018 International Joint Conference on Neural Networks (IJCNN)_. 1–7.  https://doi.org/10.1109/IJCNN.2018.8489316
  * OWASP ([n.d.]) OWASP. [n.d.].  Secure Coding Practices-Quick Reference Guide.  https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content Last accessed 5 March 2021.
  * Panos et al. (2017) Christoforos Panos, Stefanos Malliaros, Christoforos Ntantogian, Angeliki Panou, and Christos Xenakis. 2017.  A Security Evaluation of FIDO’s UAF Protocol in Mobile and Embedded Devices. In _Digital Communication. Towards a Smart and Secure Future Internet_ , Alessandro Piva, Ilenia Tinnirello, and Simone Morosi (Eds.). Springer International Publishing, Cham, 127–142.
  * Papadamou et al. (2020) Kostantinos Papadamou, Savvas Zannettou, Bogdan Chifor, Sorin Teican, George Gugulea, Alberto Caponi, Annamaria Recupero, Claudio Pisa, Giuseppe Bianchi, Steven Gevers, Christos Xenakis, and Michael Sirivianos. 2020.  Killing the Password and Preserving Privacy With Device-Centric and Attribute-Based Authentication.  _IEEE Transactions on Information Forensics and Security_ 15 (2020), 2183–2193.  https://doi.org/10.1109/TIFS.2019.2958763
  * pkgs.prg ([n.d.]) pkgs.prg. [n.d.].  Python-fido2 Download for Linux (eopkg, rpm, xz, zst).  https://pkgs.org/download/python-fido2 Last accessed 20 April 2021.
  * Politis et al. (2021) Ilias Politis, Christos Xenakis, Adarbad Master, and John Polley. 2021.  On an innovative architecture for digital immunity passports and vaccination certificates.  (03 2021).
  * Reese et al. (2019) Ken Reese, Trevor Smith, Jonathan Dutson, Jonathan Armknecht, Jacob Cameron, and Kent Seamons. 2019\.  A Usability Study of Five Two-Factor Authentication Methods. In _Fifteenth Symposium on Usable Privacy and Security (SOUPS 2019)_. USENIX Association, Santa Clara, CA, 357–370.  https://www.usenix.org/conference/soups2019/presentation/reese
  * Reimair et al. (2016) Florian Reimair, Christian Kollmann, and Alexander Marsalek. 2016\.  Emulating U2F authenticator devices. In _2016 IEEE Conference on Communications and Network Security (CNS)_. 543–551.  https://doi.org/10.1109/CNS.2016.7860546
  * Samsung ([n.d.]) Samsung. [n.d.].  Using Samsung Pass on my Galaxy device.  https://www.samsung.com/au/support/mobile-devices/using-samsung-pass/ Last accessed 20 April 2021.
  * Security ([n.d.]) IBM Security. [n.d.].  Extending Keycloak SSO Capabilities with IBM Security Verify.  https://community.ibm.com/community/user/security/blogs/jason-choi1/2020/06/10/extending-keycloak-sso-capabilities-with-ibm-secur Last accessed 5 March 2021.
  * Siadati et al. (2017) Hossein Siadati, Toan Nguyen, Payas Gupta, Markus Jakobsson, and Nasir Memon. 2017.  Mind your SMSes: Mitigating social engineering in second factor authentication.  _Computers & Security_ 65 (2017), 14–28.  https://doi.org/10.1016/j.cose.2016.09.009
  * Snyder ([n.d.]) Joel Snyder. [n.d.].  Using biometrics for authentication in Android.  https://www.samsungknox.com/en/blog/using-biometrics-for-authentication-in-android Last accessed 20 April 2021.
  * StatCounter (2020) StatCounter. 2020\.  Mobile Operating System Market Share Worldwide.  https://gs.statcounter.com/os-market-share/mobile/worldwide Last accessed 18 January 2021.
  * The FIDO Alliance ([n.d.]) The FIDO Alliance. [n.d.].  Support for FIDO2: WebAuthn and CTAP.  https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/ Last accessed 5 March 2021.
  * The Guardian ([n.d.]) The Guardian. [n.d.].  What you need to know about the biggest hack of the US government in years.  https://www.theguardian.com/technology/2020/dec/15/orion-hack-solar-winds-explained-us-treasury-commerce-department Last accessed 5 March 2021.
  * Togan et al. (2017) Mihai Togan, Bogdan-Cosmin Chifor, Ionuţ Florea, and George Gugulea. 2017.  A smart-phone based privacy-preserving security framework for IoT devices. In _2017 9th International Conference on Electronics, Computers and Artificial Intelligence (ECAI)_. 1–7.  https://doi.org/10.1109/ECAI.2017.8166453
  * Ulqinaku et al. (2020) Enis Ulqinaku, Hala Assal, AbdelRahman Abdou, Sonia Chiasson, and Srdjan Čapkun. 2020\.  Is Real-time Phishing Eliminated with FIDO? Social Engineering Downgrade Attacks against FIDO Protocols.  Cryptology ePrint Archive, Report 2020/1298.  https://eprint.iacr.org/2020/1298.
  * Votipka et al. (2020) Daniel Votipka, Kelsey R. Fulton, James Parker, Matthew Hou, Michelle L. Mazurek, and Michael Hicks. 2020.  Understanding security mistakes developers make: Qualitative analysis from Build It, Break It, Fix It. In _29th USENIX Security Symposium (USENIX Security 20)_. USENIX Association, 109–126.  https://www.usenix.org/conference/usenixsecurity20/presentation/votipka-understanding
  * Wagner et al. (2021) Paul Wagner, Kris Heid, and Jens Heider. 2021.  Remote WebAuthn: FIDO2 Authentication for Less Accessible Devices. In _7th International Conference on Information Systems Security and Privacy (ICISSP 2021)_. 368–375.  https://doi.org/10.5220/0010192703680375
  * Wiki ([n.d.]a) Arch Linux Wiki. [n.d.]a.  PAM.  https://wiki.archlinux.org/index.php/PAM Last accessed 5 March 2021.
  * Wiki ([n.d.]b) Arch Linux Wiki. [n.d.]b.  Universal 2nd Factor.  https://wiki.archlinux.org/index.php/Universal_2nd_Factor Last accessed 5 March 2021.
  * Yahoo Finance (2020) Yahoo Finance. 2020\.  Another AT&T SIM Swapping Hack Targets Trio of Crypto Execs.  https://finance.yahoo.com/news/another-t-sim-swapping-hack-082039662.html? Last accessed 5 January 2021.
  * Yubico ([n.d.]a) Yubico. [n.d.]a.  WebAuthn Compatibility.  https://developers.yubico.com/WebAuthn/WebAuthn_Browser_Support/ Last accessed 5 March 2021.
  * Yubico ([n.d.]b) Yubico. [n.d.]b.  Works with YubiKey catalog.  https://www.yubico.com/gr/works-with-yubikey/catalog/#protocol=webauthn&usecase=all&key=all Last accessed 5 March 2021.
  * Zhang et al. (2018) Yongxian Zhang, Xinluo Wang, Ziming Zhao, and Hui Li. 2018\.  Secure display for FIDO transaction confirmation. In _CODASPY 2018 - Proceedings of the 8th ACM Conference on Data and Application Security and Privacy_ _(CODASPY 2018 - Proceedings of the 8th ACM Conference on Data and Application Security and Privacy)_. Association for Computing Machinery, Inc, 155–157.  https://doi.org/10.1145/3176258.3176946
  * Zhen et al. (2019) Ping Zhen, Dong Wang, and Chao Ji. 2019.  Unified Identity Authentication Scheme Based on UAF Protocol. In _2019 IEEE 19th International Conference on Communication Technology (ICCT)_. 415–419.  https://doi.org/10.1109/ICCT46805.2019.8947083