2018 IEEE 31st Computer Security Foundations Symposium

An extensive formal analysis of multi-factor authentication protocols

Charlie Jacomme Steve Kremer

LSV & CNRS & ENS Paris-Saclay LORIA, Inria Nancy-Grand Est
& Inria & Université Paris-Saclay & CNRS & Université de Lorraine

Abstract—Passwords are still the most widespread means for characters does not solve these problems, and the latest
authenticating users, even though they have been shown to recommendations by NIST [3] even discourage this practice.
create huge security problems. This motivated the use of To palliate password weaknesses, multi-factor authen-
additional authentication mechanisms used in so-called multi- tication protocols combine several authentication factors.
factor authentication protocols. In this paper we define a Typically, instead of using only a login and password, the
detailed threat model for this kind of protocols: while in user proves possession of an additional device, such as his
classical protocol analysis attackers control the communication mobile phone, or a dedicated authentication token. Two
network, we take into account that many communications popular protocols are Google 2-step [4] (which actually
are performed over TLS channels, that computers may be regroups several mechanisms) and FIDO’s U2F [5], which
infected by different kinds of malwares, that attackers could is supported by many websites, including Google, Facebook,
perform phishing, and that humans may omit some actions. and GitHub. In (one version of) Google 2-step, the user
We formalize this model in the applied pi calculus and perform receives a verification code on his phone that he must copy
an extensive analysis and comparison of several widely used onto his computer, while FIDO’s U2F requires the use of a
protocols — variants of Google 2-step and FIDO’s U2F. The specific USB token that must be plugged into the computer.
analysis is completely automated, generating systematically all
combinations of threat scenarios for each of the protocols and Our contributions. In classical protocol analysis, the at-
using the P ROVERIF tool for automated protocol analysis. Our tacker is supposed to control the communication network.
analysis highlights weaknesses and strengths of the different However, the protocols we study in this paper make exten-
protocols, and allows us to suggest several small modifications sive use of TLS communications and are supposed to pro-
of the existing protocols which are easy to implement, yet vide security even if some devices are infected by malware.
improve their security in several threat scenarios. We therefore propose a detailed threat model for multi-
factor authentication protocols which takes into account
many additional threats.
1. Introduction
• Compromised passwords: our basic assumption is that
Users need to authenticate to an increasing number of the user’s password has been compromised. Otherwise
electronic services in everyday life: emails, agenda, bank multi-factor authentication would not be required.
accounts, e-commerce sites, etc. Authentication generally re- • Network control: we define a high-level model of TLS
quires a user to present an authenticator, that is “something channels that guarantees confidentiality and authenti-
the claimant possesses and controls (typically a crypto- cation of messages and additionally ensures, through
graphic module or password) that is used to authenticate the inclusion of session ids, that messages of different TLS
claimant’s identity” [1]. Authenticators are often classified sessions cannot be mixed. Nevertheless, we allow the
according to their authentication factor: attacker to delay or block messages. Our model also
contains a notion of fingerprint that is used in some
• what you know, e.g. a password, or a pin code;
protocols to identify machines, and we may give the
• what you have, e.g. an access card or physical token;
adversary the power to spoof such fingerprints.
• what you are, e.g. a biometric measurement.
• Compromised platforms: we give a structured and fine-
Although these different mechanisms exist, passwords are grained model for malwares. We take an abstract view
still by far the most widely used mechanism, despite the fact of a system as a set of input and output interfaces,
that many problems with passwords were already identified on which an adversary may have read or write access,
in the late ’70s when they were mainly used to grant login depending on the particular malware.
into a computer [2]. Since then, things have become worse: • Human aspects: we take into account that most of these
many people choose the same weak passwords for many protocols require some interaction with the human user.
purposes, and large password databases have been leaked. We model that humans may not correctly perform these
Studies have shown that the requirement to add special steps. Moreover, we model that a human may be victim

© 2018, Charlie Jacomme. Under license to IEEE. 1

DOI 10.1109/CSF.2018.00008

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
 of phishing, or pharming, and hence willing to connect USER C OMPUTER M OBILE S ERVER
to and enter his credentials on a malicious website.
• Trust this computer mechanism: to increase usability,
login, pwd
several websites, including Google and Facebook, offer login, pwd
the possibility to trust a given machine, so that the
use of a second factor becomes unnecessary on these new code
code
machines. We add this trust mechanism to our model. code
We model these threat scenarios in the applied pi calcu- code
code
lus and use the P ROVERIF tool to analyse several variants of
the Google 2-step and FIDO’s U2F protocols. The analysis
is completely automated, generating systematically all com- Figure 1: G 2V protocol
binations of threat scenarios for each of the protocols and
using the P ROVERIF tool for automated protocol analysis.
2.1. Google 2-step
Even though we eliminate threat scenarios as soon as results
are implied by weaker scenarios, the analysis required over
6 000 calls to P ROVERIF. Our analysis results in a detailed To improve security of user logins, Google proposes a
comparison of the protocols which highlights their respec- two factor authentication mechanism called Google 2-step
tive weaknesses and strengths. It also allows us to suggest [4]. If enabled, a user may use his phone to confirm the
several small modifications of the existing protocols which login. On their website Google recalls several reasons why
are easy to implement, yet improve their security in several password-only authentication is not sufficient and states that
threat scenarios. In particular, the existing mechanisms do “2-Step Verification can help keep bad guys out, even if they
not authenticate the action that is performed, e.g., a simple have your password”.
login may be substituted by a login enabling the trust this Google 2-step proposes several variants. The default
computer mechanism, or a password reset. mechanism sends to the user, by SMS, a verification code
to be entered into his computer. An alternative is the “One-
Tap” version, where the user simply presses a Yes button
Related work. Bonneau et al. [6] propose a detailed frame- in a pop up on his phone. The second version avoids to
work to classify and compare web authentication protocols. copy a code and is expected to improve the usability of
They use it for an extensive analysis and compare many the mechanism. This raises an interesting question about the
solutions for authentication. While the scope of their work trade-off between security and ease of use. We also present a
is much broader, taking into account more protocols, as well newer version of “One-Tap” that we dubbed “Double-Tap”.
as usability issues, our security analysis of a more specific
set of protocols is more fine-grained. Moreover, our security
2.1.1. Google 2-step with verification codes - G 2V.
analysis is grounded in a formal model using automated
In Figure 1 we depict the different steps of the protocol.
analysis techniques.
All communications between the user’s computer and the
Some other attempts to automatically analyse multi-
server are protected by TLS. The user enters his login and
factor authentication protocols were made, including for
password into his computer, which forwards the information
instance the analysis of FIDO’s U2F [7], the Yubikey One
to the server. Upon receiving login and password, the server
Time Password [8], [9] and the Secure Call Authorization
checks them. In case of success, the server generates a fresh
protocols [10]. However, those analyses do not study re-
6 digits code, and sends an SMS of the form "G-****** is
sistance to malware, nor do they capture precisely TLS
your Google verification code" to the user’s mobile phone.
channel behaviour or fingerprints. Basin et al. [11] studied
The user then copies the code to his computer, which sends it
how human errors could decrease security. Their model is
to the server. If the correct code is received login is granted.
more evolved than ours on this aspect. However, we consider
more elaborate malwares and also check for a stronger
authentication property: an attack where both a honest user 2.1.2. Google 2-step with One-Tap - G 2OT. In Figure 2 we
and an attacker try to log into the honest user’s account but present the One-Tap version of Google 2-step. The protocol
only the attacker succeeds is not captured in [11], as they starts as the verification code variant with the transmission
simply check that every successful login was proceeded by of the login credentials to the server. The server then creates
an attempt from the corresponding user to login. In the same a fresh random token that is sent to the user’s mobile phone.
vein, [12] studies minimal topologies to establish secure Unlike in the previous version, the communication between
channels between humans and servers. the server and the phone is over a TLS channel rather
than by SMS. The phone displays a pop up to the user
who can then confirm the action or abort it, by choosing
2. Multi-factor authentication protocols “Yes” or “No” respectively. In case of confirmation the
phone returns the token and login is granted. Note that
In this section we briefly present the two, widely used, in its most basic version, the user only answers a yes/no
multi-factor authentication protocols that we study in this question. Google announced in February 2017 [13] that the
paper: (several variants of) Google 2-step and FIDO’s U2F. pop up would also contain in the future a fingerprint of the

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
USER C OMPUTER M OBILE S ERVER USER T OKEN C OMPUTER S ERVER

login, pwd login, pwd

login, pwd login, pwd

new token new chall

token chall
yes or no?
yes chall, origin, sid
token press?
press
Figure 2: G 2OT protocol signature
signature

computer, including information such as IP address, location Figure 3: U2F protocol

and computer model. However this new version has yet to
be implemented on some of the smartphones we used for
tests. In the following we will analyse both versions, with pressing the token button. The signature is then forwarded
(G 2OTfpr ) and without (G 2OT) the fingerprint. to the server for verification.

2.1.3. Google 2-step with Double-Tap - G 2DTfpr . The 2.3. Disabling the second factor on trusted devices
issue with One-Tap compared to the code version is that
the user is likely to simply press “Yes” without reading When designing an authentication protocol, as also em-
any displayed information. To mitigate this issue, Google phasized in [6], a key requirement should be usability. On a
sometimes uses a version which we call Double-Tap. It is user’s main computer, used on a daily basis, it may not be
not documented, but we saw it at work in practice. The first necessary to use a second factor: for instance, using a second
step is the One-Tap protocol previously presented, with the factor each time a user pops his emails on his main laptop
display of the fingerprint. It is then followed by a second would be very cumbersome. This is why several providers,
step, where a two digit number is displayed on the user’s including Google and Facebook, propose to trust specific
computer screen, and the same number is displayed on the computers and disable the second factor authentication on
user phone along two other random numbers. The user is these particular machines. This is done by checking a “Trust
then asked to select on his phone the number displayed on this computer” option when initiating a two-factor authen-
his computer. This mimics the behaviour of a verification ticated login. Technically, the computer will be identified
code displayed on the computer and that the user should by a cookie and its fingerprint. A fingerprint typically
enter on his phone, but with the benefits of greater simplicity includes information about the user’s IP address, inferred
and ease of use. location, OS or browsers version, etc. As these elements will
obviously change over time, in practice, a distance between
2.2. FIDO’s Universal 2nd Factor - U2F fingerprints is evaluated, and if the fingerprint is too far from
the expected one, the second factor authentication will be
FIDO is an alliance which aims at providing standards required. To the best of our knowledge, this feature is not
for secure authentication. Among their proposed solutions documented and the full mechanism has not been studied
is the Universal 2nd Factor (U2F) protocol [5]. We here previously even though it may lead to security issues. To
concentrate on the version using a USB token as the second capture such security issues we will include the “Trust this
factor. The U2F protocol relies on a token able to securely computer” mechanism in our analysis.
generate and store secret and public keys, and perform
cryptographic operations using these keys. Moreover, the 3. Threat model
token has a button that a user must press to confirm a
transaction. To enable second-factor authentication for a In order to conduct an in depth analysis of multi-factor
website, the token generates a key pair and the public key is authentication protocols, we consider different threat mod-
registered on the server. This operation is performed once, els, types of attacks and corresponding attacker capabilities.
and the token can then be used for authenticating; the steps We will consider a Dolev-Yao attacker [14] that controls any
of the authentication protocol are presented in Figure 3. compromised parts and, classically, the network. However,
First, the computer forwards the user’s login and password many of the protocols we study use channels protected
to the server. Then, the server generates a challenge which by TLS. The attacker may block a message, even if he
is sent to the user’s computer. Upon reception, the browser cannot read or write on such channels. Moreover, as we
generates a payload containing the url of the server, the are studying multi-factor authentication protocols, in order
challenge and the identifier of the current TLS session to be to assess additional protection offered by these protocols, we
signed by the token. The user confirms the transaction by are interested in the case where the user’s password has been

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
compromised. Therefore, the most basic threat scenario we access implies having read access. This yields for each
consider is the one where the attacker has (partial) control interface 5 levels, that can be organized as a lattice depicted
over the network, and knows the users’ passwords. in Figure 4.
There are however several ways the attacker can gain
more power. Our aim is to present a detailed threat model, 3.1.2. Malware on a computer. For a computer, we will
reflecting different attacker levels that may have more or less consider three interfaces:
control over the user’s computer, the network, or even over • the USB interface, capturing for instance the keyboard,
the user itself. Those levels aim at capturing the attacker or a U2F USB key, with all possible types of access;
capabilities that are necessary for a given attack. • the display, the computer screen, with only outputs
interfaces;
• the TLS interface, capturing the network communica-
3.1. Malware based scenarios tions, but by always assuming that the attacker as the
same level of control over inputs and outputs.
The first range of scenarios covers malwares that give
We can succinctly describe a malware on a computer by
an attacker control over parts of a user’s device.
giving for each interface inputs and output the attacker
access, and we will the use the notation : Minterface
in:acc1,out:acc2 ,
3.1.1. Systems as interfaces. To give a principled model of where interface might be tls, usb or dis, and acc1 and acc2
malwares and what parts of a system a malware may control, might be RO or RW .
we take an abstract view of a system as a set of interfaces on By convention, if we do not specify any access level,
which the system receives inputs and sends outputs. Some it means that the attacker has no access. A key logger is
interfaces may only be used for inputs, while other interfaces for instance denoted with Musb in:RO . If the access level is
may be used for outputs, or both. For example the keyboard the same both for the inputs and the outputs, as we always
is an input interface, the display is an output interface, and assume for TLS, we may write Mtls io:RW , thus capturing
the network is an input and output interface. Compromise the fact that the attacker may have full control over the user
of part of the system can then be formalized by giving an browser, or that he might have exploited a TLS vulnerability.
attacker read or write access to a given interface. On a secure
system, the attacker has neither read nor write access on 3.1.3. Malware on a phone. For a mobile phone, the type
any interface. Conversely, on a fully compromised system of interface may vary from protocols, with for instance SMS
the attacker has read-write access on all interfaces. inputs or TLS inputs. To simplify, we will only consider a
More formally we consider that for each interface the phone to have one input and one output interface. We thus
attacker may have only consider a generic device interface called dev , with all
• no access (NA), possible access level. Mdev
in:RO then corresponds for instance
• read-only access (RO), to the attacker having broken the SMS encryption, or to
• write-only access (WO), or some malware on the phone listening to inputs.
• read-write access (RW).
We may specify many different levels of malware by spec- 3.2. Fingerprint Spoofing
ifying for every interface two access levels, one for in- Whenever a user browses the Internet, he provides infor-
puts and one for outputs on the interface. Obviously, for mation about himself, called his fingerprint. Those elements
a given interface not all combinations need to be con- will be very useful later on for additional checks in our
sidered: a read-write access will yield a stronger threat protocols, and as we mentioned Google is adding this kind
model than read-only access, write-only or no access. of details to their One-Tap protocol. However, in some cases
We will suppose in this paper that the attacker might be able to obtain the same fingerprint as
it is harder to control the outputs of Out RW a given user. While some elements, such as the OS version,
an interface than its inputs: therefore are rather easy to spoof, it is more complicated to spoof the
a given access level to the outputs IP address and inferred location. It is nevertheless possible
will imply the same access level on In RW Out RO
if an attacker either completely controls the network the user
the interface inputs. Although not a connects on, or because he is connected to the same Wifi,
limitation of our model, this choice In RO or works in the same office.
is motivated by practical considera-
tions. Running for instance a keylog- 3.3. Human errors
ger does not require specific rights, NA
because the keyboard data is com- Figure 4: Access The attacker may also exploit vulnerabilities that rely
pletely unprotected in the OS. FIDO on the user not or wrongly performing some actions, or
devices are identified by the OS as a keyboard (at least on preferring to ignore security warnings. The assumption that
linux). However, reading data sent by an application to some users may not behave in the expected way seems reasonable
USB device, may require to corrupt the driver (or in the given that most users are not trained in computer security,
case of linux enable the "usbmon" module) which requires and their goal is generally to access a service rather than
specific privileges. Similarly, we suppose that having write performing security related actions.

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
3.3.1. Phishing. In our model, we capture that users may be Our different scenarios, provide a high level of gran-
victim of phishing attempts, i.e. willing to authenticate on ularity going from no attacker power at all to complete
a malicious website. For instance, an untrained, naive user control over both the network and the platforms. Our threat
may be willing to click on a link in an email which redirects model abstracts how the attacker gained this power. Thus,
to a fake web site. While a phishing attack through an e- the scenarios we consider will contain at some point all the
mail may not fool a trained user, even an experienced user possible attacks, without the need to specify how they may
may be a victim, for instance if he connects to an attacker be performed. For instance, a side channel attack such as
Wifi hotspot which asks to login to a website in order to Meltdown [15] or Spectre [16] may allow the attacker to
obtain free Wifi. Therefore, when we consider the phishing read the memory of the user computer: this is captured by
threat scenario we allow the attacker to choose with whom giving read-only access to all the interfaces of the computer
the user will initiate the protocol. We consider phishing as (Musb
in:RO Min:RO Min:RO ). Another example is pharming,
tls dis

one of the simplest attacks to mount, and protocols should where the attacker can “lie” about the url that is displayed to
effectively protect users against it. the user. This may happen either because of a malware that
However, even though we consider that users might be edits the hosts file (on a UNIX system), or by performing
victim of phishing, we suppose that they are careful enough DNS ID Spoofing or DNS Cache Poisoning. All of these
to avoid it when performing the most sensitive operations: scenarios are simply captured as Mtls io:RW .
these operations include the registration of the U2F key,
and logging for the first time on a computer they wish to 4. The formal model
trust later on. Indeed, if we were to allow phishing to be
performed during those steps, no security guarantees could
ever be achieved as the use of a second factor authentication For our formal analysis, we model protocols in a dialect
requires a trusted setup. of the applied pi calculus [17], [18] that is used as input
language by the P ROVERIF tool [19] which we use to
automate the analysis. We will only give a brief, informal
3.3.2. No compare. A protocol may submit to the user a fin- overview here, which should be sufficient to explain our
gerprint and expect him to continue the protocol only if the modelling of TLS sessions and threat scenarios. We refer
fingerprint corresponds to his own. When given a fingerprint the reader to [19] for additional details about the formal
and a confirmation button, some users may confirm without semantics.
reading the displayed information. Thus, when considering
the no compare scenario, we assume that the user does not
compare any value given to him and always answers yes. 4.1. The applied-pi calculus and P ROVERIF

In the applied pi-calculus, protocols are modelled as

3.4. Threat scenarios considered concurrent processes that communicate messages built from
a typed term algebra. The attacker controls the execution
In our analysis we consider all the possible combinations of the processes and can make computations over known
of the previously presented scenarios. This yields a fine- terms. The grammar is given in Figure 5.
grained threat model allowing for a detailed comparison of Atomic terms are either names a, b, c, n, . . ., or variables
the different protocols, allowing us to identify the strengths x, y, z, . . ., each declared with a type. Pre-defined types
and weaknesses of each protocol, by showing which threats include channel, bool and bitstring, but a user may define
are mitigated by which mechanisms. additional types. We note that the type system is only a
By considering those possibilities, we capture many real convenient way to avoid errors in the specification; it does
life scenarios. For instance, when connecting to a Wifi not limit the attacker, and types are basically ignored in the
hotspot in an hotel or a train station, the Wifi might be semantics. We suppose a set of function symbols, split into
controlled by the attacker, and we would have fingerprint constructors and destructors. Each function symbol has an
spoof and phishing, because the attacker can have full con- arity, defining the number and types of the arguments, as
trol over the network, and thus use the provided IP address well as the type of the resulting term. Terms are built by
or redirect a user to a fake website. applying constructors to other terms. Destructors are defined
If we try to connect on some untrusted computer, for by one or several rewriting rules and model the properties
instance the computer of a coworker, it may contain a of function symbols. For example, we can model digital
rather basic malware, for instance a keylogger (Musb in:RO ). signatures as follows. Suppose that pkey and skey are
However, if we connect on a computer shared by many user defined types, modelling public and secret keys. Then
people at some place, for instance at a cybercaffé, there we can define the function constructors
could be a very strong malware controlling the display of
the computer (Mdisout:RW ) or controlling any TLS connection pk(skey) : pkey and sign(bitstring, skey) : bitstring
on this computer (Mtls io:rw ). Moreover, the network in this
unknown place might also be compromised, and we may as well as the destructor checksign by the following rewrite
have some other scenarios combined with the malware, such rule
as phishing (PH) or fingerprint spoofing (FS). checksign(sign(m, k), pk(k)) → m

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
While constructors are used to build terms, application of twice the event Accept(rnd) (for the same value rnd) while
destructors generalizes terms to expressions. Expressions this session was only initiated once. To capture such replay
may fail when a destructor is applied and the expression can- attack we may use injective correspondence properties
not reduce to a term by applying the rewrite rules defining
the destructors. Additionally, one may declare equations on e1 (t1 , . . . , tn ) =⇒inj e2 (u1 , . . . , um )
terms, which define a congruence relation on terms that are that require that any occurrence of e1 is matched by a
considered equal. Hence, an alternative way of specifying different preceding occurrence of e2 .
digital signatures would be to declare checksign as a
constructor together with the equation 4.2. Modelling TLS communications
checksign(sign(m, k), pk(k)) = m
Most web protocols rely on TLS to ensure the secrecy
In contrast to the previous modelling, checksign(t1 , t2 ) is of the data exchanged between a client and a server. In
a valid term for any t1 , t2 and the evaluation of this term order to formally analyse online authentication protocols, we
will not fail. Moreover, one can define private names and thus need to model TLS sessions and corresponding attacker
function symbols that may not be used by the attacker. capabilities. A possibility would of course be to precisely
The protocols themselves are modelled by processes. 0 is model the actual TLS protocol and use this model in our
the terminal process that does nothing. P | Q runs processes protocol analysis. This would however yield an extremely
P and Q in parallel, and !P allows to spawn an unbounded complex model, which would be difficult to analyse. There-
number of copies of P to be run in parallel. new n : T fore, for this paper, we opt to model TLS at a higher level
declares a fresh name of type T ; this construct is useful of abstraction.
to generate fresh, secret keys and nonces. in(M, x : T ) In essence we model that TLS provides
inputs a term that will be bound to a variable of type T on • confidentiality of the communications between the
channel M and out(M, N ) outputs the term N on channel client and the server, unless one of them has been
M . If the channel name is known to (or can be computed compromised by the adversary;
by) the adversary, the channel is under the adversary’s • a session identifier that links all messages of a given
control: any input message may come from the adversary, session, avoiding mixing messages between different
and any output is added to the adversary’s knowledge. On sessions.
the contrary, if the channel is private, then the adversary can
neither read from nor write on this channel. The conditional We model this in the applied pi calculus as follows:
if E1 = E2 then P else Q checks whether two expressions • we define a private function tls(id, id) : channel
successfully evaluate to equal terms and executes P , or Q if where id is a user defined type of identities, and use the
at least one of the expressions failed or the two expressions channel tls(c, s) for communications between client c
yield different terms. Finally processes can be annotated by and server s;
an event e(M ) where e is a user defined event. Events do • we define a TLS manager process that given as inputs
not influence the process execution and serve merely as an two identities id1 , id2 and outputs on a public channel
annotation for specifying properties. the channel name tls(id1 , id2 ), if either id1 or id2 are
As an example consider the processes defined in Fig- compromised;
ure 6. A server process S signs a freshly generated random • we generate a fresh name of type sid for each TLS
bitstring rnd and sends it to a user process U . U raises connection and use it as a session identifier, concate-
the event Accept(rnd) if the signature is valid. The main nating it to each message, and checking equality of this
process then declares that sk is a fresh secret key and identifier at each reception in a same session.
executes an unbounded number of copies of S and U in However, even if the communication is protected by TLS,
parallel. we suppose that the adversary can block or delay com-
In this paper we are interested in verifying authentica- munications. As communications over private channels
tion properties. We model them, as usual, as correspondence are synchronous we rewrite each process of the form
properties of the form out(tls(c, s), M ).P into a process out(tls(c, s), M )|P .
This ensures that the communications on TLS channels are
e1 (t1 , . . . , tn ) =⇒ e2 (u1 , . . . , um )
indeed asynchronous.
Such a property holds, if for any execution, any occurrence
of an instance of e1 (t1 , . . . , tn ) is preceded by the corre- 4.3. Modelling threat models
sponding instance of e2 (u1 , . . . , um ). Considering the ex-
ample of Figure 6, we model the property that any accepted We will now present how we model the different sce-
session with a given random was actually initiated with the narios discussed in Section 3 in the applied pi calculus.
same random as
4.3.1. Malware. As discussed in Section 3.1.1, we view a
Accept(x) =⇒ Init(x)
system as a set of interfaces. By default, these interfaces
This property is indeed satisfied. However, it may be too are defined as private channels. Let a be a public channel.
weak as it does not capture replay attacks. We may have A malware providing read-only access to an interface ch is

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
 M, N ::= terms P, Q::= 0 null process
| a, b, c, k, m, n, s name |P |Q parallel
| x, y, z variable | !P replication
| f(M1 , . . . , Mn ) constructor application | new n : T. P name restriction
| in(M, x : T ).P message input
E ::= expressions | out(M, N ).P message output
|M name | if E1 = E2 then P else Q conditional
| h(E1 , . . . , En ) function application | event e(M ).P event e
| fail failure

Figure 5: Terms and processes

S(sk : skey)=ˆ 4.3.4. Fingerprint and spoofing. As discussed before,

new rnd : bitstring. when browsing, one may extract informations about a user’s
event Init(rnd). location, computer, browser and OS version, etc. This finger-
out(a, (sign(rnd, sk), rnd)) print may be used as an additional factor for identification,
and can also be transmitted to a user for verification of its
U (pk : pkey)= ˆ accuracy. We model this fingerprint by adding a function
in(a, (sig : bitstring, rnd : bitstring)). fpr(id) : fingerprint which takes an identity and returns
if checksign(sig, pk) = rnd then its corresponding fingerprint. Given that all network com-
event Accept(rnd). munications are performed over a TLS channel tls(c, s) the
server s can simply extract the fingerprint fpr(c). However,
new sk : skey; !S(sk)|!U (pk(sk)) in some cases we want to give the attacker the possibility
to spoof the fingerprint, e.g., if the attacker controls the
Figure 6: Process example user’s local network. In these cases we declare an additional
function spooffpr (fingerprint) : id and the equation

modelled by rewriting processes of the form in(ch, x).P into fpr(spooffpr (fpr(c))) = fpr(c)
processes of the form in(ch, x).out(a, x).P , respectively
out(ch, M ).P into out(a, M ).out(ch, M ).P , depending on which allows the attacker to initiate a communication on
whether inputs or outputs are compromised. Read-write a channel tls(spooffpr (fpr(idC)), s) using a fingerprint
access is simply modelled by revealing the channel name ch, that is identical to fpr(idC).
which gives full control over this channel to the adversary.

4.3.2. Human errors - No compare. Our model contains

5. Analysis and Comparison
dedicated processes that represent the expected actions of a
human, e.g., initiating a login by typing on the keyboard, In this section we use the formal framework to analyze
or copying a code that he may receive through the display several multi-factor authentication protocols. The analysis is
interface of its computer or its phone. A user is also assumed completely automated using the P ROVERIF tool. All scripts
to perform checks, such as verifying the correctness of a and source files used for these analyses are available at [20].
fingerprint or comparing two random values, one displayed
on the computer and one on the phone. In the No Compare 5.1. Properties and methodology
scenario we suppose that a human does not perform these
checks and simply remove them.
5.1.1. Properties. We will concentrate on authentication
4.3.3. Human errors - Phishing. In our model of TLS we properties and consider that a user may perform 3 different
simply represent a url by the server identity idS , provided by actions:
the human user. This initiates a communication between the • an untrusted login: the user performs a login on an un-
user’s computer, with identifier idC , and the server over the trusted computer, i.e., without selecting the “trust this
channel tls(idC, idS). This models that the server URL computer” option, using second-factor authentication;
is provided by the user and may be that of a malicious • a trusted login: the user performs an initial login on a
server, which his machine is then connecting to. We let the trusted computer, and selects the “trust this computer”
adversary provide the server identity idA to the user in order option, using second-factor authentication;
to model a basic phishing mechanism. We distinguish two • a cookie login: the user performs a login on a computer
cases: a trained user will check that idA = idS , where idS that he previously trusted, using his password, but no
is the correct server, while an untrained user will omit this second factor, and identifying through a cookie and
check and connect to the malicious server. fingerprint.

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
 Threat Scenarios G 2V G 2OT G 2OT fpr
For each of these actions we check that whenever a login   
happens, the corresponding login was requested by the user. PH   
We therefore define three pairs of events NC   
FS   
(initx (id), acceptx (id)) x ∈ {u, t, c} PH NC   
PH FS   
The initx (id) events are added to the process modelling Mdev
in:RO   
the human user, in order to capture the user’s intention to Mt−dis
io:RO   
perform the login action. The acceptx events are added to Mt−tls
io:RO   
the server process. The three properties are then modelled Mt−usb
in:RO   
as three injective correspondence properties: NC Mt−tls
io:RO   
NC Mt−usb
in:RO   
acceptx (id) =⇒inj initx (id) x ∈ {u, t, c} Mdev
in:RW   
Mt−tls
io:RW   
When the three properties hold, we have that every login Mt−usb
in:RW   
of some kind accepted by the server for a given computer FS Mt−tls
io:RO   
is matching exactly one login of the same kind initiated by FS Mt−usb
in:RO   
the user on the same computer. Mu−dis
io:RO   
Mu−tls
io:RO   
u−usb
5.1.2. Methodology. For every protocol, we model the three Min:RO   
different types of login, and then check using P ROVERIF NC Mu−tls
io:RO   
whether each security property holds for all possible (com- NC Mu−usb
in:RO   
binations of) threat scenarios presented in Section 3. As we Mu−tls
io:RW   
Mu−usb   
consider trusted and untrusted login, we provide the user in:RW
FS Mu−tls   
with two platforms: a trusted platform on which the user io:RO
FS Mu−usb
in:RO   
will try to perform trusted logins, and an untrusted platform
for untrusted logins. We will thus extend the notation for Table 1: Analysis of the basic Google 2-step protocols
malwares presented in 3.1.2 by prefixing the interface with
t if the interface belongs to the trusted computer, and u if it
belongs to the untrusted computer, with for instance Mu−usb The result tables use the following notations:
io:RO
for a keylogger on the untrusted computer. A scenario is • results are displayed as a triple u t c where u, t, c are
described by a list of considered threats that may contain each  (violated) or  (satisfied) and give the status of
• phishing (PH); the authentication property for untrusted login, trusted
• fingerprint spoofing (FS); login and cookie login for the given threat scenario;
• no comparisons by the user (NC); •  and  are shortcuts for  and ;

• the malwares that may be present on the trusted and • signs are greyed when they are implied by other results,

untrusted platform. i.e., the attack existed for a weaker threat model, or the
property is satisfied for a stronger adversary;
For instance, “PH FS Mt−usb io:RW ” corresponds to the sce- • we sometimes use blue symbols to emphasize differ-
nario where the attacker can perform phishing, fingerprint
ences when comparing protocols.
spoofing, and has read-write access to usb devices of the
trusted computer, and “NC Mu−tls Even if P ROVERIF can sometimes return false attacks,
io:RW Mio:RW Mio:RW ”
u−usb u−dis

corresponds to a human that does not perform comparisons we remark that any  corresponds to an actual attack where
and full attacker control (read-write access to TLS, USB P ROVERIF was able to reconstruct the attack trace.
and display interfaces) on the untrusted device.
We use a script to generate the files corresponding to 5.2. Google 2-step: Verification Code and One-Tap
all scenarios for each protocol and launch the P ROVERIF
tool on the generated files. In total we generated 6 172 In this section we report on the analysis of the currently
scenarios that are analysed by P ROVERIF in 8 minutes on a available Google 2-step protocols: the verification code
computing server with twelve Intel(R) Xeon(R) CPU X5650 (G 2V, described in Section 2.1.1), the One-Tap (G 2OT,
@ 2.67GHz and 50Go of RAM. We note that we do not described in Section 2.1.2) with and without fingerprint, and
generate threat scenarios whenever properties are already the Double-Tap (G 2DTfpr , described in Section 2.1.3). The
falsified for a weaker attacker (considering less threats or results are summarized in Tables 1 and 2.
weaker malware). The script generates automatically the
result tables, displaying only results for minimal threat sce- 5.2.1. G 2V. In the G 2V protocol the user must copy a
narios that provide attacks, and maximal threat scenarios for code received on his phone to his computer to validate the
which properties are guaranteed. In the following sections login. We first show that G 2V is indeed secure when only
we present partial tables with results for particular protocols. the password of the user was revealed to the attacker: as
Full results for all protocols are given in Tables 7 and 8 in long as the attacker cannot obtain the code, the protocol
Appendix. remains secure. If the attacker obtains the code, either using

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
a keylogger (Mt−usb in:RO ), or by reading the SMS interface however interesting to note that G 2OTfpr resists to read only
(Mdevin:RO ), or any other read access on an interface on which access on the device as there is no code to be leaked to
the code is transmitted, the attacker can use this code to the attacker. One may argue that an SMS channel provides
validate his own session. less confidentiality than a TLS channel, i.e., the read-access
We have tested on the Google website that a code on the SMS channel may be easier to obtain in practice.
generated for a login request can indeed be used (once) for Indeed, SMS communications between the cellphone and
any other login, demonstrating that such attacks are indeed the relay can be made with weaker encryption (A5/0 and
feasible. Interestingly, this also shows that in the actual A5/2) than TLS, and the SMS message will also travel over
implementation, the verification code is not linked to the TLS between the relay and the provider’s servers. While
TLS session. This may be useful as it allows to print in this argument is in favour of G 2OTfpr , one may also argue
advance a set of codes, e.g., if no SMS access is available. that G 2V has better resistance to user inattention, as a user
In theory, linking the code to a session does not improve needs to actively copy a code.
security, as the code of the attacker session will also be sent
to the user’s phone and could then be recovered. In practice, 5.2.4. G 2DTfpr . To palli-
if the code is linked, an attack can be produced only if the ate the weakness of G 2OT Threat Scenarios G 2DTfpr
attacker’s code is received first, i.e., if the attacker can login compared to G 2V, Google NC 
just before or after the user. proposes G 2DTfpr where a FS 
We remark that the results for G 2V are also valid for comparison through a sec- NC Mt−tls
io:RO 
another protocol, Google Authenticator, in which the phone ond tap is required. The NC Mt−usb 
in:RO
and the server shares a secret key, and use it to derive from additional security provided FS Mt−tls 
io:RO
the current time a one time password. In all the scenarios by the second tap is dis-
FS Mt−usb
in:RO 
where the SMS channel is secure, G 2V can be seen as played in Table 2, where we
highlight in blue the differ- NC Mio:RO
u−tls

a modelling of Google Authenticator where the OTP is
a random value “magically” shared by the phone and the ences between G 2OTfpr and NC Mu−usb
in:RO 
server. G 2DT fpr . The attacker must FS Mu−tls
io:RO 
now be able to have its code FS Mu−usb
in:RO 
5.2.2. G 2OT. In the G 2OT protocol a user simply confirms displayed to the user and Table 2: Analysis of the
the login by pressing a yes/no button on his phone. We first then selected onto the user’s Google 2-step Double-Taps
consider the version that does not display the fingerprint, device in order to success-
and which is still in use. Our automated analysis reports fully login, so even in case of FS or NC and some read only
a vulnerability even if only the password has been stolen. access, it is not enough. Interestingly, in the NC scenario,
In this protocol, the client is informed when a second, we are now as secure as G 2V, while having greater usability.
concurrent login is requested and the client aborts. However, We note that we are still not secure in the PH FS scenario.
if the attacker can block, or delay network messages, a This means that an attacker controlling the user’s network or
race condition can be exploited to have the client tap yes some Wifi hotspot, could in practice mount an attack against
and confirm the attacker’s login. We have been able to G 2DT fpr .
reproduce this attack in practice and describe it in more
detail in Appendix A. While the attack is in our most basic 5.3. Additional display
threat mode, it nevertheless requires that the attacker can
detect a login attempt from the user, and can block network In this section, we propose and analyse small modi-
messages. fications of the previously presented protocols. Given the
benefits discussed in section 5.2.3, we first add a fingerprint
5.2.3. G 2OTfpr . We provide in the third column of Table to G 2V.
1 the analysis of G 2OTfpr . To highlight the benefits of the In Google 2-step some attacks occur because the attacker
fingerprint, we color additionally satisfied properties in blue. is able to replace a trusted login by an untrusted one, e.g.
In many read only scenarios (Mt−tls io:RO , Min:RO ,Mio:RO ,
t−usb u−tls
under Mu−usb
in:RW . If this happens, the attacker can obtain a
Min:RO ), and even in case of a phishing attempt, the user
u−usb
session cookie for its own computer and perform additional
sees the attacker’s fingerprint on his phone and does not undetected logins later on. A user might expect that by using
confirm. However, if the user does not check the values a second factor, he should be able to securely login once
(NC) or if the attacker can spoof the fingerprint (FS), on an untrusted computer and be assured that no additional
G 2OT fpr simply degrades to G 2OT and becomes insecure. login will be possible.
Some attacks may be performed on the cookie login, for Thus, we also add for all the protocols the action the
instance for scenarios Mt−tls
io:RW or Mio:RW , as the attacker
t−usb
user is trying to perform (trusted or untrusted login) to
may initiate a login from the user’s computer without the the display. This mechanism may create some harmless
user having any knowledge of it, and then use it as a kind “attacks” where the attacker replaces a trusted login with
of proxy. an untrusted login. However, such attacks indicate that an
Because of the verification code, in scenarios of FS or attacker may change to other types of actions, such as
NC, G 2V provides better guarantees than G 2OTfpr . It is password reset, or disabling second-factor authentication.

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
 Threat Scenarios G 2V fpr G 2V dis G 2OT dis G 2DT dis Threat Scenarios G 2V dis G 2DT dis
PH     PH FS Mt−tls  
io:RO
PH FS     PH FS Mt−usb  
in:RO
PH FS Mt−tls
io:RO     PH FS t−dis
Mio:RW  
PH FS Mt−usb
in:RO     Mdev  
in:RO
PH FS Mt−dis
io:RW     NC Mt−tls  
io:RO
Mt−tls
io:RO     NC Mt−usb  
in:RO
Mt−usb
in:RO     NC Mio:RWt−dis
 
Mt−tls
io:RW     FS Mt−tls  
io:RO
Mt−usb
in:RW     FS Mt−usb  
in:RO
Mt−usb t−tls
in:RW Mio:RO     FS NC Mt−tls  
io:RO
FS Mt−tls
io:RO     FS Mt−dis  
io:RW
FS Mt−usb
in:RO     NC Mu−tls  
io:RO
FS Mt−dis
io:RW     NC Min:RO u−usb
 
FS Mt−tls
io:RW     NC Mu−dis  
io:RW
FS Mt−usb
in:RW     FS Mu−tls  
io:RO
FS Mt−dis t−tls
io:RW Mio:RO     FS u−usb
Min:RO  
FS Mt−usb
in:RO M t−dis
io:RW     FS Mu−dis  
io:RW
FS Mt−usb t−tls
in:RW Mio:RO    
Mu−tls     Table 4: Comparison of Google 2-step with code or tap
io:RO
Mu−usb
in:RO    
Mu−tls
io:RW    
Mu−usb     rather than the computer, this mechanism is more resilient
in:RW
FS Mu−tls     to malware on the computer.
io:RO
FS Mu−usb
in:RO     Moreover, the code is sent through a TLS channel rather
FS Mu−dis
io:RW     than via SMS, which may arguably provide better security.
FS Mu−tls
io:RW     Finally, even though Google 2-step may significantly
FS Mu−usb
in:RW     improve security, phishing attacks combined with fingerprint
FS Mu−dis u−tls
io:RW Mio:RO     spoofing are difficult to prevent. This seems to be inherent
u−usb u−dis
FS Min:RO Mio:RW     to the kind of protocol which is Google 2-step, where the
Table 3: Google 2-step protocols with additional display security is only enforced through the 2nd factor. As we will
see in the next section the FIDO U2F protocol may provide
better guarantees for these threat scenarios.
We call G 2Vfpr , G 2Vdis , G 2OTdis and G 2DTdis the
protocols versions that additionally display fingerprint, re- 5.5. FIDO U2F
spectively the action, and provide in Table 3 the results of
our analysis. To highlight the benefits of our modifications, FIDO’s U2F adds crypto-
we color additionally satisfied properties in blue, when graphic capabilities through its Threat Scenarios U2F
considering G 2V and G 2Vfpr , G 2Vfpr and G 2Vdis , G 2OTfpr registration mechanism. As ex- 
and G 2OTdis and G 2DTfpr and G 2DTdis . plained previously, the URL of PH 
It appears that adding the action - and the fingerprint in the server the user is trying to FS 
the G 2V case - performs as expected: the protocols become authenticate to is included in Mt−dis 
io:RO
secure in all the scenarios where the only possible attack the query made to the FIDO 
Mt−tls
io:RO
was a mixing of actions. USB token, and also in the sig- Mt−usb
in:RO 
nature returned by the token.
Mt−tls 
5.4. Conclusion regarding Google 2-step The server will then only grant io:RW
login if the signature contains M t−usb
in:RW 
Currently, Google proposes G 2V, G 2OT, G 2OTfpr and its own url. Mt−usb
io:RW 
G 2DT fpr . Adding the action to the display would provide We present the results of FS Mio:RO 
t−tls

additional security guarantees. our formal analysis in Ta- Mu−dis

io:RO 
Among the studied mechanisms, G 2Vdis and G 2DTdis ble 5. U2F is secure under Mu−tls
io:RO 
provide the best security guarantees in our model, having many threat scenarios, includ- Mu−usb
in:RO 
each advantages and disadvantages. In Table 4, we provide ing some that combine phish- Mu−tls 
io:RW
a comparison between these two mechanisms. We observe ing and fingerprint spoofing. Mu−usb 
that G 2Vdis performs better than G 2DTdis only in scenarios However, an attack is found in:RW
Mu−usb 
where we have Mt−disio:RW , which may be considered as a when the computer runs mal- io:RW
powerful malware. ware that controls the USB in- Table 5: U2F results
G 2DT dis provides better guarantees in many simpler terface of the trusted computer
threat scenarios, with for instance read-only access to the (Mt−usb
io:RW ). Indeed, the malware can then communicate with
phone. As the code is sent back to the server from the phone the U2F token, and thus send a request generated for

10

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
an attacker session. Also, if the attacker can control the key because it is generated directly on the computer and
TLS interface (Mt−tlsio:RW or Mio:RW ), he may change the
u−tls
never sent over the network. We could have specified as we
intended action and replace an untrusted login with a trusted did for the others a memory interface and the corresponding
one, thus providing the attacker with a trusted cookie. As a malware. However, this malware scenario is not useful for
consequence, a login on an untrusted computer with U2F our comparison : it would have lead to attacks for both the
may enable future attacker logins on this computer. cookie and T OKEN B INDING.
This is a problem, as Yubikeys (an implementation of
U2F token) claims protection against "phishing, session 6. Pratical Considerations
hijacking, man-in-the-middle, and malware attacks." While
this holds for the first ones, this is not the case for the mal- As mentioned previously, there are some interesting
ware attacks. Moreover, one might expect that an external aspects that are outside of the scope of our threat models and
hardware token should allow users to login securely on an formal analysis. We therefore discuss below some additional
untrusted computer. Then, it is actually easy for an attacker thoughts and findings.
to submit its own request to the user’s token. Of course, a
user has to press a button to accept a request. As we said Short integer for G 2DTdis . Currently, G 2DTdis uses only
previously, with a malware controlling the TLS connection, a 2-digit integer. Hence, an attacker has probability 1/100
one press of the user may lead to many attacker logins, but to guess the integer, which is much higher than usually
this is a failure of the trust mechanism, not of U2F. accepted. To maintain usability it might be worth exploring
U2F may lead to another problem that is out of the different mechanisms, such as using images or visual hashes.
scope of our analysis: the Yubikey does not have any way to The only conditions are that the domain should be large, and
provide feedback for a successful press. When the computer a human should be able to instantly pick the correct value
submits two request in a row to the token and the user just out of the three proposed ones.
presses once, the user may believe that the press failed, and
press once more. This is similar to the problem identified Independence of the second factor. When trying to login
during the analysis of the One-Tap mechanism: success and on a malicious computer, we saw that the U2F token might
failure of the second factor should not be silent. be used by the attacker if he controls the USB interface.
To summarize, one might expect U2F to protect against Therefore, our phone, which remains completely indepen-
malware, as it is based on a secure hardware token providing dent from the untrusted computer, is not affected by malware
cryptographic capabilities. Thus, even if U2F does provide on the untrusted computer.
a better security than most existing solutions, it does not up- On the need of feedback. An advantage of the phone
hold this promise. However, the U2F mechanism providing over the U2F token is also that the token does not provide
protection against phishing is very interesting. What appears feedback to the user, and two consecutive button presses
to be lacking from U2F is some feedback capabilities, i.e may remain unnoticed. On the phone, a success or failure
a screen, to notify failures, success, and maybe information confirmation after pressing the button is easily provided to
such as the fingerprint of the computer. the user.
5.6. Token Binding Storing the keys on a dedicated secure token. An ad-
vantage of the U2F token is that if your computer is
We previously studied the security of the protocols com- compromised, the number of attacker logins is limited by the
bined with the “Trust this computer” mechanism where a number of times the button is pressed. It is then more secure
cookie is used to authenticate a computer on the long term. to store the keys on a device that ensures that keys are not
While cookies are a common mechanism, a new protocol completely compromised, rather than storing the keys on a
called T OKEN B INDING [21] is under development. After computer or a smartphone, where a malware may extract
a successful login a public key may be bound to the user them. We however saw that U2F does not provide perfect
account, and the corresponding secret key will be used to security, and if indeed the key cannot be compromised, one
sign the session identifier of the following TLS sessions. should be careful of how the token is used, to ensure that
We describe the protocol in appendix in Figure 7. It may no unwanted computer becomes trusted, or that the user
be seen as a partial U2F where the keys are directly stored may not press twice the button in a row. A solution to
on the computer. mitigate key leakage for computer or smartphones could be
We provide in Table 6 the results of the formal analysis to consider an Isolated Execution Environment, such as Intel
of T OKEN B INDING combined with U2F and G 2DTdis . It SGX, ARM Trustzone or a Trusted Platform Module.
provides protection against a read only access to the TLS
interface, because it is not any more sufficient to steal the Carrying additional authenticators. An important ques-
cookie. The attacker needs to be able to access the private tion for multi-factor protocols is of course usability. From
key of the user which was generated on his platform but that point of view, the need to buy and carry an additional
never sent over the network. token may be cumbersome. Nowadays, more and more
We remark that for T OKEN B INDING, having full access people possess and constantly carry their phone, making it
to the computer interfaces is not enough to steal the secret a natural choice for a second factor.

11

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
 Threat Scenarios U2F U2Ftb G 2DT dis G 2DT dis
tb
PH FS Mt−tls
io:RO    
PH FS NC Mt−tls
io:RO    
PH FS Mio:RW Mt−tls
t−dis
io:RO    
FS Mt−dis t−tls
io:RW Mio:RO    
FS NC Mio:RW Mt−tls
t−dis
io:RO    
Table 6: Results for the T OKEN B INDING extension

Disabling the second factor. On some websites, for instance Finally, as discussed above, U2F tokens claim to achieve
Github, disabling the second factor (and then changing the unlinkability. It would be interesting to formally model and
password) does not require the use of the second factor, study this property.
once a login was performed. It seems advisable to require
a second factor authentication to disable the mechanism. Acknowledgements. We wish to thank Arnar Birgisson and
Alexei Czeskis for interesting discussions and the anony-
Privacy. A concern about authentication that is often ig- mous reviewers for their comments. We are grateful for the
nored is unlinkability. If the same second factor is used support from the ERC under the EU’s Horizon 2020 research
to login on different providers, e.g. the user’s phone, it and innovation program (grant agreements No 645865-
might be possible to use this second factor to link accounts. SPOOC), as well as from the French National Research
Unlinkability is obviously not provided by G 2DTdis , because Agency (ANR) under the project Sequoia.
one provides the same phone number. However, U2F explic-
itly claims to achieve unlinkability by generating a fresh key
pair for every distinct provider. References

7. Conclusion [1] P. A. Grassi, M. E. Garcia, and J. L. Fenton, “Nist special publication

800-63-3 – digital identity guidelines,” Jun. 2017, available at https:
//doi.org/10.6028/NIST.SP.800-63-3.
In this paper we propose a detailed threat model for
multi-factor authentication protocols. It takes into account [2] R. Morris and K. Thompson, “Password security: A case history,”
Communications of the ACM, vol. 22, no. 11, pp. 594–597, 1979.
communication through TLS channels in an abstract way,
yet modelling interesting details such as session identifiers [3] P. A. Grassi, J. L. Fenton, E. M. Newton, R. A. Perlner, A. R.
Regenscheid, W. E. Burr, J. P. Richer, N. B. Lefkovitz, J. M.
and TLS sessions in with compromised agents. Moreover, Danker, K. K. Choong, Yee-Yin Greene, and M. F. Theofanos,
we consider different levels of malwares, in a systematic “Nist special publication 800-63b – digital identity guidelines –
way by representing a system as a set of interfaces. Ad- authentication and lifecycle management,” Jun. 2017, available at
ditionally, we allow the adversary to perform phishing and https://doi.org/10.6028/NIST.SP.800-63b.
spoof fingerprints, and consider scenarios where a careless [4] “Google 2 Step,” https://www.google.com/landing/2step/.
user does not perform expected checks. We formalize this [5] “FIDO Yubikey,” https://www.yubico.com/solutions/fido-u2f/.
model in a dialect of the applied pi calculus and use the
[6] J. Bonneau, C. Herley, P. C. v. Oorschot, and F. Stajano, “The
P ROVERIF tool to systematically and automatically analyse quest to replace passwords: A framework for comparative evaluation
several versions of Google 2-step and U2F in an extensive of web authentication schemes,” in Proceedings of the 2012 IEEE
way, considering all combinations of threats. The resulting Symposium on Security and Privacy, ser. SP ’12. Washington,
protocol comparison highlights strengths and weaknesses of DC, USA: IEEE Computer Society, 2012, pp. 553–567. [Online].
Available: http://dx.doi.org/10.1109/SP.2012.44
the different mechanisms, and allows us to propose some
simple variants, adding actions to the displayed information, [7] O. Pereira, F. Rochet, and C. Wiedling, “Formal Analysis of the Fido
1.x Protocol,” in The 10th International Symposium on Foundations &
which improves security. Practice of Security, ser. Lecture Notes in Computer Science (LNCS).
As a direction for future work we consider the use of Springer, 10 2017.
enclaves in trusted execution environments: such environ-
[8] S. Kremer and R. Künnemann, “Automated analysis of security
ments could provide execution certification and a way to protocols with global state,” CoRR, vol. abs/1403.1142, 2014.
enable secure login on a completely untrusted computer, if [Online]. Available: http://arxiv.org/abs/1403.1142
the computer is equipped with a trusted module. One could [9] R. Künnemann and G. Steel, YubiSecure? Formal Security Analysis
then use a phone as a U2F token assuming that we also Results for the Yubikey and YubiHSM. Berlin, Heidelberg:
have an efficient way to establish a channel between the Springer Berlin Heidelberg, 2013, pp. 257–272. [Online]. Available:
computer and the phone in order to pass the payload. The https://doi.org/10.1007/978-3-642-38004-4_17
U2F keys could be stored on the phone, and the next natural [10] A. Armando, R. Carbone, and L. Zanetti, Formal Modeling
step would be to merge G 2DTdis and U2F by performing and Automatic Security Analysis of Two-Factor and Two-Channel
Authentication Protocols. Berlin, Heidelberg: Springer Berlin
a U2F on the phone in parallel of the G 2DTdis . The user Heidelberg, 2013, pp. 728–734. [Online]. Available: https://doi.org/
would only see the G 2DTdis part. G 2DTdis combined with 10.1007/978-3-642-38631-2_63
for instance the storage of the keys using a trusted execution [11] D. Basin, S. Radomirovic, and L. Schmid, “Modeling human errors
environment, such as TrustZone would then palliate the issue in security protocols,” in 2016 IEEE 29th Computer Security Foun-
of keys being revealed due to malware on the phone. dations Symposium (CSF), June 2016, pp. 325–340.

12

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
[12] D. A. Basin, S. Radomirovic, and M. Schläpfer, “A complete attacker should be able to block the server response. If he
characterization of secure human-server communication,” in IEEE cannot do this, depending on the timing, the user may not
28th Computer Security Foundations Symposium, CSF 2015, Verona,
Italy, 13-17 July, 2015, 2015, pp. 199–213. [Online]. Available:
validate if he sees the error. Finally, in the attack description,
https://doi.org/10.1109/CSF.2015.21 we provide two cases, because we were not able to obtain
[13] “G Suite updates - Improved phone prompts for 2-Step
a deterministic response from the phone. Indeed, when two
Verification,” https://gsuiteupdates.googleblog.com/2017/02/ login attempts where made at the same time, we sometime
improved-phone-prompts-for-2-step.html. needed to validate twice on the screen, and sometimes only
[14] D. Dolev and A. Yao, “On the security of public key protocols,” in once. This may be due to the order of reception of requests,
Proc. 22nd Symp. on Foundations of Computer Science (FOCS’81). and session expiration on the server side. To be robust,
IEEE Comp. Soc. Press, 1981, pp. 350–357. the implementation should not accept this kind of situation,
[15] M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, and reject any kind of simultaneous login from different
S. Mangard, P. Kocher, D. Genkin, Y. Yarom, and M. Hamburg, sessions, or at least display it clearly on the phone, as it is
“Meltdown,” meltdownattack.com, 2018. [Online]. Available: done in the browser. Indeed, we believe that it is plausible
https://meltdownattack.com/meltdown.pdf
that users, after having pressed yes on their phone without
[16] P. Kocher, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, any result, would press yes once more.
S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom, “Spectre
attacks: Exploiting speculative execution,” meltdownattack.com, It is however important to
2018. [Online]. Available: https://spectreattack.com/spectre.pdf mention that the attacker must
[17] M. Abadi and C. Fournet, “Mobile values, new names, and secure
be able to detect the user login, USER D EVICE C OMPUTER S ERVER
communication,” SIGPLAN Not., vol. 36, no. 3, pp. 104–115, Jan. and block messages from the
2001. [Online]. Available: http://doi.acm.org/10.1145/373243.360213 server to the client.
Successful trusted Multi Factor login
[18] M. Abadi, B. Blanchet, and C. Fournet, “The applied pi calculus:
Mobile values, new names, and secure communication,” Journal of Appendix B. Registration
the ACM, vol. 65, no. 1, pp. 1:1–1:41, Oct. 2017.
[19] B. Blanchet, “Modeling and verifying security protocols with the
T OKEN B INDING new sk new cookie
applied pi calculus and proverif,” Foundations and Trends R in cookie
Privacy and Security, vol. 1, no. 1-2, pp. 1–135, 2016. [Online]. T OKEN B INDING is meant pk(sk)
Available: http://dx.doi.org/10.1561/3300000004 to be enabled on the trusted
[20] “Proverif source files,” https://sites.google.com/site/ devices of the user, once the
multifactorformalverif/. trust was established through
[21] A. Popov, M. Nystrom, D. Balfanz, A. Langley, N. Harper, and a previously successful Multi login, pass
J. Hodges, “Token Binding over HTTP,” Internet Engineering Task Factor Authentication. We login, pass, cookie
Force, Internet-Draft draft-ietf-tokbind-https-12, Jan. 2018, work present it in Figure 7.
in Progress. [Online]. Available: https://datatracker.ietf.org/doc/html/ check cookie
draft-ietf-tokbind-https-12
Appendix C. T OKEN B INDING

Appendix A. Global results sign((T LS _sid), sk)

An attack on G 2OT sign

We summarize in Table
7 and 8 all the results we
We provide bellow the steps of an attack on G 2OT when check sign
computed using the automated
only the password is compromised:
generation of scenarios. The
1) The User enters its password and email. results were obtained in 8 min-
2) Its browser tells him to press yes on his phone. Figure 7: T OKEN B IND -
utes of computing on a server
3) The attacker detects that the user contacted Google. with 12 Intel(R) Xeon(R) CPU
ING
After the first answer from Google the attacker blocks X5650 @ 2.67GHz and 50Gb of RAM. During the compu-
all further messages. tation, 6172 calls to P ROVERIF were made. As P ROVERIF
4) The Attacker initiates a session of its own by entering may not terminate we set a timeout at 3 seconds: only two
the user’s email and password. scenarios exceeded the timeout limit. For readability, we
5) Depending on the timing, two things then happen: only display the minimal or maximal interesting scenarios,
• The user press yes, nothing happens on its screen, and results which are implied by an other scenario are
and the attacker is logged in. greyed. The table was completely generated by an automated
• The user press yes, nothing happens on its screen, but script, to avoid transcription mistakes.
another yes/no pops up on his phone. If he presses
yes once more, the attacker is logged in.
In step 3, we block other answers from the server, because
whenever two simultaneous login requests are submitted
to the server, the server informs first one that there is a
problem, resulting in an error message for the user. Thus
to complete the attack in a completely invisible way, the

13

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
 fpr dis fpr dis fpr dis dis
Threat Scenarios G 2V G 2V G 2V G 2OTG 2OT G 2OT G 2DT G 2DT U2F U2Ftb G 2DT tb
          
PH           
NC           
FS           
PH NC           
PH FS           
t−tls
PH FS Mio:RO        -   
PH FS Mt−usb
in:RO
          
t−tls
PH FS NC Mio:RO           
t−dis
PH FS Mio:RW           
PH FS Mt−tls
io:RW
          
PH FS Mt−usb
in:RW
          
PH FS Mt−dis
io:RW Mio:RO
t−tls
          
PH FS Mt−usb
in:RO Mio:RW
t−dis
          
PH FS Mt−usb
io:RW
          
Mdevin:RO         --- --- 
t−dis
Mio:RO           
t−tls
Mio:RO           
Mt−usb
in:RO
          
t−tls
NC Mio:RO           
NC Mt−usb
in:RO
          
Mdevio:RO           
Mdev
in:RW           
Mt−tls
io:RW
         - 
NC Mt−dis
io:RW
          
t−usb
Min:RW           
NC Mt−tls
io:RW
         - 
NC Mt−usb
in:RW
          
t−dis t−tls
Mio:RO Mio:RW           
Mt−usb
in:RO M t−tls
io:RW
          
NC Mt−dis
io:RW M t−tls
io:RO
          
t−usb t−dis
NC Min:RO Mio:RW           
Min:RW Mt−tls
t−usb
io:RO
      - -   
Mt−usb
io:RW
          
NC Mt−usb
io:RW
          
Mt−usb
io:RW Mio:RO
t−tls
      - -   
t−tls
FS Mio:RO       - -   
FS Mt−usb
in:RO
          
t−tls
FS NC Mio:RO       - -   
t−dis
FS Mio:RW           
FS Mt−tls
io:RW
          
FS Mt−usb
in:RW
          
FS NC Mt−tls
io:RW
          
FS Mt−dis
io:RW Mio:RO
t−tls
          
FS Min:RO Mt−dis
t−usb
io:RW
          
FS NC Mt−dis
io:RW Mio:RO
t−tls
          
FS Min:RW Mt−tls
t−usb
io:RO
       -   
FS Mt−usb
io:RW
          
t−usb t−tls
FS Mio:RW Mio:RO        -   
Protocols
fpr
• G 2V- Google 2-step with Verification code • G 2DT - Google 2-step Double Tap (random to compare)
fpr dis fpr
• G 2V - G 2V with fingerprint display • G 2DT - G 2DT with action display
dis fpr
• G 2V - G 2V with action display • U2F- FIDO’s U2F
• G 2OT- Google 2-step One Tap • U2Ftb - T OKEN B INDING U2F
fpr dis dis
• G 2OT - G 2OT with fingerprint display • G 2DT tb - T OKEN B INDING G 2DT
dis
• G 2OT - G 2OT with action display
Scenarios:
• NC- No Compare, the human does not compare values or untrusted computers
• FS- Fingerprint spoof, the attacker can copy the user IP address • Minterface
in:acc1,out:acc2 - The interface inputs are given to the attacker with access
• PH- The user might be victim of phishing only on trusted everyday connections level acc1, and acc2 for the outputs

Notations:
• - Property satisfied (if all three) • - Property also satisfied in a stronger scenario
• - Attack found (if all three) • - - Either scenario not pertinent, or failure to reconstruct attack trace
• - Attack also present in a weaker scenario

Table 7: Global results for malware on trusted platform

14

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.
 fpr dis fpr dis fpr dis dis
Threat Scenarios G 2V G 2V G 2V G 2OTG 2OT G 2OT G 2DT G 2DT U2F U2Ftb G 2DT tb
Mu−dis
io:RO
          
Mu−tls
io:RO
          
u−usb
Min:RO           
NC Mu−tls
io:RO
          
NC Mu−usb
in:RO
          
u−tls
Mio:RW           
NC Mu−dis
io:RW
          
Mu−usb
in:RW
          
u−tls
NC Mio:RW           
NC Mu−usb
in:RW
          
NC Mio:RW Mu−tls
u−dis
io:RO
          
NC Mu−usb
in:RO Mio:RW
u−dis
          
u−usb
Mio:RW           
NC Mu−usb
io:RW
          
FS Mu−tls
io:RO
          
FS Mu−usb
in:RO
          
u−dis
FS Mio:RW           
FS Mu−tls
io:RW
          
FS Mu−usb
in:RW
          
FS Mio:RW Mu−tls
u−dis
io:RO
          
FS Mu−usb
in:RO Mio:RW
u−dis
          
u−usb
FS Mio:RW           

Protocols
fpr
• G 2V- Google 2-step with Verification code • G 2DT - Google 2-step Double Tap (random to compare)
fpr dis fpr
• G 2V - G 2V with fingerprint display • G 2DT - G 2DT with action display
dis fpr
• G 2V - G 2V with action display • U2F- FIDO’s U2F
• G 2OT- Google 2-step One Tap • U2Ftb - T OKEN B INDING U2F
fpr dis dis
• G 2OT - G 2OT with fingerprint display • G 2DT tb - T OKEN B INDING G 2DT
dis
• G 2OT - G 2OT with action display
Scenarios:
• NC- No Compare, the human does not compare values or untrusted computers
• FS- Fingerprint spoof, the attacker can copy the user IP address • Minterface
in:acc1,out:acc2 - The interface inputs are given to the attacker with access
• PH- The user might be victim of phishing only on trusted everyday connections level acc1, and acc2 for the outputs

Notations:
• - Property satisfied (if all three) • - Property also satisfied in a stronger scenario
• - Attack found (if all three) • - - Either scenario not pertinent, or failure to reconstruct attack trace
• - Attack also present in a weaker scenario

Table 8: Global results for malwares on untrusted platform

15

Authorized licensed use limited to: UNIVERSITY OF LECCE. Downloaded on January 23,2023 at 14:05:29 UTC from IEEE Xplore. Restrictions apply.