0% found this document useful (0 votes)
69 views

Future Generation Computer Systems: Peng Xu Ruijie Sun Wei Wang Tianyang Chen Yubo Zheng Hai Jin

Uploaded by

ardika
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
69 views

Future Generation Computer Systems: Peng Xu Ruijie Sun Wei Wang Tianyang Chen Yubo Zheng Hai Jin

Uploaded by

ardika
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

Future Generation Computer Systems 125 (2021) 32–40

Contents lists available at ScienceDirect

Future Generation Computer Systems


journal homepage: www.elsevier.com/locate/fgcs

SDD: A trusted display of FIDO2 transaction confirmation without


trusted execution environment

Peng Xu a , Ruijie Sun a , Wei Wang b , , Tianyang Chen a , Yubo Zheng a , Hai Jin a
a
National Engineering Research Center for Big Data Technology and System, Services Computing Technology and System Lab, and Hubei Engineering
Research Center on Big Data Security, School of Cyber Science and Engineering, Huazhong University of Science and Technology,
Wuhan, Hubei, 430074, China
b
Cyber–Physical–Social Systems Lab, School of Computer Science and Technology, Huazhong University of Science and Technology,
Wuhan, Hubei, 430074, China

article info a b s t r a c t

Article history: The FIDO2 protocol allows users to perform online authentication by setting a public key and avoids
Received 15 December 2020 the shortcomings of the traditional password authentication mechanism in terms of security. During
Received in revised form 5 May 2021 transaction confirmation with the FIDO2 protocol, users must confirm the transaction message and
Accepted 19 June 2021
then sign this message using a cryptographic signature scheme. However, it is a challenge to show
Available online 25 June 2021
that transaction messages are correct or trusted in practice. No available authenticator that supports
Keywords: the FIDO2 protocol uses trusted display hardware to guarantee the correctness of transaction messages.
FIDO2 protocol This paper proposes a trusted display of transaction messages by developing a lightweight and trusted
Authentication base on hardware without a trusted execution environment (TEE). The proposed trusted display is
Transaction confirmation easily applied in the FIDO2 protocol and resists four types of well-known attacks, such as malicious
Secure display process tampering with display and occupying an authenticator. The experimental results indicate that
the improved FIDO2 protocol slightly increases the processing overhead compared to the traditional
protocol.
© 2021 Elsevier B.V. All rights reserved.

1. Introduction services, and each password reset operation costs a company


approximately $70 on average.
User authentication is a critical component of ensuring ap- The FIDO Alliance aims to ameliorate the defects of traditional
plication security in online services. Password authentication is password authentication. The early members of the alliance in-
currently the most popular method of identity authentication. clude some famous companies, such as PayPal, Lenovo, Google,
However, this method may exhibit several weaknesses. For ex- Yubico, and Microsoft. The FIDO Alliance released the FIDO pro-
ample, a compromised server could leak users’ passwords. An tocol in 2014 [2–4] and the FIDO2 protocol in 2019 [5]. The World
Wide Web Consortium and the FIDO Alliance jointly announced
internet eavesdropper could intercept the transferred users’ pass-
the WebAuth specification [6], a core component of the FIDO2
words. It is also easy for an attacker to guess weak passwords [1],
protocol, as an official web standard on 4 March 2019. Many
especially when users set their personal information as pass-
popular operating systems and browsers support this standard.
words. Thus, a user must select long and complex passwords,
Thus, the FIDO2 protocol has become the world’s most extensive
which may be difficult to remember for various applications.
standards-based identity authentication system.
On average, a user has twenty-six accounts and correspond- The FIDO2 protocol is an online authentication protocol, where
ing passwords. These passwords must be periodically updated a user has a credential in their hardware called an authenti-
to guarantee high security. It is thus challenging for users to cator that authenticates their identity to a server, as shown in
use password authentication while ensuring high security. Every Fig. 1. Online services can use the FIDO2 protocol to achieve
year, enterprises and individuals incur considerable losses by more secure user identity authentication. Industrial equipment
resetting passwords. The Gardner group has shown that approxi- is also increasingly requiring improved user authentication per-
mately 30%–50% of IT consultation calls pertain to password reset formance. Compared to traditional password authentication, this
passwordless authentication method is better suited for industrial
∗ Corresponding author. Internet of Things (IoT) applications. Togan et al. [7] used the
E-mail addresses: [email protected] (P. Xu), [email protected] FIDO UAF protocol as an identity authentication scheme for IoT
(R. Sun), [email protected] (W. Wang), [email protected] devices to improve the security of authentication. The FIDO2 pro-
(T. Chen), [email protected] (Y. Zheng), [email protected] (H. Jin). tocol consists of two modules: local user verification and online

https://doi.org/10.1016/j.future.2021.06.034
0167-739X/© 2021 Elsevier B.V. All rights reserved.
P. Xu, R. Sun, W. Wang et al. Future Generation Computer Systems 125 (2021) 32–40

registration and transaction confirmation. In Section 4, we de-


scribe the attacks that aim to create a malicious display. We
then introduce the proposed solution and analyze its security and
performance in Section 5 and Section 6, respectively. Section 7
summarizes the conclusion.
Fig. 1. FIDO2 protocol authentication overview.
2. Related work

authentication. Both modules are executed by an authenticator, Passwordless authentication is an active research area due to
the shortcomings of traditional password-based authentication in
which is usually specialized hardware such as a USB key. An
usability and security. Loxin [11] offers a passwordless authenti-
authenticator runs the first module to verify whether a local
cation solution that uses a mobile application and a Loxin central
login user is allowed by comparing his login information with
server. The Loxin central server stores the registration informa-
preassigned biological details or password. If allowed, the au-
tion of all the users. However, the compromise of the Loxin server
thenticator runs the second module to authenticate the user to
would damage the security of authentication. Moreover, relying
a remote server using a standard public key signature scheme.
parties can identify a user in multiple sessions based on a specific
Thus, the FIDO2 protocol avoids the need for users to remember
public key, which violates the unlinkability of the authentication.
many passwords. Only one password is needed and only for local Pico is another passwordless authentication scheme proposed
authentication, not online authentication. In other words, neither by Stajano based on dedicated hardware tokens [12]. Users are
eavesdroppers nor compromised servers can obtain any password allowed to manage their own credentials with various devices
from communications. This signature scheme is also a much more instead of relying on third parties. Pico is similar to the FIDO2
secure technique than password authentication because no one protocol, using the challenge–response protocol and public-key
can impersonate a user’s signature without the user’s private key. cryptosystem for authentication. However, this authentication
However, the FIDO2 protocol also has a critical limitation in scheme has not been widely used due to the absence of standards
guaranteeing the correctness of transaction information. When and implementation.
the relying party (RP) requires a user to confirm a transaction Bui et al. [13] proposed and implemented an attack on the
such as a funds transfer, the FIDO2 protocol must show the FIDO U2F protocol using a malicious browser to occupy the au-
user’s transaction information when performing transaction con- thenticator. The malicious browser sends requests to the au-
firmation [6]. Suppose that the authenticator does not have a thenticator at a high rate. When a regular request arrived, the
trusted display module. The application must display the trans- malicious browser has a high chance of interrupting the regular
action information directly on the screen of the user’s device. request and replacing it with a malicious request. The user cannot
Thus, attackers may tamper with transaction information before detect this attack due to their inability to display the request’s
displaying it. source.
Currently, the primary method to implement a trusted dis- Zhang et al. [8] proposed an attack to tamper with the dis-
play relies on TEE. However, this method only applies to mobile played content. This attack results in the user observing a false
devices. Most mobile devices use ARM chips, and the TrustZone transaction message, which violates the ‘‘What You See Is What
technology of ARM chips can ensure trusted computing for users. You Sign’’ requirement. Zhang et al. used the TrustZone technol-
Mobile devices can thus use TrustZone technology with the FIDO ogy of ARM chips to guarantee the integrity of the transaction
protocol to guarantee that the transaction information shown on content. This mechanism is only suitable for mobile devices be-
the screen is complete [8]. However, most personal computers cause most personal computers do not have a trusted execution
use Intel chips. The Intel group introduced SGX, a TEE technique environment. Also, applying the TEE technology in the FIDO2
of Intel, to its chips (e.g., its sixth-generation core microprocessor) protocol is difficult: both TrustZone and SGX technologies require
in 2015. Thus, a considerable number of personal computers in developers to place the part requiring protection into the secure
use cannot apply the TEE technique. world or enclave [14,15]. Thus, a developer’s proficiency will
In devices that do not have a TEE, some hardware can enhance affect the correctness of the code. Recoding existing applications
is also a massive burden in practice.
content display security. The FPGA hardware located between
In addition to security risks, FIDO2 protocol also has some
the processor and the screen can create an overlay to guarantee
shortcomings in usability. Lyastani et al. [16] conducted a large-
that the untrusted processors cannot tamper with the display
scale experimental study on the usability of FIDO2 protocol.
content [9]. Modern graphics processing units can also achieve
When the authenticator device gets lost, there is no convenient
trusted display on untrusted platforms with the separation ker-
way for the user to revoke the credentials stored in it. Under
nel [10]. However, these methods rely on additional hardware
this circumstance, users worry that they would no longer be able
and are not suitable for a wide range of devices.
to access their accounts. Furthermore, some embedded devices
In this study, we summarize and investigate four kinds of cannot interact with the authenticator via USB, Bluetooth, or NFC
attacks that aim to compromise user displays of the FIDO2 pro- interface, which limits the usability of the FIDO2 protocol. There
tocol: mal-process occupying attack, cross-site scripting (XSS) are not yet suitable resolutions for these concerns in the FIDO2
attack for tampering with display content, misauthentication at- protocol.
tack (namely, XSS attack for sending malicious authentication Researches by Das et al. [17] showed that the ambiguous
requests), and implicit authentication attack. To resist these four status prompt from the authenticator might confuse users. The
kinds of attacks, we append the transaction message’s signature current authenticators mainly prompt users to perform regis-
in the authentication request and implement a trust strategy be- tration and authentication operations by flashing signal lights.
tween the authenticator and a verification process residing on the However, the signal light will also flash at insertion or other
user’s device. Finally, this study analyzes our solution’s security unrelated points. The user cannot determine when to press the
and experimentally shows that our solution slightly increases button, which may lead to incorrect operations. Requiring user’s
communication and computation costs. explicit consent before establishing a relationship with a new
This paper organizes its content into the following sections. relying party is one of the FIDO2 protocol security goals [18].
Section 2 describes the related work. Section 3 introduces the Currently, certified authenticators cannot meet this requirement
main details of the FIDO2 protocol, especially the details of its due to the lack of status display measures.
33
P. Xu, R. Sun, W. Wang et al. Future Generation Computer Systems 125 (2021) 32–40

Fig. 2. Financial website registration workflow. Fig. 3. Financial website authentication workflow.

3. FIDO2 transaction confirmation workflow (2) The financial website server receives the request and gener-
ates a transaction message based on the request, such as ‘‘A
We consider a financial website as an example to introduce transfers $100 to B’’.
the registration and authentication workflows of the FIDO2 pro- (3) The FIDO2 module in the website server constructs an au-
tocol. Suppose that a user would like to register an account on a thentication request. The request contains randomly gener-
financial website. Fig. 2 shows the registration workflow of the ated challenge data and the transaction message.
FIDO2 protocol. The steps are as follows. (4) The financial website server sends the authentication request
to the user’s browser.
(1) The user visits a financial website through a user agent, such (5) The browser forwards the authentication request to the au-
as his browser and submits a registration form to the website thenticator. Because the authenticator cannot display the
after filling in his personal information. contained transaction message, the browser displays the
(2) The financial website server (e.g., the RP server, including transaction message to the user instead. After confirming
a FIDO2 module) receives the user’s registration form and the transaction message shown on the browser, the user
verifies the legality of the submitted personal information. performs an authorization gesture.
(3) The FIDO2 module constructs a registration request, includ- (6) After the user is authenticated, the authenticator unlocks
ing the user’s username and randomly generated challenge the user’s private key and signs the challenge data, which
data. is contained in the authentication request, with this pri-
(4) The financial website server sends the registration request to vate key. The authenticator then constructs an authentication
the user’s browser. response, including the signature just generated.
(5) The browser forwards the registration request to the authen- (7) The authenticator sends the authentication response to the
ticator. The authenticator processes the registration request browser. Then, the browser forwards the authentication re-
after the user performs an authorization gesture (e.g., enter- sponse to the financial website server.
ing a valid PIN code). (8) After receiving the authentication response, the financial
(6) The authenticator generates a new pair of public and pri- website server looks up the user’s public key according to the
vate keys, and uses the private key to sign the registration user’s username and verifies the signature in the response. If
request’s challenge data. The authenticator then constructs a valid, the financial website server executes the transaction
registration response, including the newly generated public and sends the final result to the user’s browser.
key and the signature of the challenge data. According to the FIDO2 protocol, the authenticator must have
(7) The authenticator sends a registration response to the a trusted display module to show the user the received trans-
browser. Then, the browser forwards the registration re- action message before signing the challenge data in the above
sponse to the financial website server. authentication workflow [6]. In this case, the authentication can
(8) The FIDO2 module in the website server verifies the signa- confirm that the displayed transaction message is real. However,
ture’s correctness with the user’s public key in the response. this assumption cannot always be guaranteed. The FIDO Alliance
If correct, the module then generates a new user record and has recently awarded the FIDO2 authenticator certification to
stores the user’s public key. Finally, the financial website twenty-three types of roaming authenticators and eleven types of
server sends the registration result back to the user’s browser embedded authenticators as of September 2020. However, none
to notify the user that the registration is successful. of these authenticators have a trusted display module. Currently,
all web applications that use the FIDO2 protocol directly call
Now, suppose that the user wants to transfer money to an- the browser display interface to display the transaction message,
other person on the financial website. Fig. 3 shows the corre- such as the pop-up window or changing HTML elements. Such a
sponding authentication workflow of the FIDO2 protocol. display pattern is vulnerable to attackers.

(1) The user accesses the financial website through a browser. 4. Four kinds of attacks to tamper the FIDO2 display
When he decides to transfer his money to another account,
he sends a transaction confirmation request to the financial Due to the lack of the trusted display module in existing
website server. authenticators, some attacks on a web page may threaten the
34
P. Xu, R. Sun, W. Wang et al. Future Generation Computer Systems 125 (2021) 32–40

Fig. 4. Mal-Process occupying attack. Fig. 5. Tampering display attack.

security of transaction confirmation and other display-related


processes of the FIDO2 protocol. We summarize four types of
attacks related to display below.

4.1. Mal-process occupying attacks

A mal-process occupying attack occurs when a malicious pro-


cess residing on the user’s device monitors the call to the au-
thenticator and attempts to log into the user’s online service. The
attack workflow is shown in Fig. 4. We use red in the figure to
highlight key steps. When the user performs authentication of
an online service, the browser intends to send an authentication
request to the authenticator, as in step 5. However, a malicious
process can find and interrupt the browser’s action, and imme-
diately replace the legal request by sending a malicious request
to the authenticator. Due to the lack of a secure path to inform Fig. 6. Misauthentication attack.
the user regarding which request the authenticator currently
receives, the user has a high probability of verifying the malicious
authentication request. Also, the malicious process can launch on a financial website. The attack workflow is shown in Fig. 5.
subsequent attacks after it logs into the user’s online service. When the user clicks on a phishing link, the financial website
The Windows operating system allows non-interactive processes server sends a malicious script and regular data back to the
to access the USB device without the user’s authorization, such user’s browser, as in step 4. The user mistakenly believes that the
as a USB authenticator; this is a critical factor that allows the malicious script comes from a trusted server. After the HTML page
above attack to occur. The Windows operating system currently is rendered, the malicious script replaces the transaction message
occupies 77% to 87.8% of the global market share, and this type with content that can be easily trusted, such as logging in again,
of attack has a significant effect on the FIDO2 protocol. as in step 5.
According to the above attack model, we used a Python script Because there is no secure path on the user’s device, the
to monitor calls to a USB authenticator on a computer. The user’s device cannot verify the transaction message’s integrity
experiment shows that before the user performs an authorization or display the current transaction confirmation message to the
gesture, this script has a 100% chance of interrupting the previous user in a unified way. The browser only displays the transaction
call’s execution and replacing it with a malicious request. The message through the display interface, such as by changing HTML
high success probability is achieved because the script sends elements or pop-up windows. Because every online service im-
requests much faster than the user performs their authorization plements the display in different ways, it is difficult for the user
gesture. We implemented the attack using Python scripts, but XSS to discover the attack according to the display mode. Thus, the
attacks can also achieve the same effect. Bui et al. [13] proposed a user has a high possibility of performing authentication for an
similar attack method. The malicious process sent authentication unexpected transaction. Currently, XSS vulnerabilities remain the
requests to the U2F authenticator at a high rate and applied the principal vulnerabilities of financial websites and are prevalent in
attack to a U2F authenticator. The solution proposed in this study social networks [19]. Such attacks cause severe loss of property
can resist this type of attack. and privacy to users. We implemented this attack by constructing
an XSS attack.
4.2. Tampering display attacks
4.3. Misauthentication attacks
A tampering display attack occurs when an attacker shows
a false transaction message to the user through an XSS script, A misauthentication attack occurs when an attacker deceives
causing the user to perform authentication on the request of the user, causing the user to perform authentication on the target
an unexpected transaction. For example, consider such an attack RP website through an Ajax request. The attack workflow is
35
P. Xu, R. Sun, W. Wang et al. Future Generation Computer Systems 125 (2021) 32–40

(3) Suppose that an authenticator does not need the user’s ges-
ture to start authentication. A malicious process can call the
authenticator without interacting with the user.

5. Proposed solution without both TEE and particular hard-


ware

The critical factor in allowing the above four types of attacks


to occur is that the user’s device does not have a trusted path:
the user agent cannot display the correct transaction message to
the user. Constructing a trusted path on the users’ devices can
verify that no one tampers with the transaction message during
transmission and display, and a trusted path can also provide
users with a unified display.
To verify a transaction message’s integrity, we add a signature
from the transaction message to the corresponding authentica-
Fig. 7. Implicit authentication attack. tion request. Specifically, to construct the authentication request,
the RP server uses its private key to sign the transaction message
and adds the signature into the authentication request. The RP
server then sends the authentication request to the expected
user agent. The corresponding user’s device must then verify
the transaction message’s integrity to ensure that the transaction
message has not been tampered with during transmission.
To provide a trusted path with a lightweight trust base, we
run a new local process on the user’s device called Secure Display
Daemon (SDD), which provides a JS library for the user’s other
processes to call. All of these processes must access the authen-
ticator through this unique process. We will describe how to
guarantee that this process occurs in the next section. As a trusted
path, SDD is responsible for verifying a transaction message’s
integrity and providing a unified display. Fig. 8 shows the location
of the SDD. We describe the details of the improved scheme next.
Compared to the previous solutions [8], our solution does
not require the users’ devices to have a trusted execution en-
vironment or some particular hardware, such as an FPGA and
Fig. 8. Location of secure display Daemon.
graphics processing unit. Thus, the proposed solution offers more
extensive application prospects. Moreover, there is no need to re-
program existing applications when applying the proposed solu-
shown in Fig. 6. Due to the XSS vulnerabilities of websites, the tion, which successfully avoids increasing burden on application
attacker injects a malicious XSS script into the user’s browser. developers.
The malicious script uses an Ajax cross-domain request to send an
unexpected authentication request to the target RP website, as in
5.1. Proposed modifications to the FIDO2 protocol
step 1. Because the attack process occurs when the user browses
an unrefreshed web page, it is difficult for the user to deter-
mine that the processing request originates from an unexpected Suppose that a malicious process tampers with the transac-
website. After the user performs authentication to the target RP tion message in an authentication request during a transaction
confirmation process. In this case, a user will see a fake trans-
website, the attacker can launch a subsequent attack.
action message. To prevent malicious processes from tampering
with the transaction message, the user must verify its integrity.
4.4. Implicit authentication attacks Currently, the FIDO2 protocol places the transaction message in
the txAuthSimple field in an authentication request. To verify the
Currently, there is no display module in the authenticators cer- transaction message’s integrity, we add the transaction message’s
tified by the FIDO Alliance. Applications could display transaction signature in the authentication request.
messages in different ways. Thus, users encounter difficulty in Fig. 9 shows the proposed modifications to the FIDO2 protocol
identifying status changes in the authenticator when performing in red. The details are as follows.
authentications. This flaw may cause users to inadvertently per-
form authentication, as in step 5 in Fig. 7, and the following three (1) In step 2, RP uses the website certificate’s private key to
dangerous situations may result. sign the transaction message and place the signature in an
extension field named txTextSignature.
(1) Some authenticators may perform identity verification with- (2) After receiving the user request in step 5, the browser for-
out noticing, such as by fingerprint recognition or by touch- wards the authentication request to SDD, which verifies the
ing a button. transaction message’s signature in the authentication re-
(2) For an authenticator with an authentication cache, an at- quest. If verification fails, SDD rejects the request. Otherwise,
tacker may restart a previous request when this past request SDD sends the authentication request to the authenticator for
remains in the authentication cache. further processing.

36
P. Xu, R. Sun, W. Wang et al. Future Generation Computer Systems 125 (2021) 32–40

Fig. 11. SDD verification workflow.

Fig. 9. Signature and verification of transaction message. adr to find the corresponding s in its local database and cal-
culates HMAC-SHA256s (challenge). The authenticator compares
the calculation result with the token in the verification request.
If the verification succeeds, the authenticator sends the result
back to SDD. During the transaction confirmation process, SDD
sends the verification request and the authentication request to
the authenticator together. Only one round of communication is
required between the SDD and the authenticator instead of two,
thereby reducing communication overhead.
SDD logout process. Users do not need to logout from SDD
manually. With the LRU algorithm, the authenticator automati-
cally deletes data that has not been used for the longest time.
When the user agent runs a new SDD process, the previous data
in the authenticator can be automatically overwritten with the
user’s consent.
Mal-process detection. The malicious process initiates an at-
Fig. 10. SDD registration workflow.
tack by sending requests to the SDD at a high rate [13]. SDD main-
tains a cache of authentication requests. When a new request
arrives, SDD updates the cache and deletes expired requests.
5.2. Secure display daemon When a process requests too many times within a specified time,
SDD terminates the request currently being processed and sends
To achieve a lightweight trusted path, we run SDD on the a warning message to the user.
user’s device and use an HMAC-based authentication to prevent The improved scheme is compatible with the original FIDO2
other processes from calling an authenticator directly. To avoid protocol. When the SDD runs on the user device, the browser calls
imposing additional requirements on the authenticator, we use the SDD interface to verify the transaction content’s integrity.
the HMAC-SHA256 algorithm that is natively supported by the Otherwise, the browser calls the original FIDO2 interface to ac-
FIDO2 protocol [5]. The specific process is as follows. cess the authenticator directly. Even on devices without SDD,
SDD registration process. As shown in Fig. 10, when a user users can still perform authentication through the original FIDO2
runs an SDD process on a device for the first time, SDD randomly protocol.
$
generates secret key s ← − {0, 1}256 and sets adr to the MAC In summary, as a trusted path, SDD provides us with the
address of the user’s device. When the device connects to a new following three functions. First, SDD verifies the contents of the
authenticator, it sends (adr , s) to the authenticator to perform transaction by checking the corresponding fields in an authentica-
the registration process of SDD. After receiving the registration tion request when executing a transaction confirmation request.
request, the authenticator adds (adr , s) to a local database. We SDD looks up the corresponding RP server’s certificate in the
use the well-known least recently used (LRU) algorithm to pre- browser cache and verifies the transaction message’s integrity.
vent the secret key database stored in the authenticator from Second, SDD provides a unified and trusted display for authen-
becoming too large. tication requests. SDD displays the domain name and transaction
SDD verification process. As shown in Fig. 11, when the message to users. Last, SDD detects malicious processes. In attacks
SDD receives a verification request, it must prove its identity to where the malicious process occupies the authenticator, SDD
the authenticator. To ensure that the secret value stored in the detects such processes and sends a warning message to the user.
verification process is secure, we do not directly transmit the
secret key s. SDD sets 5.3. Proposed ultimate authentication process
token = HMAC-SHA256s (challenge)
Considering a financial website as an example to introduce the
and sends (adr , challenge, token) to the authenticator. By trans- proposed authentication process, we assume that a user seeks to
ferring token between SDD and authenticator, we can thus ef- transfer money to another person on the financial website. Fig. 12
fectively prevent eavesdropping and replay attacks. After the au- shows the corresponding workflow. The SDD process is running
thenticator receives the verification request, it uses the received on the user’s device. The details are as follows.
37
P. Xu, R. Sun, W. Wang et al. Future Generation Computer Systems 125 (2021) 32–40

(1) The user accesses the financial website through his browser.
When he decides to transfer his money to another account,
he sends a transaction confirmation request to the financial
website server.
(2) The financial website server receives the request and gener-
ates a transaction message based on the request, such as ‘‘A
transfers $100 to B’’.
(3) The FIDO2 module in the website server constructs an au-
thentication request. The request contains randomly gener-
ated challenge data, transaction message, and the signature
to the transaction message.
(4) The financial website server sends the authentication re-
quest to the user’s browser.
(5) The browser sends the authentication request to the SDD by
calling the JS library.
(6) SDD extracts the txTextSignature, txAuthSimple, and origin
fields in the request and verifies the correctness of the
txTextSignature according to the public key obtained from
the origin field. If verification fails, the process exits. If veri-
fication succeeds, the next step is performed.
(7) SDD displays the transaction message. The user observes the
Fig. 12. Ultimate authentication workflow.
transaction details and confirms the transaction.
(8) SDD uses HMAC-SHA256 algorithm to calculate token. SDD
then adds (adr , token) to the authentication request and
sends the authentication request to the authenticator. In a tampering display attack, a malicious script replaces the
(9) The authenticator looks up the corresponding secret key s transaction display content on the browser to trick the user into
according to adr in the authentication request; if not found, performing authentication. Because there is no trusted path to
the SDD registration process is first executed (see Section 5.2 verify transaction messages’ integrity, users cannot guarantee
for the registration process). Then, the authenticator per- the ‘‘What You See Is What You Sign’’ requirement when an
forms the same steps in algorithm. If the result matches XSS attack occurs. In the proposed scheme, SDD can verify the
the token in the authentication request, the next step is integrity of the transaction message, effectively preventing such
performed. attacks.
(10) The user performs an authorization gesture. In a misauthentication attack, a malicious script can send a
(11) After authenticating the user, the authenticator unlocks the request to a target website without refreshing the current page
user’s private key and signs the challenge, which is contained to trick users into performing authentication. In the proposed
in the authentication request, with this private key. The solution, even if the current page is not refreshed, the user can
authenticator then constructs an authentication response, still observe the origin field of the current request in the SDD
including the signature just generated. display, making it easy to distinguish a misauthentication attack.
(12) The authenticator sends the authentication response to the In an implicit authentication attack, the attacker performs
browser through SDD. The browser then forwards the au- authentication without the user’s attention. The FIDO2 protocol
thentication response to the financial website server. does not have a unified display mode, which allows the attack. To
(13) After receiving the authentication response, the financial resist the three attacks mentioned in Section 4.4, SDD can explic-
website server looks up the user’s public key according to itly display the authentication request. After the user confirms the
the user’s username and verifies the response’s signature. If transaction message, SDD forwards the authentication response
valid, the financial website server executes the transaction for further processing.
and sends the final result to the user’s browser.
6.2. Experiment

6. Security analysis and performance We designed and conducted experiments to test the original
FIDO2 protocol and the proposed scheme. We compared their
6.1. Security time overheads and data transmission overheads, and analyzed
the improved scheme’s impact on the user experience.
For the four types of attacks described above, we separately Test environment. We conducted experiments on a computer
analyzed the security of the improved scheme. with an Intel Core i5-10300H 2.5-GHz processor, 16 GB of RAM
In a mal-process occupying attack, the malicious process in- and a 512 GB hard disk that was running Windows 10 Pro
terrupts and replaces the current authentication request to trick 19041 and the browser Firefox 81.0.2. Currently, authenticator
the user into signing the wrong authentication request. Because manufacturers typically use capacitive buttons, fingerprint recog-
the authenticator does not have a trusted display path, the user nition, and PIN codes for user verification. Capacitive buttons
cannot distinguish the authentication request that is currently are the most commonly used mechanism due to their simple
being processed. In the proposed scheme, SDD displays the do- implementation and low cost. Moreover, compared to PIN code
main name and transaction message of the current processing and fingerprint recognition, a capacitive button requires a shorter
request to users in a unified way, allowing users to observe the interaction time, which is more representative for experimental
interruption of malicious processes quickly and easily. Thus, the analysis. Therefore, we use the YubiKey 5 NFC authenticator with
authentication response will not be sent to the browser before the a capacitive button.
user confirms the request, effectively preventing the processing of Data transmission overhead. We executed the transaction
erroneous requests. confirmation process with the original FIDO2 protocol and the
38
P. Xu, R. Sun, W. Wang et al. Future Generation Computer Systems 125 (2021) 32–40

Fig. 13. Performance comparison between original protocol and improved scheme.

proposed scheme. For transaction messages of different lengths, CRediT authorship contribution statement
we recorded the data transmission volume and time overhead of
authentication. Fig. 13a shows the data transmission volume be- Peng Xu: Conception or design of the work, Acquisition, Anal-
tween the RP server and the user’s device. The improved scheme ysis, or interpretation of data for the work, Writing - original
added a signature to the transaction message in authentication draft, Writing - review & editing. Ruijie Sun: Conception or
request, and the associated data transmission increased by 31.03% design of the work, Analysis, or interpretation of data for the
compared to the original FIDO2 protocol on average. Fig. 13b work, Writing - original draft, Writing - review & editing. Wei
shows the data transmission volume between the user’s device Wang: Conception or design of the work, Acquisition, Analysis,
and the authenticator. The increased data volume originated in or interpretation of data for the work, Writing - original draft,
the token and adr field, and there is an associated 10.92% increase Writing - review & editing. Tianyang Chen: Conception or design
compared to the original FIDO2 protocol. of the work, Acquisition, Analysis, or interpretation of data for the
Time overhead. Fig. 13c shows the time overhead for the work, Writing - original draft, Writing - review & editing. Yubo
RP server to process authentication requests. On the server side, Zheng: Conception or design of the work, Acquisition, Analysis,
the time overhead of the proposed scheme for processing au- or interpretation of data for the work, Writing - original draft,
thentication request increased by 25.26%. With the YubiKey 5 Writing - review & editing. Hai Jin: Conception or design of the
NFC authenticator, considering the time to perform authorization work, Acquisition, Analysis, or interpretation of data for the work,
gesture, a successful authentication process required an average Writing - original draft, Writing - review & editing.
of 512 ms. The time overhead of the proposed scheme thus
increased by approximately 0.18% compared to the original FIDO2 Declaration of competing interest
protocol.
In terms of operating procedures, the proposed scheme must The authors declare that they have no known competing finan-
only consider the authenticator’s registration process in the SDD cial interests or personal relationships that could have appeared
once. Frequent authentication is consistent with the original pro- to influence the work reported in this paper.
tocol’s experience and will not impact the user experience. In
terms of authentication time, considering that the main time Acknowledgments
for authentication is the time to perform authorization gesture
(e.g., clicking a button), the improved scheme only slightly in- The paper is partly supported by the National Natural Sci-
creases the time overhead (e.g., 0.18% with the YubiKey 5 NFC ence Foundation of China under Grant No. 61702206 and No.
authenticator). Therefore, the impact of the proposed solution on 61872412, the Wuhan Applied Foundational Frontier, China
user experience is negligible. Project under Grant No. 2020010601012188, the Guangdong
Provincial Science and Technology Plan, China Project under
Grant No. 2017B010124001, and the Guangdong Provincial Key
7. Conclusion R&D Plan, China Project under Grant No. 2019B010139001. We
have approved the final version to be published.
In this study, we analyzed the authentication process of the
FIDO2 protocol and found four display-related attacks: References
mal-process occupying attacks, tampering display attacks, mis-
authentication attacks and implicit authentication attacks. We [1] D. Wang, Z. Zhang, P. Wang, J. Yan, X. Huang, Targeted online password
modified the original FIDO2 protocol to add a signature to the guessing: An underestimated threat, in: Proceedings of the 2016 ACM
transaction message to ensure integrity during transmission. We SIGSAC conference on computer and communications security, 2016, pp.
1242–1254.
also ran a lightweight SDD process on the user’s device to verify
[2] R. Lindemann, D. Baghdasaryan, E. Tiffany, D. Balfanz, B. Hill, J. Hodges,
the signature and provide a unified display. We then compre-
FIDO UAF Protocol Specification V1. 0, FIDO Alliance, 2014.
hensively tested the proposed scheme. Compared to the origi- [3] S. Machani, R. Philpott, S. Srinivas, J. Kemp, J. Hodges, FIDO UAF
nal FIDO2 protocol, authentication time overhead increased by Architectural Overview, FIDO Alliance, 2014.
0.18%, and data transmission increased by 31.03%. In practice, the [4] S. Srinivas, D. Balfanz, E. Tiffany, Universal 2nd Factor (U2F) Overview,
proposed scheme exerts little impact on the user experience. FIDO Alliance, 2014.

39
P. Xu, R. Sun, W. Wang et al. Future Generation Computer Systems 125 (2021) 32–40

[5] C. Brand, A. Czeskis, J. Ehrensvard, M. Jones, A. Kumar, R. Lindemann, Ruijie Sun received a B.E. degree in computer science
A. Powers, J. Verrept, FIDO 2.0: Client To Authenticator Protocol, FIDO from Huazhong University of Science and Technology,
Alliance, 2019. Wuhan, China, in 2018. He is currently working to-
[6] D. Balfanz, A. Czeskis, J. Hodges, J. Jones, M. Jones, A. Kumar, A. Liao, R. ward a master’s degree in cyberspace security at the
Lindemann, E. Lundberg, Web authentication: An api for accessing public Huazhong University of Science and Technology. His
key credentials, 2019, URL: https://www.w3.org/TR/2019/REC-webauthn- research interests include online authentication and
FIDO protocol.
1-20190304/ (accessed: 2021-02-01).
[7] M. Togan, B.-C. Chifor, I. Florea, G. Gugulea, A smart-phone based privacy-
preserving security framework for iot devices, in: 2017 9th International
Conference on Electronics, Computers and Artificial Intelligence (ECAI),
IEEE, 2017, pp. 1–7.
Wei Wang received the B.E. and Ph.D. degrees in Elec-
[8] Y. Zhang, X. Wang, Z. Zhao, H. Li, Secure display for fido transaction
tronic and Communication Engineering from Huazhong
confirmation, in: Proceedings of the Eighth ACM Conference on Data and
University of Science and Technology, Wuhan, China,
Application Security and Privacy, 2018, pp. 155–157. in 2006 and 2011, respectively. Currently she works
[9] A. Brandon, M. Trimarchi, Trusted display and input using screen overlays, as a researcher with Cyber–Physical–Social Systems
in: 2017 International Conference on ReConFigurable Computing and Lab, Huazhong University of Science and Technology,
FPGAs (ReConFig), IEEE, 2017, pp. 1–6. Wuhan, China. Her research interests include cloud
[10] M. Yu, V.D. Gligor, Z. Zhou, Trusted display on untrusted commodity plat- security, network coding and multimedia transmission.
forms, in: Proceedings of the 22nd ACM SIGSAC Conference on Computer She has authored more than 20 papers in international
and Communications Security, 2015, pp. 989–1003. journals and at conferences.
[11] B. Zhu, X. Fan, G. Gong, Loxin-a solution to password-less universal login,
in: 2014 IEEE Conference on Computer Communications Workshops, IEEE, Tianyang Chen received a B.E. degree in informa-
2014, pp. 488–493. tion security from Huazhong University of Science
[12] F. Stajano, Pico: no more passwords!, in: International Workshop on and Technology, Wuhan, China, in 2017. He is cur-
Security Protocols, Springer, 2011, pp. 49–81. rently working toward a doctor’s degree in cyberspace
[13] T. Bui, S.P. Rao, M. Antikainen, V.M. Bojan, T. Aura, Man-in-the-machine: security at the Huazhong University of Science and
exploiting ill-secured communication inside the computer, in: 27th USENIX Technology. His research interests include cryptography
Security Symposium, 2018, pp. 1511–1525. and IoT.
[14] T. Alves, D. Felton, Trustzone: Integrated Hardware and Software Security,
White Paper, 2004.
[15] V. Costan, S. Devadas, Intel sgx explained, IACR Cryptol. EPrint Arch. 2016
(2016) 1–118.
[16] S.G. Lyastani, M. Schilling, M. Neumayr, M. Backes, S. Bugiel, Is fido2 the Yubo Zheng received a B.E. degree in information
kingslayer of user authentication? a comparative usability study of fido2 security from Huazhong University of Science and
passwordless authentication, in: 2020 IEEE Symposium on Security and Technology, Wuhan, China, in 2019. He is currently
Privacy, IEEE, 2020, pp. 268–285. working toward a master’s degree in cyberspace se-
[17] S. Das, A. Dingman, L.J. Camp, Why johnny does not use two factor a curity at the Huazhong University of Science and
Technology. His research interests include cryptography
two-phase usability study of the fido u2f security key, in: International
and lattices.
Conference on Financial Cryptography and Data Security, Springer, 2018,
pp. 160–179.
[18] D. Baghdasaryan, B. Hill, J.E. Hill, D. Biggs, FIDO Security Reference, FIDO
Alliance, 2018.
[19] Y. Zhang, Q. Liu, Q. Luo, X. Wang, Xas: Cross-api scripting attacks in social Dr. Hai Jin received his Ph.D. degree in computer
ecosystems, Sci. China Inf. Sci. 58 (2015) 1–14. engineering from Huazhong University of Science and
Technology, in 1994. He received German Academic
Exchange Service fellowship to visit the Technical Uni-
versity of Chemnitz in Germany in 1996. He worked at
Peng Xu received a Ph.D. degree in computer science
the University of Hong Kong between 1998 and 2000,
from Huazhong University of Science and Technology,
and as a visiting scholar at the University of Southern
Wuhan, China, in 2010. He worked as a post-doctor
California between 1999 and 2000. He received the
at Huazhong University of Science and Technology,
Excellent Youth Award from the National Science Foun-
Wuhan, China, from 2010 to 2013, and as an associate
dation of China in 2001. He is a Cheung Kung Scholars
research fellow at the University of Wollongong, Aus-
chair professor of computer science and engineering of
tralia, from 2018 to 2019. Now, he is a full professor
Huazhong University of Science and Technology. He has coauthored 22 books
at Huazhong University of Science and Technology. His
and published over 800 research papers. His research interests include computer
research interests are in the field of cryptography. He
architecture, virtualization technology, cluster computing and cloud computing,
authored over thirty research papers, sixteen patents,
peer-to-peer computing, network storage, and network security. He is a fellow
and two books. He was PI in nine grants, including
of the CCF, a fellow of the IEEE and a member of the ACM.
three NSF projects.

40

You might also like