FIDO2 With Two Displays—Or How to Protect

Security-Critical Web Transactions Against

Malware Attacks
Timon Hackenjos∗ , Benedikt Wagner† , Julian Herr∗ , Jochen Rill‡ , Marek Wehmer∗ , Niklas Goerke∗ , Ingmar Baumgart∗
∗ FZI Research Center for Information Technology
† CISPA Helmholtz Center for Information Security
‡ Alter Solutions Deutschland
arXiv:2206.13358v1 [cs.CR] 27 Jun 2022

Abstract—With the rise of attacks on online accounts in the possibly remember that many different passwords (and the
past years, more and more services offer two-factor authenti- adoption of password managers is still very low) re-using
cation for their users. Having factors out of two of the three passwords on a multitude of different sites is a common prac-
categories something you know, something you have and something
you are should ensure that an attacker cannot compromise two tice [2]. This means that one stolen password from an account
of them at once. Thus, an adversary should not be able to on an unimportant website might also give an adversary access
maliciously interact with one’s account. However, this is only to more important ones, like an online banking account.
true if one considers a weak adversary. In particular, since most As more and more of our private and professional life started
current solutions only authenticate a session and not individual to happen on the Internet, compromising accounts through
transactions, they are noneffective if one’s device is infected
with malware. For online banking, the banking industry has simple and cheap attacks like credential stuffing and phishing
long since identified the need for authenticating transactions. became increasingly more attractive and lucrative for attackers.
However, specifications of such authentication schemes are not To mitigate these risks, security experts started to advertise
public and implementation details vary wildly from bank to the use of two-factor authentication instead of only a single
bank with most still being unable to protect against malware. password [3]. A mandatory second authenticating factor (like
In this work, we present a generic approach to tackle the
problem of malicious account takeovers, even in the presence a one-time password (OTP)) severely restricts the utility of
of malware. To this end, we define a new paradigm to improve stolen passwords for an attacker. Users and account providers
two-factor authentication that involves the concepts of one-out- alike took a very long time to adopt this recommendation,
of-two security and transaction authentication. Web authentication but nowadays many web applications offer at least one form
schemes following this paradigm can protect security-critical of two-factor authentication. Most implementations require the
transactions against manipulation, even if one of the factors
is completely compromised. Analyzing existing authentication user to present a second factor together with a password during
schemes, we find that they do not realize one-out-of-two security. login. If successful, the user then receives an authenticated
We give a blueprint of how to design secure web authentication session token (stored within a cookie), which she can use
schemes in general. Based on this blueprint we propose FIDO2 to interact with the site and her account without having to
With Two Displays (FIDO2D), a new web authentication scheme authenticate herself again for a while.
based on the FIDO2 standard and prove its security using
Tamarin. We hope that our work inspires a new wave of When using two-factor authentication, it is recommended
more secure web authentication schemes, which protect security- to use two of the three following factors: something you
critical transactions even against attacks with malware. know, something you have and something you are. Behind
Index Terms—web authentication, malware, two-factor au- this categorization lies the assumption that it is improbable
thentication, transaction authentication, one-out-of-two security, for the same adversary to compromise factors from different
Tamarin, 2DA, FIDO2D
categories (e.g., an adversary that gets a password from a
password leak cannot also steal a copy of the user’s finger-
I. I NTRODUCTION
print). However, this is only true in a very specific adversarial
In recent years, the World Wide Web and the multitude of model. An attacker who has compromised a victim’s computer
different services offered within changed almost everyone’s does not need to steal a copy of the fingerprint; he can
life. Whether we want to send an email, do online banking, simply manipulate all interactions with a website by using
buy a product, or update our social media profile, we use the the authenticated session token stored in the browser after the
Web. In general, each of these activities requires a separate victim performed a legitimate login.
account with which we authenticate ourselves. According to a Indeed, two-factor authentication as it is used today does
study by Google in partnership with The Harris Poll in 2019, not help against a number of attack techniques used by
the average American has 27 different online accounts [1]. real-life adversaries [4]–[6]. Most schemes are susceptible
Passwords always were and still are the main means of to malware attacks and some popular forms, like OTP, are
authentication on the Internet. However, since one cannot also vulnerable to real-time phishing, in which an adversary
relays authentication details from a fake website to a legitimate II. O UR C ONTRIBUTION
one [7], [8].
Bruce Schneier adequately summarized the applicability of In this work, we analyze the security of web authentication
two-factor authentication in as early as 2005: “Two-factor schemes in the presence of malware and real-time phishing
authentication isn’t our savior. It won’t defend against phish- attacks. We find that even strong authentication schemes for
ing. It’s not going to prevent identity theft. It’s not going to online banking that rely on transaction authentication as
secure online accounts from fraudulent transactions. It solves required by the revised Payment Services Directive (PSD2)
the security problems we had 10 years ago, not the security do not protect against these attacks.
problems we have today” [9]. As a remedy, we propose that web authentication schemes
In recent years, online banking has been moving into handling security-critical transactions should fulfill one-out-of-
the right direction security-wise by introducing transaction two security, a security notion that neither requires a primary
authentication, which is the verification of transaction details device nor an additional device trusted. We show how this
(often on an additional device, but not necessarily). Authen- security notion introduced for electronic payment can be
ticating transactions individually mitigates the risk of session adapted to web authentication. Furthermore, we provide a
hijacking by stealing a cookie. Furthermore, manipulation of blueprint to design web authentication schemes that fulfill this
transaction details can be detected if one is using an additional notion and thus protect security-critical transactions even if
device to check them. one device is fully compromised.
The chip authentication program (CAP) protocol used in Based on our blueprint, we design and implement FIDO2
online banking thus provides a high level of security. It relies With Two Displays (FIDO2D), a web authentication scheme
on a dedicated card reader with a display. The device offers based on the FIDO2 standard. We identify shortcomings of
a very small attack surface for infection by malware as it has FIDO2 for implementing malware-resistant web authentication
limited functionality and is specifically built for this use case. and show how they can be treated. Integration into the FIDO2
Carrying an additional device has been identified as un- standard would pave the way for broad adoption of our
pleasant for many users [10], [11]. In consequence, many approach. We examine multiple use cases that benefit from
banks abandoned dedicated hardware tokens and transitioned the security guarantees of FIDO2D.
to app-based authentication schemes such as photoTAN. How- Finally, we provide a formal model of FIDO2D and prove
ever, similar to regular computers, smartphones have large that it fulfills one-out-of-two security using Tamarin.
attack surfaces, are susceptible to, and have been attacked
by malware [12]. By compromising the smartphone, attackers III. ATTACKS ON W EB AUTHENTICATION
can bypass confirmation of transactions on the device [13].
Therefore, if an attacker gets access to the user’s password, In this section, we analyze attacks on current web authenti-
he can access the online banking system and execute arbitrary cation schemes and introduce our attack model that serves as
transactions (see Section III). Some banks even allow initiating the basis for all of the following.
transactions from the same device [13]. Thus, most current
online banking schemes, which are required by law to offer A. Password Attacks
strong security [14], do not adequately protect against malware
attacks, since the smartphone needs to be fully trusted. Besides Password authentication is by far the most prominent
online banking, many other use cases such as administration authentication scheme in the web. The main problems of
panels and electronic health records handle security-critical password authentication are that users choose weak pass-
transactions (see Section VII). However, most of them do not words and reuse them across multiple sites [16]. Brute-force
implement transaction authentication and thus do not protect and password spraying attacks exploit weak passwords while
against malware attacks. credential-stuffing attacks focus on reused passwords. For
The recent FIDO2 standard provides a widely implemented example, the video conferencing solution Zoom was hit by
browser API called WebAuthn that simplifies integration of a credential-stuffing attack and a large number of accounts
secure web authentication mechanisms relying on public- were compromised [17]. The success of these attacks is
key cryptography and supporting authentication of individual not surprising considering the amount of publicly available
transactions. However, authentication with FIDO2 is primarily credentials [18].
used for login today and thus suffers from susceptibility to Risk-based authentication (RBA) aims to strengthen pass-
malware attacks as described before. The support for trans- word authentication by monitoring features such as the IP
action authentication has even been removed from the latest address and the user agent of the browser and triggering
version of the WebAuthn standard [15]. additional authentication during login if they differ from those
We show how to design web authentication schemes using recorded before [19]. While this limits the impact of a stolen
two devices (one of which could be a smartphone) which password, most features are easy to detect and spoof during a
protect security-critical transactions, even if one device is fully phishing or malware attack. Criminal platforms evolved that
compromised. While this might seem like an impossible task, sell access to user profiles containing credentials and features
it can be done. In the following, we show how. that allow bypassing RBA [20].
 1. initiate t 2. initiate t' an OTP (3). In this case, the malware prompts the user to
confirm the original transaction t (4). As the user cannot
4. confirm t 3. confirm t' detect the manipulation, she supplies the required OTP (5).
User
6. credential
The attacker can use the OTP to confirm the manipulated
5. credential PC Service
transaction t’ (6). This attack applies to other authentication
Fig. 1. Transaction manipulation attack: malware on the device manipulates schemes such as FIDO2 as well. Transaction manipulation has
the transaction data t and issues a transaction t’ instead. been used extensively in the wild by online banking malware
such as ZeuS and SpyEye [4]. Note that RBA does not prevent
2. confirm login
1. login this attack, as the transaction is initiated in a valid session of
the user.
3. ok
2) Transaction Initiation: Authentication schemes that in-
3. logged in 5. confirm t corporate an additional device for transaction verification are
often susceptible to a transaction initiation attack as depicted
Service
4. initiate t Smartphone in Figure 2. We assume that the attacker compromised the
6. ok
additional device and installed malware. In a next step, the
attacker needs to determine the user’s password using one of
Fig. 2. Transaction initiation attack: malware on a smartphone confirms
transaction initiated by the attacker. the methods from Sections III-A and III-B. Potentially, the
password is even stored on the additional device and thus
accessible to the attacker. With the password, the attacker
B. Real-Time Phishing logs in to the service from his own device using the victim’s
In 2018, Amnesty International reported targeted phishing account (1). The service might require confirmation of the
attacks on Google and Yahoo accounts that bypassed one- login attempt on the additional device, e.g., because the
time password (OTP)-based two-factor authentication [5]. By service implements RBA and detected a change in the user
automating the process of using the stolen password and OTP, profile. Usually, confirmation of the login attempt relies on text
the attackers were able to work around the short validity of messages, email or an app [26]. However, since the attacker
the token. Despite being more complex than classic phishing remotely controls the additional device, he can confirm the
attacks that only harvest passwords for later use, real-time login request (3) [13]. After logging in successfully, the
phishing attacks are not sophisticated. Several tools are pub- attacker can initiate an arbitrary transaction t (4). The service
licly available to automate this attack [21], [22]. In addition, might require confirmation of the transaction (5), however,
real-time phishing attacks can be used to identify features of again the attacker controlling the additional device can confirm
the user necessary to bypass RBA [20]. the request (6).

C. Malware D. Our Attack Model

As described in prior work, multiple ways exist to re- We identify the following three main means of attack on
motely infect devices with malware ranging from drive-by web authentication schemes:
downloads and email attachments to social engineering attacks • Password attacks
that convince a user to install malware herself [23], [24]. • Real-time Phishing
Google’s Threat Analysis Group even detected the use of a • Malware
zero-day exploit to install malware stealing cookies for popular Malware attacks are more powerful than real-time phishing
websites such as Google, Microsoft and LinkedIn [25]. Of and password attacks. Password attacks give access to pass-
course, smartphones are affected by malware too [12]. In the words only. In addition, real-time phishing grants access to
following, we discuss two types of attacks that can be carried other credentials entered by the user such as an OTP. The
out by malware to issue a malicious transaction. strongest type of attack is compromising a device and infecting
1) Transaction Manipulation: In the following, we assume it with malware. This grants full access to input and output
that an authentication scheme is used that does not display interfaces of a device such as the keyboard and display, as
transaction details on an additional device. Malware on the well as credentials stored on the device. Thus, malware on a
primary device can then carry out a transaction manipulation device might eavesdrop on credentials entered by the user, as
attack as depicted in Figure 1. Suppose that a user wants well as manipulate information displayed on the screen.
to make a security critical transaction on a website. After We assume malware to be executed with the highest user
logging in (potentially with two factors), she enters the desired privileges available such as root or administrator and thus mal-
transaction details t (1), however, the compromised device ware might manipulate the operating system. This assumption
initiates a manipulated transaction t’ (2). If the service relies is supported by prior work that documents the use of privilege
on session authentication only, the manipulated transaction t’ escalation attacks in the wild [12]. Furthermore, a similar
is authenticated by the cookie sent by the browser and thus model for malware has been used in prior work [8], [13].
confirmed immediately. However, the service might require Because of the high prevalence of password and phishing
confirmation by a second factor for transaction t’ such as attacks [16], we assume all attackers to be able to carry them
out. However, we differentiate attackers by their ability to the presence of malware. As described in Section III, malware
infect involved devices with malware (see Section VIII). Fur- and real-time phishing attacks are not prevented thoroughly by
thermore, we consider that an attacker can carry out multiple current two-factor authentication schemes.
attacks targeting the same user. For example, an attacker that Two-factor authentication schemes used in online banking
infects a smartphone with malware can also mount a password such as the chip authentication program (CAP) protocol and
or phishing attack targeting the account of the user. photoTAN provide resistance against malware on the device
running the browser. However, the reason for this does not
IV. M ALWARE -R ESISTANT W EB AUTHENTICATION lie in the fact that they fulfill the two-factor authentication
As discussed in the last section, a secure web authentication definition, but that they require the user to verify transaction
scheme should protect against real-time phishing and malware details on a separate device. Thus, we need a new way of
attacks. In the following, we argue that the concept of trans- defining two-factor authentication that fulfills the intuitive
action authentication is inevitable to protect against malware promise of the notion: ensuring the security of a scheme even
attacks and that two-factor authentication, as it is currently if one of two factors is fully compromised. This redefinition
defined, does not provide security benefits in this attack model. of two-factor authentication makes malware and real-time
phishing attacks infeasible and thus solves the weaknesses of
A. Transaction Authentication current web authentication schemes.
Usually, users sign in into a web service before using it.
During this process, the web service authenticates the user and C. One-out-of-two Security for the Web
establishes a session. Session authentication means that that
once the session is created, the user is allowed to perform an In their work on secure electronic payment, Achenbach et
arbitrary number of actions by sending requests to the service. al. [27] formalize exactly this requirement. The authors model
It can be described as authenticating the session and then an electronic payment protocol using two separate devices that
assuming every action performed as part of the session has is still secure (with regards to specific security properties)
been authorized by the user. even if one of the devices is fully compromised. They call
On the other hand, using transaction authentication transac- this property one-out-of-two security and show that it can be
tions are initiated in an authenticated session, but confirmation fulfilled by requiring the user to verify the transaction details
of each individual transaction is required (e.g., verification on both devices. We adapt this idea of one-out-of-two security
of transaction details by the user on a separate device). to web authentication by letting the user verify details of
Nonetheless, transaction authentication is usually used for individual transactions on two separate devices.
security-critical transactions only. For example in online bank- The authors rely on a so-called confirmation channel to
ing, transferring money between a checking and a savings build a scheme that fulfills one-out-of-two security. The trans-
account of the same user could rely on session authentication. action details are displayed to the user (e.g., on an additional
Security-critical transactions such as bank transfers to an exter- device) and explicit confirmation is required before performing
nal account should require transaction authentication. These the transaction. We reuse the idea of a confirmation channel
transactions must be identified for each use case on its own. in the design of our web authentication scheme. However,
We provide examples for such transactions in Section VII. whereas Achenbach et al. explicitly allow an attacker to break
Relying on session authentication only is fundamentally their protocol by guessing the Personal Identification Number
flawed in the presence of malware. Taking control of the (PIN) correctly, we use a slightly stronger version of one-
session lets an attacker interact with the service on behalf out-of-two security. Our notion also prevents attacks that
of the user, independently of the used authentication proce- circumvent compromising a device by breaking an underlying
dure. Thus, strong security guarantees can only be stated for authentication scheme such as passwords. According to our
transactions protected by transaction authentication. However, definition, a protocol that uses two separate devices exhibits
transaction authentication is not sufficient to protect against one-out-of-two security, if an attacker who has the capabilities
malware attacks on its own [13]. Combined with other mea- defined in our attack model in Section III is not able to issue
sures proposed below, individual transactions can be protected a fraudulent transaction without compromising both devices.
to make it impossible for an attacker to perform an unsolicited Note that the goal of the security property is authenticity of
transaction without the user explicitly authenticating it. transactions and not confidentiality of the transaction details.
To be able to confirm the authenticity of a transaction on
B. Flaws in Two-Factor Authentication two devices, the user must either see or enter the details on
The notion of two-factor authentication is too weak in a each device separately. In either case, both devices will need
realistic attack model and does not imply any security guaran- to handle the transaction details in plain text. Thus, compro-
tees in the presence of a malware or phishing attacker, even for mising one device is enough to violate the confidentiality of
individually authenticated transactions. Intuitively, we expect a transaction details. As described in Section VII, by limiting
two-factor authentication scheme to be secure as long as one of access to actions that return or change data on the service, the
the two factors is not compromised. However, this is satisfied authenticity guarantee of transactions can be used to achieve
neither by the notion nor by currently deployed schemes in integrity and confidentiality of data stored on the server.
D. Blueprint for Secure Web Authentication V. T WO D ISPLAY AUTHENTICATION USING FIDO2
We use our blueprint 2DA from the last section to design
Constructing a web authentication scheme that fulfills one-
FIDO2 With Two Displays (FIDO2D), a new scheme for web
out-of-two security and is thus only vulnerable to attackers
authentication that fulfills one-out-of-two security, i.e., the
that are able to compromise both devices is not an easy task.
scheme is secure as long as one of the two devices is not
As we will show in Section VIII, commonly used schemes do
compromised. We refer to Section VI for a detailed security
not have this property.
proof. On a high level, a user U aims to initiate a transaction
We propose Two Display Authentication (2DA), a blueprint at a server S using a computer B running a browser. The user
for secure web authentication. Following the blueprint simpli- also holds an additional device A, such as a smartphone.
fies constructing schemes that fulfill one-out-of-two security. We assume that (2DA.4) is already satisfied by existing
We identify the following requirements for 2DA. mechanisms that restrict the access to B and A. Following
(2DA.1) Authenticate each security-critical transaction indi- (2DA.3), we build on top of an existing authentication mech-
vidually. anism with appropriate security, and following (2DA.2) we
(2DA.2) Require verification of transaction details by the user use two instances of this mechanism. That is, one instance
on both devices. is executed between B and S, and one instance is executed
(2DA.3) Use mechanisms for client and server authentication between A and S. Again, following (2DA.2) we let the user
that protect against non-malware attacks. verify the transaction details during both instances. To be more
(2DA.4) Use local authentication mechanisms to limit access precise, we organize both instances in a way that the user
to the devices. enters the transaction details in the browser on B and require
verification of the transaction data by the user on A using
The first requirement addresses that the security guarantees
a confirmation channel. In the following, we introduce the
can only be stated for transactions that are authenticated
underlying authentication scheme FIDO2, and then describe
individually. The second requirement is necessary to thwart
the protocol for registration and authentication in its entirety.
attacks that involve one of the two devices being compromised.
Entering the transaction details on a device instead of reading A. FIDO2
them from the display is also possible. Furthermore, the third We use FIDO2 as the underlying authentication mechanism.
requirement relates to the communication between the devices That is, our protocol consists of two instances of FIDO2.
and the server. It ensures that an attacker is not able to FIDO2 is an interactive public-key challenge-response authen-
authenticate to the service without compromising a device. tication protocol published by the Fast IDentity Online (FIDO)
For example, using a password for login, compromise of the Alliance. It is used on top of TLS. Both registration and
primary device is not necessary to attack the scheme. Password authentication consist of a three-message flow between client
and phishing attacks are sufficient to bypass authentication and server. The first message from client to server initiates the
of the primary device. Thus, one-out-of-two security cannot interaction. The second message is sent from server to client
be fulfilled by relying on password authentication for one of and contains a randomly sampled challenge. Finally, the client
the devices. Finally, the fourth requirement protects devices in sends a signature of this challenge and some additional data
case they are stolen. Even though this is not strictly necessary to the server.
to fulfill one-out-of-two security, we consider it important as More precisely, the client does not do all the computation it-
it prevents physical attackers from compromising or abusing self, but rather forwards messages to a so-called authenticator,
stolen devices. which contains all key material and performs cryptographic
Note that a secure transaction authentication scheme does operations. FIDO2 differentiates platform authenticators that
not protect a user from authenticating an unintended trans- are integrated into devices and roaming authenticators that
action if the original transaction data was manipulated in the can be connected via transports such as USB. For our further
first place. Thus, it is of utmost importance that the transaction description, we focus on the FIDO client, because most
data is either self-explanatory or the user has the ability to authenticators do not contain a display to show transaction
compare the transaction data with a known safe value. For data themselves that is crucial for verification by U.
example, attacks on online banking have been described that There are mainly two reasons for our choice of FIDO2.
are based on manipulating digital invoices [28]. If the original First, it is supported as an API by all modern browsers on the
transaction details are only available on one device, then no client side and libraries for various programming languages on
scheme can offer protection when the device is compromised. the server side. This makes our protocol easy to implement and
The goal of 2DA is to simplify creating web authentication integrate. Second, it offers the security we need for (2DA.3) as
schemes that protect security-critical transactions by relying well as the user verification we need for (2DA.4). Intuitively,
on one-out-of-two security. In the following section, we show FIDO2 is resilient to replay and phishing attacks because both
that building on existing web authentication mechanisms such a random challenge as well as the identifier of S, typically
as FIDO2, we can use this new paradigm to design an a domain name, is signed. Next, we describe our protocol
authentication scheme that is secure, even in the presence of FIDO2D in its entirety to show how the two instances of
malware and real-time phishing attacks. FIDO2 work together.
 U B A S U sB
B sA
A S
pubA ; pubB

U U
confirm reg.? opt U; d U; d
ok! pubB confirm? opt
n ok! Sig(sB ; authch )
n; U; S
confirm reg. U,S? confirm d; U; S? opt0
ok! n ok! Sig(sA ; authch0 ;d )
opt0
pubA

Sender authenticated TLS session Sender authenticated TLS session

Receiver authenticated Receiver authenticated

Fig. 3. Sequence diagram for registration in our protocol FIDO2D. Here, a Fig. 4. Sequence diagram for transactions in our protocol FIDO2D. Here,
user U registers at a server S. The devices B and A are used to generate secret a user U authenticates a transaction with data d with a server S by using
and public keys sB , pubB and sA , pubA during the process. The nonce n is devices B and A. The devices B and A have a secret key sB and sA , and the
randomly generated by S. server S knows the corresponding public keys pubB and pubA . The variables
authch and authch0 ,d contain ch and ch0 , d respectively and are further
explained in the text.
B. Registration
First, the user registers B using the standard FIDO2 regis- detection. This follows the FIDO2 standard. In Figure 4 this
tration ceremony. During registration, S stores the public key is simply presented as Sig(sB , authch ) while authch contains
pubB from B. Then, S provides a nonce to B to link the second the aforementioned data. After receiving the signed challenge
device A to the account. The nonce is transferred from B to from B, the transaction is not yet fully authenticated. The
A using a QR code. Again, we use the FIDO2 registration server S requires a signature from A too. After transmitting
ceremony to store the public key pubA from A on S. d to A, the same FIDO2 protocol is performed between A
In more detail, the registration process is depicted in Fig- and S. Note that for this protocol a fresh challenge ch0 and
ure 3. The server responds to a user registration request with a the public key pubA is used. S links both challenges ch and
set of options opt, containing a random challenge, the identifier ch0 to the transaction data d. We use the Simple Transaction
of the server and the new user, as well as further parameters for Authorization Extension (txAuthSimple) of FIDO2 with data
the creation of credentials. First, the authenticator of B creates d for A. This extension ensures that A receives the transaction
a new credential and sends the public key pubB back to S. data d in combination with the challenge ch0 as part of options
During this process, the user is asked to confirm registration. opt0 , and presents it to the user. After U’s confirmation, A not
Next, the server S randomly generates a nonce n, links it to only signs ch0 , but also d. This allows to bind the challenge
the username, and sends it to B. Then, n is transferred from ch0 to the transaction data d, which is important when the
B to A (e.g., using a QR code). Again, the user is asked to data is transmitted over an insecure channel. As we propose
confirm the registration on the device A. Then, A can initiate a to use TLS, transferring d separately and not signing it would
similar FIDO2 registration ceremony, allowing S to link both suffice in our attack model. However, using txAuthSimple
ceremonies using n. allows adapting the protocol to devices that are not connected
As a result of the registration, S is aware of public keys to the Internet directly and thus require another device to relay
pubA , pubB linked to user U. The devices A and B know the the messages to them. Again, there is additional data that is
secret keys sA , sB for the public keys pubA , pubB , respectively. signed as in authch , and we denote this as authch0 ,d in our
C. Transactions diagram. S only accepts the transaction with data d when
both authentication ceremonies are successful and A signed
The message flow during a transaction is shown in Figure 4.
the correct transaction data d.
Recall that a user U wants to issue a transaction with data d at
a server S. First, U uses B to transfer the intended transaction D. Prototypical Implementation
data d in combination with the username to S. S sends a set of To verify the feasibility of our approach, we implemented
options opt, containing a random challenge ch, and expecting a prototype of FIDO2D consisting of a server component for
a signature of ch for the public key pubB as a result. Again, the S and an Android app running on A. On the server, we use a
user has to confirm before the challenge is signed by B and the Go library for FIDO2 by Duo-Labs1 . We had to add support
signature is sent to S. To be more precise, the signature is com- for the txAuthSimple extension. More specifically, the server
puted over the challenge, an identifier of S, extension data, and
the authenticator’s signature counter, which is used for clone 1 https://github.com/duo-labs/webauthn
Fig. 5. Screenshots of a user’s view in our app prototype during registration.
Left: Registration in the browser using FIDO2. Right: Registration in the app
by scanning a QR code. Fig. 6. Screenshot of our app prototype during transaction confirmation in a
fictitious micro-blogging scenario.

has to check that the authenticator signed the extension data Even though the Client to Authenticator Protocol (CTAP)
containing the transaction details and that they have not been protocol is designed to relay data to an authenticator, we
tampered with. For our app, we use an Android library by decided against using it for our App. CTAP requires the user
Duo-Labs2 to create credentials and sign supplied challenges. to connect the smartphone to the computer during authentica-
Again, we added support for the txAuthSimple extension, tion [30]. However, Bluetooth and NFC are not available on all
which mainly required signing the extension data. On device platforms and USB requires a wired connection. Furthermore,
B, we use the Web Authentication (WebAuthn) browser API current browsers do not forward unsupported extensions and
which is part of the FIDO2 standard and is supported by all thus txAuthSimple could not be used [31]. Thus, we suggest
modern browsers. using push messages and TLS for the communication of
Following the principle (2DA.4) we limit access to the A and S. In our implementation, we use the push service
devices by a local authentication mechanism such as a lock Firebase Cloud Messaging4 . However, we do not transmit any
screen. On A we force the use of a lock screen by enabling the data in the push message, but request the app to establish a
option setUnlockedDeviceRequired of the Android Keystore3 . TLS connection to the server and retrieve data from there.
This ensures that the private key can only be used if the Integration of a push-based transport into CTAP would be
device is unlocked. Access to the private key can be further desirable, as it would allow FIDO2D to rely on standard
restricted by requiring to push a physical button or displaying FIDO2 only. Recently, attempts to integrate such a mech-
transaction data on a protected screen [29]. However, these anism into CTAP [32] have been made, however, they are
mechanisms might affect usability negatively and are not not yet included in the standardized protocol. We hope that
necessary to fulfill one-out-of-two security. We assume that our work strengthens these developments. Furthermore, our
device B has a lock screen set up too. Furthermore, we enable prototypical app could be superseded by integrated support
the requireUserVerification parameter in the WebAuthn API for FIDO2 in mobile operating systems. This requires that
and require the User Verified flag to be set in the signed the smartphone can be used as a roaming authenticator on
authenticator data. This ensures that roaming authenticators another device and that it supports the txAuthSimple extension
that are prone to theft cannot be used without authentication such that transaction data can be verified. Sadly, the extension
e.g., using a PIN. txAuthSimple has been removed in the second level of the
Figure 5 shows the user interface of the registration process. WebAuthn API [15].
On B the browser shows a pop-up asking the user to confirm Although we do not consider recovery in our implementa-
registration with FIDO2. Afterwards, the user links the app on tion, promising methods for recovery of FIDO2 authenticators
A to the account by scanning a QR code from the browser. In have been proposed that do not sacrifice security by incorpo-
the background, the app establishes a connection to the server rating a backup authenticator [33].
and initiates a FIDO2 registration ceremony as well. Figure 6
shows the transaction confirmation screen of our app. In this VI. S ECURITY P ROOF
example, the user initiated a new post on a fictitious micro- We formally prove the security property one-out-of-two-
blogging service. The app displays all relevant information security (see Section IV-C) of our protocol FIDO2D with the
including the username and identifier of the service. help of Tamarin Prover (Tamarin) [34]. Our lemma definitions,
which from Tamarin’s point of view constitute the protocol’s
2 https://github.com/duo-labs/android-webauthn-authenticator security properties, are inspired by [8]. We also analyze the
3 https://developer.android.com/reference/android/security/keystore/KeyGen
ParameterSpec.Builder 4 https://firebase.google.com
rule f i r s t : specifically extended by writing data to the attacker-controlled
[ ] network. This mechanism can be used to leak any kind of data
−− [ ] −> such as key material, identities, nonces as well as a protocol’s
[ NowSecond ( ) ]
message flow.
rule second : A protocol declaration in Tamarin usually contains at least
[ NowSecond ( ) ] one rule with an empty set of in-facts. This rule can be
−− [ ] −> instantiated on the state that only contains facts that are
[ NowThird ( ) ] populated by Tamarin at the start of a program verification
session.
Fig. 7. Example of chaining two Tamarin rules.
B. Our Tamarin Model for FIDO2D
Our model consists of 13 rules and two lemma definitions.
effect of users not verifying transaction data on the security We refer to Appendix A for a complete definition of each
of FIDO2D. While our scheme does not fulfill one-out-of-two- rule, including an enumeration of facts that are produced and
security in this scenario, we prove that it still protects against consumed by it. Each rule’s purpose is briefly explained below:
most types of attacks including phishing and malware on the • new_server: registers a new honest server as a global fact.
additional device. Honest servers cannot be used in phishing attacks.
In the following, we give a brief introduction to Tamarin • register_first_device: Registers a new account at a server
and then describe how we modeled our protocol as well as and connects a user’s first device with it. The device is
the security property. identified by a public key generated for the particular
A. A Short Introduction to Tamarin account. Account and device identities are then leaked to
the attacker.
By modeling a protocol in its custom modeling language, • register_second_device: Finishes registration of a user’s
Tamarin performs unbounded verification of given security account by connecting a second device with it. This step
properties (called lemmas) for the protocol in the symbolic also leaks the public key registered by the second device
model. Within the custom modeling language, individual pro- to the attacker.
tocol steps are expressed as multi-set rewrite rules. These • init_transaction: A user commences a transaction at a
rules describe world state changes during execution flow of server for which there already exists a personal account
a protocol. This world state is tracked by Tamarin in the form with two registered devices. After sending the transaction
of a set of facts. A fact is an atom, optionally associated with with its accompanying data to the network, it waits for a
data such as key material, nonces, identities or constants. A nonce from the server.
rule can query facts as well as add new facts to the state. • receive_transaction: An honest server receives a trans-
Application of a rule can be subject to the existence of a fact action from a previously registered user. It generates a
within the state. Such a fact is called an in-fact. Similarly, facts nonce and sends this back to the user.
that a rule adds to the global state, as a result of its application, • phish_transaction: A user initiates a transaction on a
are called out-facts. Chaining of two rules first, and second phishing server.
is achieved by matching first’s out-facts with the in-facts of • receive_transaction_phisher: A phishing server receives
second (see Figure 7). Additionally, facts may contain data, a transaction of a previously phished user.
such as cryptographic key material, constants and nonces. • sign_nonce: A user signs a nonce on her first device for
Within Tamarin’s input language, interaction with the at- a transaction that has also been started by her.
tacker is modeled by special in- and out-facts, which we briefly • verify_signature: A server verifies the signature of a
explain in the following: previously issued nonce of a user’s first device. It then
• Fr(~var ) is an in-fact that instantiates a variable binding generates a second nonce, which is sent to the user’s
that represents a perfect randomly chosen value. These second device.
values can (among other) be used to model generation of • sign_second_nonce: A user’s second device receives a
nonces and cryptographic key material. transaction request. After the user verified that the dis-
• In( var ) is an in-fact that reads a value from the network. played transaction data corresponds to the transaction she
• Out(var) is an out-fact that writes the contents of its previously initiated, her second device signs the second
argument to the network. nonce. The signed nonce is sent back to the server.
These facts can be employed arbitrarily by the protocol’s • verify_second_signature: A user’s second signature is
rules, are not captured in the global state and as such do verified on the server. If verification succeeds the trans-
not need to have a corresponding counterpart embodied in action is completed, i.e., the server executes the user
the global state already. requested transaction internally.
Facts within the global state as well as facts that are written • compromise_first_device: A user’s primary device is
on the trace, including their respective data captures, are not compromised. We model this by leaking the device’s
known to the attacker. Instead, the attacker’s knowledge is private key to the adversary.
 register first device compromise first device

Registration
register second device compromise second device

init transaction phish transaction

receive transaction

Init transaction receive transaction receive transaction phisher

sign nonce

verify signature

sign second nonce

Verify transaction

verify second signature

Fig. 8. Structure of our Tamarin model. Pictured is the most straightforward order of instantiation of rules for normal and phishing transactions.

• compromise_second_device: A user’s additional device Security (TLS) sessions, our Tamarin model relies on uni-
is compromised. We model this by leaking the device’s lateral authentic channels only. Specifically, we require the
private key to the adversary. communication channels from the server to the user’s devices
An example trace containing a transaction accepted by a to be authentic. We use the rules suggested in the Tamarin
server can be obtained by instantiating the rules in the order manual to model the authentic channel [36]. As a result,
given in Figure 8, excluding rules that model phishing or the actual payload of a transaction is always assumed to be
compromise of devices. In our model, there are two rules transmitted in the clear over an attacker-controlled network.
that do not require custom facts to be present within the These simplifications allow us to present a more concise model
global state, namely new_server and register_first_device. in contrast to a model in which FIDO2 and TLS have also been
Consequently, these two rules can be instantiated regardless of realized. Furthermore, this highlights again that we assume
the current world state within Tamarin. In this example, pro- a strong attack model. In a real-world implementation of
tocol instantiation starts with registration of an honest server FIDO2D, confidentiality is guaranteed by performing trans-
(omitted for clarity in Figure 8), registration of a user’s devices actions within the context of a TLS session.
at this server, initialization of a transaction and verification
of a transaction by the server. These rules correspond to FIDO2D relies on FIDO2 and thus we also model a sim-
three distinct categories: registration, transaction initialization plified version of the FIDO2 protocol. We use the built-in
and transaction verification. In order to model phishing at- signing model of Tamarin that provides the necessary functions
tacks, which is a transaction that is started on a malicious of a signature scheme. To model drawing a fresh nonce as
server, transaction initialization contains two more rules, challenge, we use the built-in fact Fr(~nonce). We simplified
init_transaction_phisher and receive_transaction_phisher. the signed authenticator data to include the server identity
and nonce only. Thus in our model, the signature generation
C. How Our Model Captures Reality can be described as sign(<S, nonce>, privkey ). In our imple-
Tamarin builds on the Dolev-Yao [35] attack model. In mentation, the second device signs the transaction details by
this model, the attacker obtains knowledge of every message usage of the FIDO2 txAuthSimple extension. Therefore, our
sent over the network. He is also able to modify message model assumes that the authenticator data also contains the
contents, suppress and inject messages as well as re-send transaction data for the second device. This is expressed by
known messages at any time in protocol execution. However, the term sign(<S, d, nonce>, privkey ).
the model assumes that the attacker is not able to break
cryptographic schemes without knowing the key. During registration, the registered public keys are written
Although we expect typical implementations of FIDO2D to the attacker-controlled network. We thereby model that
to be embedded within already bootstrapped Transport Layer authentication information stored on a server can be leaked by
lemma o n l y _ u s e r _ i n i t i a t e d _ t r a n s a c t i o n s _ a c c e p t e d :

" A l l i n i t i a t o r t r a n s a c t i o n s e r v e r # i . T r a n s a c t i o n C o m p l e t e ( i n i t i a t o r , s e r v e r , t r a n s a c t i o n ) @i
==>
( ( Ex # j . T r a n s a c t i o n B e g i n ( i n i t i a t o r , s e r v e r , t r a n s a c t i o n ) @j ) |
( Ex # k # l . CompromiseDev1 ( i n i t i a t o r , s e r v e r ) @k & CompromiseDev2 ( i n i t i a t o r , s e r v e r ) @l ) ) "

Fig. 9. A FIDO2D security property which states that only honest (i.e., user initiated) transactions are accepted by a server, captured as a Tamarin lemma.
In conjunction with replay_attack_impossible, this lemma constitutes one-out-of-two-security.

a data breach. However, user devices must not be compromised which the start of a transaction is recorded should be before
during registration. the corresponding completion of said transaction.
Our model considers phishing and malware attacks as By using the Tamarin theorem prover, we verified
described in Section III. We model malware by ex- that our protocol satisfies both lemmas only-user-initiated-
plicitly allowing the attacker to compromise a device. transactions-accepted and replay-attacks-impossible and thus
This is depicted in the rules compromise_first_device and exhibits one-out-of-two security. We sketch why the scheme
compromise_second_device by leaking the stored private key. intuitively fulfills one-out-of-two security and adheres to these
Leaking the private key is a worst-case scenario, as the private lemmas. Assume a user’s first device is compromised and
key is sufficient to impersonate a device completely. her second device is benign. Then, the attacker is able to is-
To consider real-time phishing, we add the rules sue fraudulent transactions or manipulate benign transactions.
phish_transaction and receive_transaction_phisher. The rule During protocol execution the user is asked to confirm the
phish_transaction allows the attacker to force the user to visit transaction data dˆ on her second device although she did not
a potentially attacker-controlled website. In an actual attack, initiate a transaction at all or initiated a transaction with data
this could be accomplished by sending a phishing email with d 6= d. ˆ Clearly, the user will not confirm this transaction
a link to the user. We assume that the user does not notice the and thus the server will not execute the transaction. On the
phishing attempt and continues to follow the protocol by en- other hand, assume her second device compromised and her
tering transaction data. The rule receive_transaction_phisher first device benign. In this case, the attacker cannot initiate
allows the attacker to answer the user’s request with arbitrary a transaction himself. If the user initiates a transaction, the
transaction data and nonce. The whole protocol flow of a attacker is not able to manipulate the transaction data because
phishing attack can be found in Figure 8. After receiving trans- the server links the challenge sent to the user’s second device
action data from the user, the attacker initiates a manipulated to the transaction data entered on the corresponding first device
transaction at the original server. For example, this allows him beforehand. Thus, the attacker can only complete a fraudulent
to relay the nonce of a different transaction to the user. transaction by compromising both devices.

D. Proving One-out-of-two Security

E. Comparing Transaction Data
This model is verified by Tamarin against two lemmas,
only-user-initiated-transactions-accepted and replay-attacks- Our model expects the user to verify transaction data
impossible. Together they form our protocol’s notion of one- properly. User studies suggest that this is not always the
out-of-two-security. The lemmas are inspired by the Tamarin case [37]. Similar to prior work, we extend our model to
proof of SecurePay [8]. We give the definition of the first consider users that do not verify transaction data at all [38]. In
lemma in Figure 9. For brevity, we omit the second lemma and our model, it is sufficient to remove parameters from the fact
refer to Appendix A for the complete definition. Informally the UserWaitForConfirmation. Thereby, the user only confirms a
first lemma states that every transaction that is accepted by a transaction after she initiated one but does not compare the
server has been initiated by an honest user and has not been transaction data. Under this assumption, our protocol does
tampered with. Additionally, the second lemma is necessary to not satisfy one-out-of-two-security. An attacker can break the
prevent replay attacks. It ensures that each accepted transaction scheme by compromising the first device to manipulate a
corresponds to exactly one transaction initiated by an honest transaction initiated by the user. Then, the user confirms the
user. Furthermore, both lemmas contain an additional clause. manipulated transaction on the second device because she does
The additional clause ensures that the lemma is also satisfied not verify the transaction data. However, by removing the rule
if both of the user’s devices have been compromised. In this compromise_first_device we can prove that our protocol resists
case, the protocol cannot provide any security guarantees. an attacker that compromises the additional device and carries
For simplicity, the lemmas do not impose any temporal out password and phishing attacks even if the user does not
order on the sequence of actions on the trace. Thereby, the verify the transaction details at all. Thus, FIDO2D provides
lemmas are more general but consider traces with specific strong security guarantees and even provides one-out-of-two-
temporal order as well. For example, the point of time at security if the user verifies transaction data.
 VII. O N W HEN T O U SE FIDO2D 1) Online Banking: Of course, FIDO2D can be used in
online banking scenarios. For example, transactions can be
FIDO2D can improve security in several scenarios. Before
used to protect the integrity of money transfers and settings
we describe possible use cases, we present general guidelines
such as transfer limits. For money transfers, the transaction
and requirements.
details should include the recipient and the amount. Changing
limits, should include the new value of the limit. These types
A. Guidelines and Requirements
of transactions can be verified on a smartphone properly.
To adopt FIDO2D, the first step is to identify security- Even though transaction authentication is already used
critical actions that should be protected from malware attacks. in online banking, applying FIDO2D yields the following
Our scheme can be used to achieve two separate security goals. advantages. First, it encourages the user to initiate and confirm
First, the confidentiality of data stored on the server can be pro- transactions on separate devices. And second, it replaces the
tected by requiring the user to confirm requests for said data. use of passwords to access the online banking system.
However, once the user approves a request, the data is shown 2) Electronic health record: In electronic health records,
on the primary device and might be eavesdropped by malware. FIDO2D can be used to protect the confidentiality of stored
Nonetheless, malware on a single device cannot get access health information. Sensitive information would only be ac-
to data protected by transactions without the user requesting cessible for a patient after confirmation on the smartphone.
or confirming it. Furthermore, transactions can protect the The transaction data should indicate which data was requested.
integrity of data stored on the server or activities triggered by Such requests can be verified on a smartphone properly.
the server. For example, money transfers are often protected 3) Microblogging: In a microblogging service, the integrity
by transactions as they change the account balance stored on of posted messages can be protected using FIDO2D. In this
the server. Actions have to be chosen carefully, as requiring scenario, publishing a message might have a huge impact
transaction authentication for many actions can easily cause depending on the author. Messages of influential people such
authentication fatigue, drastically reducing security benefits. as the former president of the United States have been associ-
For the security of FIDO2D, it is important that transaction ated with stock market activity [39] but might also influence
details contain all necessary information about the transaction, international affairs. As messages in a microblogging service
so that the user can verify them. As FIDO2D might be used for are short (e.g., 280 characters on Twitter), they are suitable for
multiple accounts and services, the transaction details should verification on a second device. The transaction details should
always include the domain name of the service and the account include the name of the account as well as the full message
name. Furthermore, the length of the transaction details should content.
also be considered when identifying suitable actions. 4) Administration Panels: Management panels such as
Services can still provide a login mechanism and offer to Plesk6 allow users to carry out administrative tasks on remote
initiate a transaction from the authenticated session. However, servers. For example, DNS settings for registered domains can
security-critical actions chosen by the provider must be ver- be configured. Manipulating the DNS settings of a domain
ified by the user on the additional device. Of course, not all allows to eavesdrop and manipulate all traffic destined to the
users want to confirm messages individually. Thus, the use of domain [40]. Thus, protecting integrity of the DNS settings
FIDO2D should be configurable. However, disabling FIDO2D using FIDO2D is beneficial. The transaction details should
for an account must also require verification with FIDO2D. include the domain name, the record type and the value. Since
Otherwise, FIDO2D can be bypassed trivially. this information is short, it is suitable for verification on a
To be able to use FIDO2D, users need a smartphone and smartphone.
a computer that supports FIDO2 either with an integrated
platform authenticator or with a roaming authenticator. Win- VIII. R ELATED W ORK
dows 10 provides a FIDO2 platform authenticator out-of-the- We consider three types of related work: formal frameworks
box5 . Hence, many users only need to install an app on their to prove security properties of cryptographic protocols, se-
smartphone. Our app can be used for multiple web applications curity models and work that introduces web authentication
that implement our protocol. While platform authenticators are schemes. Finally, we compare the security of existing web
bound to a specific device, a roaming authenticator might also authentication schemes with FIDO2D.
be used to access an account from multiple devices.
A. Proof Frameworks
B. Use Cases Defining and proving the security of a protocol within a
FIDO2D is suited best for scenarios with security-conscious formal model is an important step during the development
users as it unfolds it full potential when users verify transaction of new security protocols. To this end, various frameworks
data properly. We introduce four use cases where FIDO2D can and models have been proposed in the past. The Universal
protect users against malware attacks. Composability (UC) Framework [41] for example is widely
used by the cryptographic community and is considered to be
5 https://fidoalliance.org/microsoft-achieves-fido2-certification-for-windo
ws-hello/ 6 https://www.plesk.com/
the most popular and most expressive framework. It is best C. Web Authentication
suited for modeling basic cryptographic primitives and simple
FIDO2 is a standard for web authentication published by the
protocols; however, modeling protocols is a manual task and
FIDO Alliance. It consists of a widely implemented browser
there is no support for automated proof checking. Lots of
API called WebAuthn [15]. This API simplifies integration
technical artifacts (like its reliance on Turing Machines for
of strong authentication mechanisms in web applications. The
modeling protocol participants) therefore make modeling com-
underlying challenge-response protocol relies on public-key
plex protocols error-prone and lead to complex security proofs
cryptography. Even though the protocol is resistant to real-
which even humans sometimes cannot verify completely.
time phishing, it does not prevent malware attacks [7].
In contrast, the Tamarin modeling framework allows ver-
ification of models in an automated fashion [34]. Tamarin- This also applies to Google’s Advanced Protection pro-
models consist of multi-set rewrite rules as well as lem- gram [47]. It restricts login attempts to FIDO tokens; how-
mas, defining protocols and security properties respectively. ever, they can still be abused by malware. Other proprietary
These constructs are expressed in a domain specific language. solutions such as Duo Push and Akamai MFA confirm login
Protocols and their security properties are verified in the attempts using push messages [48], [49]. However, they do not
symbolic model. A proof of correctness can then be obtained authenticate transactions individually and are thus susceptible
by executing the Tamarin theorem prover. A curated list of to malware using session hijacking or transaction manipulation
Tamarin-proofs for various protocols can be found on the (see Section III).
Tamarin website7 . For instance, Tamarin has been used to The CAP protocol is a transaction authentication scheme
verify all claimed security properties of a draft specification used in online banking [44]. A dedicated card reader is used
of TLS 1.3 [42]. to allow the user to verify transaction details. Even though the
CAP protocol is resilient to malware on the primary device,
B. Security Models it does not exhibit one-out-of-two security. In the unlikely
To remedy the issue of a single point of failure within a event that the card reader is compromised, the scheme can be
trusted device, Achenbach et al. [27] put forth the notion attacked by using phishing to initiate a malicious transaction
of “one-out-of-two security”. They provide a model for the (see Section III). Nonetheless, it provides a high level of
security of electronic payment protocols based on the UC security as compromise of the card reader is less likely than of
framework. Furthermore, they introduce a protocol for cash a smartphone. However, the protocol is of proprietary nature
withdrawal at an ATM with an additional device such as a and requires the user to carry an additional device, which has
smartphone, and prove that it fulfills one-out-of-two security. been shown to hinder adoption significantly [10].
Thus, the protocol is secure as long as one device is not Recent attempts to improve authentication schemes focus
compromised. While their protocol and model are specifically on banning weak schemes but do not reason about security
tailored to electronic payments and cannot be directly applied properties and requirements systematically, e.g., the European
to web authentication, our work is inspired by theirs. Commission issued the revised Payment Services Directive
Jacomme et al. introduce a formal model for multi-factor (PSD2), a regulation requiring strong customer authentication
authentication in the applied pi calculus [7]. They analyze for online banking [14]. PSD2 suggests that users have to be
the Universal Second Factor (U2F) protocol, a predecessor of made aware of the transaction details, but does not prevent
FIDO2 and Google 2-step authentication. Their threat model malware attacks, as it allows operating both factors on one
includes phishing and malware attacks, as well as fingerprint device [13]. NIST introduced security levels for authentication
spoofing to bypass RBA. Using ProVerif they identify several called Authenticator Assurance Level (AAL) [50], but does
weaknesses of the analyzed protocols. Google 2-step is suscep- not systematically consider what needs to be authenticated.
tible to phishing attacks that include fingerprint spoofing and Thus, these regulations do not solve the problems of two-factor
U2F to malware controlling an attached authenticator. They authentication schemes.
propose that these protocols should incorporate verification of Mannan and van Oorschot [45] introduce Mobile Password
transaction data, which is exactly what FIDO2D provides. Authentication (MP-Auth). The scheme is based on a trusted
Bonneau et al. [43] compare schemes proposed to replace smartphone that stores cryptographic keys. By incorporat-
passwords for web authentication regarding usability, deploy- ing public-key cryptography, the protocol achieves phishing-
ability, and security. They consider a wide range of schemes resistance. The authors use transaction authentication to
such as password managers, federated schemes, OTPs, and thwart malware attacks, yet MP-Auth is only secure if the
hardware tokens. The security of a scheme is assessed based on smartphone is not compromised. Because smartphones are
the resilience to different kinds of attacks. However, phishing multi-purpose devices that are connected to the Internet, they
and malware attacks are not considered to their full extent. are susceptible to malware as well. Similarly, Chow et al.
For example, malware is only assumed to steal credentials introduce a scheme that relies on a trusted smartphone [46].
passively but not to manipulate the browser. Furthermore, real- The smartphone is used as a OTP generator that displays the
time phishing attacks are excluded explicitly. transaction data and requires confirmation by the user.
Konoth et al. propose a solution to secure two-factor
7 https://tamarin-prover.github.io/ authentication when both factors are operated on a single
 TABLE I
S ECURITY OF TRANSACTION AUTHENTICATION SCHEMES .
XINDICATES THAT A SCHEME IS SECURE IN A GIVEN SCENARIO . × INDICATES THAT THIS IS NOT THE CASE .
B IS THE DEVICE RUNNING THE BROWSER . A IS AN ADDITIONAL DEVICE .
C OMPARE MEANS THAT THE USER VERIFIES TRANSACTION DETAILS . N O C OMPARE INDICATES THAT THIS IS NOT THE CASE .
D EVICES LISTED IN THE SECURITY ASSUMPTION OF A SCHEME MUST NOT BE COMPROMISED .

No Compare Compare
B compromised A compromised B compromised A compromised Security assumption
CAP reader [44] × × X × A
PhotoTAN [27] × × X × A
MP-Auth [45] × × X × A
Chow et al. [46] × × X × A
Secure Pay [8] × × X × TEE in A
FIDO2D × X X X A or B

smartphone [8]. Their scheme SecurePay uses OTPs and a (see Section VI), because transaction initiation is protected by
trusted user interface to verify transaction data. The authors FIDO2, which is resilient to password and phishing attacks.
formally model and verify the security of their scheme using If the user compares transaction data, all schemes protect
Tamarin [34]. By relying on a Trusted Execution Environment against malware on the primary device B. Again, FIDO2D is
(TEE), Secure Pay is resilient to malware attacks. However, the only scheme that is secure if A is compromised. Control
this is only true as long as attackers do not exploit vulnera- of device A allows an attacker to tamper with transaction veri-
bilities in the TEE implementation to escalate their privileges fication [13]. However, FIDO2D protects transaction initiation
to the secure world, which has been successfully achieved in with FIDO2 against phishing and password attacks. The other
the past [51]. Furthermore, TEE implementations have been schemes rely on password authentication (potentially including
shown to be susceptible to fault injection and side-channel RBA). As described in Section III, in this case the attacker can
attacks [52], [53]. mount a transaction initiation attack.
Similarly to our work, they identify the issue that the current Thus, FIDO2D is the only scheme that fulfills one-out-of-
way two-factor authentication is defined and used is insecure two security. For users that verify transaction data, it provides
and give guidelines on how to improve upon that. However, resistance to password, phishing, and malware attacks as long
they mainly focus on the fact that strict isolation of the two as one device is not compromised. Even if the user does not
factors is needed which, even though it works in their case, verify transaction data at all, FIDO2D is resilient to malware
in general is not sufficient to guard against malware attacks. on device A. Thus, it provides a higher level of security than
In contrast, our work gives a universally applicable guideline existing schemes regardless of whether transaction data is
for how to design secure authentication schemes, which are verified or not.
resilient against malware. In particular, our notion of one-out-
IX. C ONCLUSION AND F UTURE W ORK
of-two security does not require a special type of device and
is agnostic to how isolation is achieved. In this work, we showed how to protect security-critical
web transactions against attacks with malware. Current web
D. Security of Transaction Authentication Schemes authentication schemes do not offer this protection.
We summarize the security of web authentication schemes We identified requirements for such authentication schemes,
in Table I. We only consider schemes that support transac- namely one-out-of-two security and transaction authentication.
tion authentication, because other schemes are susceptible to Web authentication schemes that fulfill these requirements
malware attacks in any case (see Section IV). Because users protect security-critical transactions against malware attacks
might not verify transaction data properly, we differentiate as long as one device is not compromised.
two scenarios: compare and no compare (see Section VI-E). We introduced 2DA, a generic blueprint for designing web
Furthermore, we assume the attacker to either compromise B authentication schemes that fulfill one-out-of-two security.
or A. In addition, the attacker may carry out password and Based on this blueprint, we designed and implemented a
phishing attacks (see Section III). A scheme is considered new web authentication scheme called FIDO2D, which is
secure, if the attacker is not able to execute a malicious applicable to a wide range of use-cases. We proved the security
transaction. As expected, none of the considered schemes of FIDO2D using Tamarin.
provides security guarantees if both devices are compromised. By relying on protocols and APIs of the FIDO2 standard,
First, we analyze the security of the schemes when a user FIDO2D can be integrated into web applications easily. We
confirms transactions on an additional device without com- demonstrate this by creating a prototypical implementation.
paring transaction data. In this case, all considered schemes Lastly, we urge the FIDO Alliance to fully embrace one-
are vulnerable to malware on the primary device B because out-of-two security and transaction authentication as a design
the user does not detect transaction manipulation. In contrast paradigm for secure web authentication in future versions of
to other schemes, FIDO2D is secure if A is compromised their standard.
 R EFERENCES [21] m0chan, Bypassing 2FA For Fun With Evilginx2, 2019. [Online].
Available: https://m0chan.github.io/2019/07/26/Bypassing-2FA-For-F
[1] J. Aten, “Google says 66% of americans still do this 1 thing that puts un-With-Evilginx2.html
their personal information at a huge risk,” 2019. [Online]. Available: [22] M. Orru and G. Trotta, Muraena: The Unexpected Phish, 2019.
https://www.inc.com/jason-aten/google-says-66-of-americans-still-do-t [Online]. Available: https://conference.hitb.org/hitbsecconf2019ams/mat
his-1-thing-that-puts-their-personal-information-at-a-huge-risk-heres-h erials/D2T1%20-%20Muraena%20-%20The%20Unexpected%20Phish
ow-google-wants-to-help.html %20-%20Michele%20Orru%20&%20Giuseppe%20Trotta.pdf
[2] A. Das, J. Bonneau, M. Caesar, N. Borisov, and X. Wang, “The tangled [23] C. Grier, L. Ballard, J. Caballero, N. Chachra, C. J. Dietrich,
web of password reuse.” in NDSS, vol. 14, no. 2014, 2014, pp. 23–26. K. Levchenko, P. Mavrommatis, D. McCoy, A. Nappa, A. Pitsillidis
[3] I. Ion, R. Reeder, and S. Consolvo, ““... no one can hack my mind”: et al., “Manufacturing compromise: the emergence of exploit-as-a-
Comparing expert and non-expert security practices,” in Eleventh Sym- service,” in Proceedings of the 2012 ACM conference on Computer and
posium On Usable Privacy and Security (SOUPS), 2015, pp. 327–346. communications security, 2012, pp. 821–832.
[4] RSA, Making Sense of Man-in-the-browser Attacks: Threat [24] T. Nelms, R. Perdisci, M. Antonakakis, and M. Ahamad, “Towards
Analysis and Mitigation for Financial Institutions, 2010. measuring and mitigating social engineering software download attacks,”
[Online]. Available: https://viewer.media.bitpipe.com/1039183786_34/ in 25th USENIX Security Symposium (USENIX Security), 2016, pp. 773–
1295277188_16/MITB_WP_0510-RSA.pdf 789.
[5] Amnesty International, When Best Practice Isn’t Good Enough: [25] M. Stone and C. Lecigne, How we protect users from 0-day attacks,
Large Campaigns of Phishing Attacks in Middle East and 2021. [Online]. Available: https://blog.google/threat-analysis-group/how
North Africa Target Privacy-Conscious Users, 2018. [Online]. -we-protect-users-0-day-attacks/
Available: https://www.amnesty.org/en/latest/research/2018/12/when-b [26] S. Wiefling, L. Lo Iacono, and M. Dürmuth, “Is this really you? an
est-practice-is-not-good-enough/ empirical study on risk-based authentication applied in the wild,” in
IFIP International Conference on ICT Systems Security and Privacy
[6] C. Cimpanu, Chinese hacker group caught bypassing 2FA, 2019.
Protection. Springer, 2019, pp. 134–148.
[Online]. Available: https://www.zdnet.com/article/chinese-hacker-gro
up-caught-bypassing-2fa/ [27] D. Achenbach, R. Gröll, T. Hackenjos, A. Koch, B. Löwe, J. Mechler,
J. Müller-Quade, and J. Rill, “Your money or your life—modeling and
[7] C. Jacomme and S. Kremer, “An extensive formal analysis of multi-
analyzing the security of electronic payment in the uc framework,” in
factor authentication protocols,” ACM Transactions on Privacy and
International Conference on Financial Cryptography and Data Security.
Security (TOPS), vol. 24, no. 2, pp. 1–34, 2021.
Springer, 2019, pp. 243–261.
[8] R. K. Konoth, B. Fischer, W. Fokkink, E. Athanasopoulos, K. Razavi,
[28] V. Haupert and S. Gabert, “Short paper: How to attack psd2 internet
and H. Bos, “Securepay: Strengthening two-factor authentication for
banking,” in International Conference on Financial Cryptography and
arbitrary transactions,” in 2020 IEEE European Symposium on Security
Data Security. Springer, 2019, pp. 234–242.
and Privacy (EuroS&P). IEEE, 2020, pp. 569–586.
[29] R. Mayrhofer, J. V. Stoep, C. Brubaker, and N. Kralevich, “The android
[9] B. Schneier, “Two-factor authentication: too little, too late,” Communi- platform security model,” ACM Transactions on Privacy and Security
cations of the ACM, vol. 48, no. 4, p. 136, 2005. (TOPS), vol. 24, no. 3, pp. 1–35, 2021.
[10] K. Krol, E. Philippou, E. De Cristofaro, and M. A. Sasse, “"they brought [30] FIDO Alliance, Client to Authenticator Protocol (CTAP), 2021. [Online].
in the horrible key ring thing!" analysing the usability of two-factor Available: https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-cli
authentication in uk online banking,” in USEC Workshop on Usable ent-to-authenticator-protocol-v2.1-ps-20210615.pdf
Security at the Network and Distributed System Security Symposium, [31] E. Klieme, J. Wilke, N. van Dornick, and C. Meinel, “Fidonuous: A
2015. fido2/webauthn extension to support continuous web authentication,” in
[11] S. G. Lyastani, M. Schilling, M. Neumayr, M. Backes, and S. Bugiel, 2020 IEEE 19th International Conference on Trust, Security and Privacy
“Is fido2 the kingslayer of user authentication? a comparative usability in Computing and Communications (TrustCom). IEEE, 2020, pp. 1857–
study of fido2 passwordless authentication,” in 2020 IEEE Symposium 1867.
on Security and Privacy (SP). IEEE, 2020, pp. 268–285. [32] N. Mooney, N. Steele, and J. Erickson, Network Transport
[12] A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner, “A survey of Summary, 2020. [Online]. Available: https://github.com/w3c/webau
mobile malware in the wild,” in Proceedings of the 1st ACM workshop thn/files/4588654/The.Network.Transport.May.2020.pdf
on Security and privacy in smartphones and mobile devices, 2011, pp. [33] N. Frymann, D. Gardham, F. Kiefer, E. Lundberg, M. Manulis, and
3–14. D. Nilsson, “Asynchronous remote key generation: An analysis of
[13] V. Haupert and T. Müller, “On app-based matrix code authentication in yubico’s proposal for w3c webauthn,” in Proceedings of the 2020 ACM
online banking.” in ICISSP, 2018, pp. 149–160. SIGSAC Conference on Computer and Communications Security, 2020,
[14] European Commission, Commission Delegated Regulation (EU) pp. 939–954.
2018/389, 2017. [Online]. Available: https://eur-lex.europa.eu/eli/reg_d [34] S. Meier, B. Schmidt, C. Cremers, and D. Basin, “The tamarin prover
el/2018/389/oj for the symbolic analysis of security protocols,” in Computer Aided
[15] World Wide Web Consortium, Web Authentication: An API for Verification, N. Sharygina and H. Veith, Eds. Berlin, Heidelberg:
accessing Public Key Credentials Level 2, 2021. [Online]. Available: Springer Berlin Heidelberg, 2013, pp. 696–701.
https://www.w3.org/TR/webauthn-2/ [35] D. Dolev and A. Yao, “On the security of public key protocols,” IEEE
[16] K. Thomas, F. Li, A. Zand, J. Barrett, J. Ranieri, L. Invernizzi, Transactions on Information Theory, vol. 29, no. 2, pp. 198–208, 1983.
Y. Markov, O. Comanescu, V. Eranti, A. Moscicki et al., “Data breaches, [36] The Tamarin Team, Tamarin-Prover Manual, 2021. [Online]. Available:
phishing, or malware? understanding the risks of stolen credentials,” in https://tamarin-prover.github.io/manual/tex/tamarin-manual.pdf
Proceedings of the 2017 ACM SIGSAC conference on computer and [37] V. Haupert and S. Gabert, “Where to look for what you see is what you
communications security, 2017, pp. 1421–1434. sign? user confusion in transaction security,” in European Symposium
[17] S. Ikeda, Half a Million Zoom Accounts Compromised by on Research in Computer Security. Springer, 2019, pp. 429–449.
Credential Stuffing, Sold on Dark Web, 2020. [Online]. Avail- [38] D. Basin, S. Radomirovic, and L. Schmid, “Modeling human errors in
able: https://www.cpomagazine.com/cyber-security/half-a-million-zoo security protocols,” in 2016 IEEE 29th Computer Security Foundations
m-accounts-compromised-by-credential-stuffing-sold-on-dark-web/ Symposium (CSF). IEEE, 2016, pp. 325–340.
[18] T. Hunt, “Password reuse, credential stuffing and another billion records [39] P. Gjerstad, P. F. Meyn, P. Molnár, and T. D. Næss, “Do president trump’s
in have i been pwned,” troyhunt.com, 2017. tweets affect financial markets?” Decision Support Systems, p. 113577,
[19] S. Wiefling, M. Dürmuth, and L. L. Iacono, “What’s in score for web- 2021.
site users: A data-driven long-term study on risk-based authentication [40] M. Hirani, S. Jones, and B. Read, Global DNS Hijacking
characteristics,” in International Conference on Financial Cryptography Campaign: DNS Record Manipulation at Scale, 2019. [Online].
and Data Security. Springer, 2021, pp. 361–381. Available: https://www.mandiant.com/resources/global-dns-hijacking-c
[20] M. Campobasso and L. Allodi, “Impersonation-as-a-service: Charac- ampaign-dns-record-manipulation-at-scale
terizing the emerging criminal infrastructure for user impersonation [41] R. Canetti, “Universally composable security: a new paradigm for
at scale,” in Proceedings of the 2020 ACM SIGSAC Conference on cryptographic protocols,” in Proceedings 42nd IEEE Symposium on
Computer and Communications Security, 2020, pp. 1665–1680. Foundations of Computer Science, 2001, pp. 136–145.
[42] C. Cremers, M. Horvat, J. Hoyland, S. Scott, and T. van der Merwe, “A
comprehensive symbolic analysis of tls 1.3,” in Proceedings of the 2017
ACM SIGSAC Conference on Computer and Communications Security,
2017, pp. 1773–1788.
[43] J. Bonneau, C. Herley, P. C. Van Oorschot, and F. Stajano, “The quest
to replace passwords: A framework for comparative evaluation of web
authentication schemes,” in 2012 IEEE Symposium on Security and
Privacy. IEEE, 2012, pp. 553–567.
[44] S. Drimer, S. J. Murdoch, and R. Anderson, “Optimised to fail: Card
readers for online banking,” in International Conference on Financial
Cryptography and Data Security. Springer, 2009, pp. 184–200.
[45] M. Mannan and P. C. Van Oorschot, “Leveraging personal devices for
stronger password authentication from untrusted computers,” Journal of
Computer Security, vol. 19, no. 4, pp. 703–750, 2011.
[46] Y.-W. Chow, W. Susilo, G. Yang, M. H. Au, and C. Wang, “Authentica-
tion and transaction verification using qr codes with a mobile device,”
in International Conference on Security, Privacy and Anonymity in
Computation, Communication and Storage. Springer, 2016, pp. 437–
451.
[47] Google, Google’s strongest security helps keep your private information
safe., 2021. [Online]. Available: https://landing.google.com/advancedp
rotection/
[48] A. Grinman, The Future of Krypton Is Here and It’s Called Akamai
MFA, 2021. [Online]. Available: https://krypt.co/blog/announcements/kr
ypton-is-now-akamai-mfa.html
[49] Duo, One-Tap Authentication With Duo Push, 2021. [Online].
Available: https://duo.com/product/multi-factor-authentication-mfa/aut
hentication-methods/duo-push
[50] P. A. Grassi, J. L. Fenton, E. Newton, R. Perlner, A. Regenscheid,
W. Burr, J. Richer, N. Lefkovitz, J. Danker, Y.-Y. Choong et al., NIST
special publication 800-63b: digital identity guidelines (Authentication
and Lifecycle Management), 2017. [Online]. Available: https://nvlpubs.
nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
[51] D. Cerdeira, N. Santos, P. Fonseca, and S. Pinto, “Sok: Understanding
the prevailing security vulnerabilities in trustzone-assisted tee systems,”
in 2020 IEEE Symposium on Security and Privacy (SP). IEEE, 2020,
pp. 1416–1432.
[52] K. Ryan, “Hardware-backed heist: extracting ecdsa keys from qual-
comm’s trustzone,” in Proceedings of the 2019 ACM SIGSAC Confer-
ence on Computer and Communications Security, 2019, pp. 181–194.
[53] P. Qui, D. Wang, Y. Lyu, and G. Qu, “Voltjockey: Abusing the processor
voltage to break arm trustzone,” GetMobile: Mobile Computing and
Communications, vol. 24, no. 2, pp. 30–33, 2020.
 A PPENDIX
TAMARIN M ODEL FOR FIDO2D
Our Tamarin model including the security lemmas can be found below. For brevity, we omitted sanity lemmas, as well as
the variations of the model for users that do no compare transaction data. However, the full Tamarin model is available online8 .
1 theory fido2d
2 begin
3 builtins : signing
4
5 rule new_server :
6 [ ]
7 −− [ H o n e s t S e r v e r ( $S ) ] −>
8 [ ! H o n e s t ( $S ) ]
9
10 rule r e g i s t e r _ f i r s t _ d e v i c e :
11 [ Fr (~ p r i v k e y ) ]
12 −− [ ] −>
13 [
14 ! Ltk_Dev1 ( $I , $S , ~ p r i v k e y ) ,
15 ! Pk_Dev1 ( $I , $S , pk ( ~ p r i v k e y ) ) ,
16 R e g i s t e r e d P a r t i a l l y ( $I , $S ) ,
17 Out ( < $I , pk ( ~ p r i v k e y ) >)
18 ]
19
20 rule register_second_device :
21 [
22 Fr (~ p r i v k e y ) ,
23 RegisteredPartially ( I , S)
24 ]
25 −− [ A c c o u n t R e g i s t e r e d ( I , S ) ] −>
26 [
27 ! Ltk_Dev2 ( I , S , ~ p r i v k e y ) ,
28 ! Pk_Dev2 ( I , S , pk ( ~ p r i v k e y ) ) ,
29 ! Registered ( I , S) ,
30 Out ( < I , pk ( ~ p r i v k e y ) >)
31 ]
32
33
34 rule i n i t _ t r a n s a c t i o n :
35 [
36 ! Registered ( I , S) ,
37 ! Honest ( S )
38 ]
39 −− [ T r a n s a c t i o n B e g i n ( I , S , $d ) ] −>
40 [
41 U s e r W a i t F o r C o n f i r m a t i o n ( I , S , $d ) ,
42 Dev1WaitForNonce ( I , S , $d ) ,
43 Out ( < I , S , $d > )
44 ]
45
46 rule r e c e i v e _ t r a n s a c t i o n :
47 [
48 ! Registered ( I , S) ,
49 ! Honest ( S ) ,
50 In ( < I , S , d >) ,
51 Fr (~ nonce )
52 ]
53 −− [ T r a n s a c t i o n R e c e i v e d ( I , S , d ) ] −>
54 [
55 S e r v e r W a i t F o r S i g n a t u r e ( I , S , d , ~nonce ) ,
56 Out_A ( S , I , < I , d , ~ nonce > )
57 ]
58
59 rule phish_transaction :

8 https://tinyurl.com/2022-fido2d-tamarin
 60 [
61 ! Registered ( I , S) ,
62 In (P)
63 ]
64 −− [ T r a n s a c t i o n B e g i n ( I , S , $d ) , P h i s h e r ( P ) ] −>
65 [
66 U s e r W a i t F o r C o n f i r m a t i o n ( I , S , $d ) ,
67 Dev1WaitForNonce ( I , P , $d ) ,
68 Phished ( I , S , P)
69 ]
70
71 rule r e c e i v e _ t r a n s a c t i o n _ p h i s h e r :
72 [
73 I n ( < d , nonce > ) ,
74 Phished ( I , S , P)
75 ]
76 −− [ ] −>
77 [
78 Out_A ( P , I , < I , d , nonce > )
79 ]
80
81 rule sign_nonce :
82 [
83 Dev1WaitForNonce ( I , S , d ) ,
84 In_A ( S , I , < I , d , nonce > ) ,
85 ! Ltk_Dev1 ( I , S , p r i v k e y )
86 ]
87 −− [ N o n c e S i g n e d ( I , S , n o n c e ) ] −>
88 [
89 Out ( s i g n ( <S , nonce > , p r i v k e y ) )
90 ]
91
92 rule v e r i f y _ s i g n a t u r e :
93 [
94 In ( s i g n a t u r e ) ,
95 S e r v e r W a i t F o r S i g n a t u r e ( I , S , d , nonce ) ,
96 ! Pk_Dev1 ( I , S , pubkey ) ,
97 Fr (~ nonce2 )
98 ]
99 −− [ Eq ( v e r i f y ( s i g n a t u r e , <S , nonce > , pubkey ) , t r u e ) , S i g n a t u r e V e r i f i e d D e v 1 ( I , S , d ) ] −>
100 [
101 S e r v e r W a i t F o r S e c o n d S i g n a t u r e ( I , S , d , ~nonce2 ) ,
102 Out_A ( S , I , <S , I , d , ~ nonce2 > )
103 ]
104
105 rule sign_second_nonce :
106 [
107 UserWaitForConfirmation ( I , S , d ) ,
108 In_A ( S , I , <S , I , d , nonce > ) ,
109 ! Ltk_Dev2 ( I , S , p r i v k e y )
110 ]
111 −− [ D i s p l a y D a t a ( I , S , d ) , N o n c e S i g n e d ( I , S , n o n c e ) ] −>
112 [
113 Out ( s i g n ( <S , d , nonce > , p r i v k e y ) )
114 ]
115
116 rule verify_second_signature :
117 [
118 In ( s i g n a t u r e ) ,
119 S e r v e r W a i t F o r S e c o n d S i g n a t u r e ( I , S , d , nonce ) ,
120 ! Pk_Dev2 ( I , S , pubkey )
121 ]
122 −− [ Eq ( v e r i f y ( s i g n a t u r e , <S , d , nonce > , pubkey ) , t r u e ) , T r a n s a c t i o n C o m p l e t e ( I , S , d ) ] −>
123 [
124 ]
125
126 rule compromise_first_device :
127 [
128 ! Ltk_Dev1 ( I , S , p r i v k e y )
129 ]
130 −− [ CompromiseDev1 ( I , S ) ] −>
131 [
132 Out ( p r i v k e y )
133 ]
134
135 rule compromise_second_device :
136 [
137 ! Ltk_Dev2 ( I , S , p r i v k e y )
138 ]
139 −− [ CompromiseDev2 ( I , S ) ] −>
140 [
141 Out ( p r i v k e y )
142 ]
143
144 / / A u t h e n t i c C h a n n e l R u l e s f r o m Tamarin Manual
145 r u l e ChanOut_A :
146 [
147 Out_A (A, B , x )
148 ]
149 −− [ ChanOut_A (A, B , x ) ] −>
150 [
151 ! Auth (A, x ) ,
152 Out ( <A, B , x > )
153 ]
154
155 r u l e ChanIn_A :
156 [
157 ! Auth (A, x ) ,
158 I n (B)
159 ]
160 −− [ ChanIn_A (A, B , x ) ] −>
161 [
162 In_A (A, B , x )
163 ]
164
165 restriction Equality :
166 " A l l x y # i . Eq ( x , y ) @i ==> x = y "
167
168 r e s t r i c t i o n HonestServersDontPhish :
169 " A l l s e r v e r # i # j . H o n e s t S e r v e r ( s e r v e r ) @i & P h i s h e r ( s e r v e r ) @j ==> F "
170
171 / / T h i s r e s t r i c t i o n i s n o t r e q u i r e d f o r s e c u r i t y b u t s i m p l i f i e s p r o o f s and c o u n t e r e x a m p l e s
172 r e s t r i c t i o n UniqueAccounts :
173 " A l l a c c s e r v e r # i # j . A c c o u n t R e g i s t e r e d ( acc , s e r v e r ) @i & A c c o u n t R e g i s t e r e d ( acc ,
s e r v e r ) @j ==> # i = # j "
174
175 lemma o n l y _ u s e r _ i n i t i a t e d _ t r a n s a c t i o n s _ a c c e p t e d :
176 " All i n i t i a t o r t r a n s a c t i o n server # i . TransactionComplete ( i n i t i a t o r , server ,
t r a n s a c t i o n ) @i ==> ( ( Ex # j .
177 T r a n s a c t i o n B e g i n ( i n i t i a t o r , s e r v e r , t r a n s a c t i o n ) @j ) | ( Ex #k # l .
CompromiseDev1 ( i n i t i a t o r , s e r v e r ) @k & CompromiseDev2 ( i n i t i a t o r , s e r v e r ) @l
))"
178
179 lemma r e p l a y _ a t t a c k _ i m p o s s i b l e :
180 " All i n i t i a t o r 1 t r a n s a c t i o n 1 i n i t i a t o r 2 t r a n s a c t i o n 2 server # i # j . TransactionComplete (
i n i t i a t o r 1 , s e r v e r , t r a n s a c t i o n 1 ) @i & T r a n s a c t i o n C o m p l e t e ( i n i t i a t o r 2 , s e r v e r ,
t r a n s a c t i o n 2 ) @j & n o t # i = # j ==> ( ( Ex #k # l . T r a n s a c t i o n B e g i n ( i n i t i a t o r 1 , s e r v e r ,
t r a n s a c t i o n 1 ) @k & T r a n s a c t i o n B e g i n ( i n i t i a t o r 2 , s e r v e r , t r a n s a c t i o n 2 ) @l & n o t # k
= # l ) | ( Ex #m #n . CompromiseDev1 ( i n i t i a t o r 1 , s e r v e r ) @m & CompromiseDev2 (
i n i t i a t o r 1 , s e r v e r ) @n) | ( Ex #m #n . CompromiseDev1 ( i n i t i a t o r 2 , s e r v e r ) @m &
CompromiseDev2 ( i n i t i a t o r 2 , s e r v e r ) @n) ) "
181
182 end