, Formal

. Over the last few years, there has been an almost exponential increase of the number of mobile applications that deal with sensitive data, such as applications for e-commerce or health. When dealing with sensitive data, classical authentication solutions based on username-password pairs are not enough, and multi-factor authentication solutions that combine two or more authentication elements of diﬀerent categories are required. Many diﬀerent such solutions are available, but they usually cover the scenario of a user accessing web applications on their lap-tops, whereas in this paper we focus on native mobile applications. This changes the exploitable attack surface and thus requires a speciﬁc analysis. In this paper, we present the design, the formal speciﬁcation and the security analysis of a solution that allows users to access diﬀerent mobile applications through a multi-factor authentication solution providing a Single Sign-On experience. The formal and automated analysis that we performed validates the security goals of the solution we propose.


Introduction
Context and Motivations. Over the last few years, there has been an almost exponential increase of the number of mobile applications (or apps, for short) that deal with sensitive data, ranging from apps for e-commerce, banking and finance to apps for well-being and health. One of the main reasons behind such a success is that mobile apps considerably increase the portability and efficiency of online services. Banking apps allow users not only to check their account balances but also to move money and pay bills or friends [1]. Mobile health apps range from personal health records (PHR) to personal digital assistants using connected devices such as smartwatches and other body-worn devices or implants. As reported in [2], there are nowadays more than 100,000 mobile health apps on the market, a number that is increasing on a weekly basis.
However, also the reports on security and privacy issues in mobile apps are increasing on a weekly basis, bearing concrete witness to the fact that the management of sensitive data is often not properly taken into account by the developers of the apps. For example, the studies performed by He et al. [3] on free mobile health apps available on the Google Play store show that the majority of these apps send sensitive data in clear text and store it on third party servers that do not support the required confidentiality measures.
When dealing with sensitive data, classical authentication solutions based on username-password pairs are not enough. The "General Data Protection Regulation" [4] mandates that specific security measures must be implemented, including multi-factor authentication, a strong(er) authentication solution that combines two or more authentication elements of different categories (e.g., a password combined with a pin sent to a mobile device, or some biometric data). There are many alternative solutions on the market for providing multi-factor authentication. Examples are FIDO (Fast IDentity Online, https:// fidoalliance.org), which enables mobile devices to act as U2F (Universal 2nd Factor) authentication devices over Bluetooth or NFC, and Mobile Connect (https://mobileconnect.io), which identifies users through their mobile phone numbers.
In addition to the establishment of high-level security for authentication solutions for mobile apps, it is essential to take the usability aspect into consideration. Monitoring apps often require a daily or even hourly use, but understandably users cannot be bothered by a long and complex authentication procedure each time they want to read or update their data, especially on mobile devices where the keyboard is small and sometimes uncomfortable to use. A better usability can be provided by supporting a Single Sign-On (SSO) experience, which allows users to access different, federated apps by performing a single login carried out with a selected identity provider (e.g., Facebook or Google). While the authentication session is valid, users can directly access all the apps in the federation, without having to enter their credentials again and again.
Contributions. In this paper, we present the design, the formal specification and the security analysis of a solution that allows users to access different mobile apps through a multi-factor authentication solution providing a SSO experience.
We focus on multi-factor authentication solutions that use One Time Passwords (OTPs), which are passwords that are valid for a short time and can only be used once. We have selected OTP-generation approaches as they are commonly used to provide strong authentication and many alternative solutions (from physical to software tools) are available on the market. For instance, Google Authenticator is a mobile app that generates OTPs [5]. Like Google Authenticator, many of the OTP-generation solutions on the market are applicable only for web solutions and use mobile devices as an additional factor.
However, in the scenario considered in this paper, users are not accessing web apps on their laptops or desktop computers, but instead they are accessing native mobile apps. In relation to SSO and multi-factor authentication, web and mobile environments and channels guarantee different security properties, e.g., in web scenarios identity providers can authenticate service provider apps using shared secrets, but this is not possible for native mobile apps that are unable to keep values secret. This changes the exploitable attack surface and thus requires a specific analysis. To the best of our knowledge, the definition of a multi-factor authentication solution for native apps is still not well specified. Even if there are some solutions currently used, their security analyses have been performed informally or semi-formally at best, and without following a standardized formal procedure. This makes a comparison between the different solutions both complex and potentially misleading.
For the security assumptions and the design of a native SSO solution, our work is based on [6,7]. In this previous work, we presented a solution for native SSO and performed a semi-formal security analysis. In this work, we extend these studies by providing a multi-factor authentication solution and a formal analysis of the identified security goals.
Summarizing, our contributions are four-fold as we have 1. designed a multi-factor authentication solution that uses OTPs as an authenticator factor and provides a SSO experience for native apps; 2. provided a description of the proposed solution detailing the security and trust assumptions; 3. formally defined the security goals of our multi-factor authentication solution; 4. formally analyzed our solution by modeling the flow, assumptions and goals using a formal language (ASLan++) and model-checking the identified security goals with the SATMC tool.
The results of our analysis show that our solution behaves as expected.
Organization. Section 2 provides background on strong authentication solutions and SSO for native mobile apps, and on ASLan++ and SATMC. Section 3 describes the design of the proposed multi-factor authentication solution, discusses the peculiarities of a multi-factor authentication solution compared to a basic username-password authentication, and identifies the corresponding security assumptions and security goals. For concreteness, Sect. 4 describes our solution in the context of mHealth apps, and the solution is then formally analyzed using SATMC. Section 5 discusses related work and Sect. 6 draws conclusions.

Background
This section provides the basic notions required to understand the proposed design for a multi-factor authentication solution that supports a SSO experience and its security assessment. In Sect. 2.1, we describe the entities involved in a multi-factor authentication and SSO solution, discuss the different OTPgeneration approaches, and identify the functional requirements of a native SSO solution. In Sect. 2.2, we provide useful background for our formal analysis.

Multi-factor Authentication and Native SSO
The entities involved in a multi-factor native SSO solution are: a User (User) that wants to access a native Service Provider app ( SP C ); an Identity Provider server ( IdP S ) that manages the digital identities of the users and provides the multi-factor process; a User Agent (UA), which could be a browser or a native app used to perform the multi-factor process between the SP C and IdP S . Optionally, the SP C app could have a backend server (SP S ). A multi-factor authentication solution augments the security of the basic username-password authentication by exploiting two or more authentication factors. In [8], it is defined as: "a procedure based on the use of two or more of the following elementscategorised as knowledge, ownership and inherence: i) something only the user knows, e.g., static password, code, personal identification number; ii) something only the user possesses, e.g., token, smart card, mobile phone; iii) something the user is, e.g. biometric characteristic, such as a fingerprint. In addition, the elements selected must be mutually independent [ . . .] at least one of the elements should be non-reusable and non-replicable".
The more factors are used during the authentication process, the more confidence a service has that the user is correctly identified.
There are many multi-factor techniques on the market. In this paper, we focus on a well-accepted solution that combines a PIN code ("something only the user knows") with the generation of an OTP using a software OTP generator ("something only the user possesses"). When an OTP-generation approach is used, a different password is generated for each authentication request and is valid only once, providing a fresh authentication property. Thus, compromising an old OTP does not have security consequences in the authentication process.
There exist many algorithms for generating OTPs and we can classify them into three main OTP-generation approaches: -Time synchronization: the OTP is generated starting from a shared secret key (called seed ) and the current time of the operation. IdP S must validate this value: only OTPs that fall into a short temporal range are accepted. -Lamport's algorithm [9]: the first OTP is generated from a seed value and each successor OTP value is based on the value of its predecessor. For example, if s is a seed value and F (x) is a one-way function, we have the following OTPs: is stored on IdP S . When a User wants to login, she sends o n−1 to the server, and the server applies the function F and checks that the result corresponds to the stored value. If the two values correspond, IdP S authenticates User and updates the stored value with o n−1 . In the next login, User will use o n−2 and so on. After n logins, User has to change the seed value and calculate new OTP values. -Challenge/Response: in the execution of this approach, IdP S presents a "challenge" (e.g., a random number) and User answers with a valid "response", which is an OTP value calculated using a mathematical algorithm starting from the challenge.
Although our solution is parametric in the OTP-generation approach, in Sect. 4, we will detail and analyze the time synchronization approach in the context of a real-world scenario.
Native SSO protocols allow users to access multiple SP C apps through a single authentication performed with an IdP S . As identified in [6], the two requirements that we expect for a native SSO solution are: (i) the IdP user credentials can be used to gain access to several SP C apps-this implies that a User does not need to have credentials with a SP C to access it; (ii) if a User has already a login session with an IdP S , then she can access new SP C apps without re-entering her IdP credentials-only the User consent is required.

Formal Analysis: ASLan++ and SATMC
The use of formal languages and automatic tools for analyzing security protocols has allowed researchers to uncover a large number of vulnerabilities in protocols that had been thought to be, or even informally proved to be, secure. Famous examples range from protocols such as the Needham-Schroeder Public Key protocol to Kerberos or TLS (see [10] for details). These examples underline how the design of a protocol that requires specific security goals is not a simple task, as its security depends on several assumptions on trust and communication channels (e.g., the federation between the involved parties, and the transport protocol used in the message exchange). Several formal languages have been developed, all sharing the idea to extract from the protocol message flow a description of the entities involved, the exchanged messages and the channel assumptions. Formal protocol specifications are then given in input to automated tools that check the desired security goals of the protocol against realistic threat models.
In this paper, we use ASLan++ [11], the input specification language of the AVANTSSAR Platform [12]. ASLan++ is a high-level formal language that formalizes the interactions between the different protocol roles, where a role represents a sequence of operations (e.g., sending and receiving messages) that must be executed by the entity that plays that role. ASLan++ supports the specification of different channel assumptions and security goals, most notably different variants of authentication and confidentiality. In our analysis, we use SATMC [13], which is one of the model checkers of the AVANTSSAR platform. SATMC uses state-of-the-art SAT Solvers and allows for the specification of security goals written using the Linear Temporal Logic.

Description of Our mID(OTP) Solution
In this section, we present a mobile identity management solution that augments the security of the native SSO solution proposed in [6] by adding a multi-factor authentication based on the generation of OTPs. We called it mID(OTP) to highlight the dual goal that our solution pursued: (i) to establish a multi-factor authentication and (ii) to manage identities for native mobile apps, e.g., providing a SSO service. As we will describe, mID(OTP) is parametric on the OTP generation (i.e., it supports different OTP-generation approaches).
In the mobile context, two possible design choices are available: a UA could be played either by a browser (external or embedded in the SP C app) or by a native app. In the design of mID(OTP), we have preferred the latter choice, as a native app can be (easily) extended to support the generation of an authentication factor (e.g., by adding the code for a OTP generator or a library to process the user's fingerprint). In addition, as the UA is involved in the authentication phase with the IdP S , it must be trusted in knowing the user's IdP credentials. Thus, we assume that this native app, called IDOTP , is released directly by the IdP S . mID(OTP) consists of three phases: registration, activation and exploitation, which we describe in the following subsections.

Registration and Activation Phases of mID(OTP)
The registration phase of mID(OTP) is performed by the SP C developers and corresponds to the exchange of some information about SP C , such as the package name and logo, together with its certificate fingerprint key hash (i.e., the hash of the certificate of the app). Note that key hash depends on the private key of the SP C developer and is thus different for apps by different developers. The registration phase can be performed in different ways, e.g., entering the data into an online dashboard or via an email exchange. As a trust relationship between SP C and IdP S is established as result of the registration phase, it is important that the IdP S validates the SP C data and in some cases (e.g., when user personal or sensitive data are involved) a service-level agreement could be required as well.
The activation phase of mID(OTP) is performed by the User to configure the native app IDOTP on her smartphone. In addition to the procedure described in [6]-user login and release of a token (token IdP ) used (from here on) to identify the user session in place of the user credentials-at the end of the activation phase the IDOTP is configured to generate OTPs, usually requiring the creation of a PIN code for the future interactions.
Also the activation phase can be performed in different ways. As a multifactor authentication is configured during this phase, it is essential to provide the User with an activation code-exchanged using a secure channel (e.g., after an in-person identification)-that she has to enter during the process.

Exploitation Phase of mID(OTP)
The exploitation phase of mID(OTP), which is shown in Fig. 1, is performed every time the User accesses a SP C that requires the multi-factor authentication and SSO experience offered by IDOTP . In Step S1, User opens the SP C app that sends a request to SP S including a session token token sync (Step S2). SP S checks the validity of token sync. If token sync has expired, SP S sends an error message asking for a login to SP C (Step S3), otherwise Step S7 is executed. If a login form is presented to User , she clicks the login button (Step A1) and SP C sends a login request to IDOTP (Step A2). As a consequence, in Step A3 IDOTP reads the key hash value of SP C and in Step A4 sends a request to IdP S asking the SP C data. The received key hash is used by IdP S to validate the SP C identity. If SP C is valid, IdP S returns to IDOTP a consent containing the meta-data of SP C (Step A5). In Step A6, User checks whether SP C is the app that she wants to access and decides whether to give her consent or not. If User agrees, the OTP is generated following one of the approaches described in Sect. 2.1 (Step A7). Then, in Step A8, IDOTP sends a token request to IdP S including the OTP value, key hash and token IdP , which corresponds to the user credentials entered during the activation phase. IdP S checks the validity of OTP, key hash and token IdP . If they are valid, a token (token SP ) for the SP app is returned (Step A9). token SP contains the identity of User , IdP S and SP , and is digitally signed with K −1 IdPS , the private key of IdP S . In Step A10, IDOTP returns token SP to SP C as result of Step A2. To finalize the authentication, SP C sends a token request to SP S with token SP (Step S4). SP S checks the validity of token SP , and if it is valid, creates and sends to SP C a token token sync (Step S5). This token will be used by SP C to synchronize user data in the future interactions, until its expiration. When SP C needs to synchronize data, sends a request to the SP S including token sync (Step S6), and SP S returns the requested resource to SP C (Step S7).
We have labeled the steps with "S" and "A". The S steps are related to the SP (but note that our representation is only an example and each SP could support different solutions). The A steps represent the steps related to the authentication solution. As the S steps can vary depending on the choices of the SP developers, in our analysis, we will focus on the A steps. Compared to the protocol flow proposed in [6], we have enhanced its security by adding the generation, exchange and validation of OTPs. For example, the OTP extension protects mainly against a stolen smartphone. Indeed, even if the user's smartphone is stolen, the intruder cannot login as the victim without generating the expected OTP.

Towards a Formal Specification of Multi-factor Authentication
We now discuss the peculiarities of a multi-factor authentication solution compared to a basic username-password authentication; in doing so, we introduce some concepts that will be the key for the formal analysis.
In a basic username-password authentication, the expected security goal is: Here, User is required to provide an authentication factor: either credentials (something only she knows) or a session token (e.g., a cookie stored in her browser) in order to properly complete the authentication process. If this is the case, it is possible to specify a minimum set of security assumptions (e.g., on the behavior of User or on the communication channels) that are necessary to guarantee G1 A . For example, if the channel used for the login is not https, then an intruder can eavesdrop the User 's password and impersonate her in the future. We call these assumptions strong assumptions (to distinguish them from the weak assumptions that we define later). A multi-factor authentication solution augments the security of the basic username-password authentication by exploiting two or more authentication factors. By the definition given in Sect. 2.1, we infer that mID(OTP) is a two-factor authentication solution using knowledge and ownership elements (factors). We do not consider inherence factors. In addition, instead of considering the independent factors, we introduce the concept of instance-factors.
We call instance-factor (IFactor ) every specific instance of either an ownership factor (IFactor o ) or a knowledge factor (IFactor k ). The multi-factor authentication solution mID(OTP) that we propose contains three instance-factors: -the IFactor o token IdP that is stored in IDOTP and in IdP S as a result of the activation phase (used as a session token in place of the user credentials to provide a SSO experience); -another IFactor k that can vary according to the specific OTP generator used, e.g., a PIN known by the user (used to protect the OTP generator); -an IFactor o that is stored in IDOTP (and possibly shared with IdP S ), according to the OTP-generator approach used (e.g., a seed value or a private key).
Note that the IFactor o token IdP is present in all instances of our solution, whereas the other two factors may differ depending on the specific solution (and this is the reason why we cannot name them explicitly a priori). Compared to classic notion of authentication factors, instance-factors can have a dependency. For example, the two IFactor o are stored in IDOTP . Thus, by breaching the IDOTP app both of them are compromised. However, it is important to note that different mitigations can be implemented for the different instance-factors. For example, in our solution, if a User realizes that the IDOTP has been compromised (e.g., if her smartphone has been stolen), she can invalidate token IdP , thus blocking possible attacks.
We are not aware of any formal definition of the multi-factor authentication property apart from [14]. In [14] they analyzed a two-factor and two-channel authentication solution that combines a classic single-factor solution with the exchange of a second factor using the GSM/3G/4G communication infrastructure of the user's mobile phone. By generalizing the definition in [14] by considering a solution involving n instance-factors, we can define the following security goal: , SP authenticates User ) holds even if an intruder knows up to n − 1 instance-factors.
Thus, the addition of instance-factors ensures some "redundancy", meaning that even if one of them is compromised there are no attacks. We call weak assumption (wa) an assumption that, whenever it is not valid or not implemented properly, causes the disclosure of a non-empty set of instancefactors of the same type, i.e., either IFactor o or IFactor k . We refer to this set as the set of instance-factors associated with wa and denote it by writing IF (wa). 1 For example, if a weak assumption wa1 states that the intruder cannot read the values typed by User , and in the authentication process User has to enter her password and PIN , then IF (wa1 ) = {password , PIN }. This definition can be easily extended to a set of weak assumptions WA as follows: IF (WA ) = wai ∈WA IF (wa i ). We write WA to denote the set of all the weak assumptions.
Defining Security Goals. The notions that we just introduced allow us to rephrase the definition of the security goal G1 MFA of a multi-factor authentication solution in the following way: A main characteristic of mID(OTP) is the use of OTPs. In G1 MFA , we considered (among others) the instance-factors linked to the OTP generation. In addition, as reported in Sect. 2, an OTP "should be non-reusable and nonreplicable." Indeed, if the OTP is not fresh, then the knowledge of an OTP leads to the same attacks possible when knowing the instance-factors linked to its generation. Thus, it is crucial that the following security goal about the OTP is satisfied: (G2) The OTP must prove its origin (meaning that IdP S authenticates IDOTP , as IDOTP is the only app that possesses a secret value shared with IdP S or a private key), and it is non-reusable (i.e., IdP S accepts only one OTP for a specific operation so as to avoid replay attacks).

Assumptions
Our solution is based on different security assumptions, which we have classified as strong or weak assumptions.

Strong Assumptions.
We have identified the following assumptions and checked them to be strong assumptions (see Sect. 4.5): Trust Assumption that clarifies the trust relationships between the different entities, Communication Assumptions that specify the concrete implementation of the communication channels required in mID(OTP), and Activation Assumption that identifies the assumptions related to the activation phase of mID(OTP).
Trust Assumption. mID(OTP) is based on the following trust relationship: Communication Assumptions. Communications between the parties are subject to the following assumptions: (ComA1) The communication between SP C and IDOTP is carried over an inter-app communication implemented using StartActivity ForResult(). This Android method-which allows an app to open another app and get a result back-guarantees that the SP C app that sends a request to IDOTP at Step A2 in Fig. 1 is the same app that receives the result back from IDOTP at Step A10. Note that even if these assumptions refer to a concrete implementation of the communication channels, in Sect. 4.3 we will provide the formal counterpart abstracting away the implementation details. By doing so, any implementation satisfying the abstract assumptions can be used in place of the implementation mentioned above (e.g., considering a similar solution in the case of iOS), and the results of our security analysis still hold. For example, the main reason to have ComA1 is to avoid the eavesdropping of the identity assertion (token SP ) by a malicious app, as in this way an intruder can use it to impersonate the user on another smartphone. An alternative implementation of ComA1 could be obtained by requiring SP C to insert a fresh value in the token request. In this way, SP C will accept only the token SP that includes the expected fresh value. Regardless of the design choice, it is crucial that SP C (and SP S if it is involved) only accepts tokens that are released for itself for a particular operation.
Activation Assumption. Phishing attacks (e.g., a malicious app that creates a fake login form and steals the user's credentials) are one of the most common types of attack and usually are beyond the scope of an authentication protocol. In our analysis, together with a secure communication, we assume that no phishing is possible during the activation phase: (ActivA) The activation phase is correctly performed by User . That is, User downloads the correct IDOTP (it is not a fake app) and correctly follows the process, and the communication channels used are secure.
Weak Assumptions. We have identified two categories for weak assumptions: Background Assumptions that specify the assumptions on the environment (user's smartphone), and User Behavior Assumptions that specify which user behaviors are allowed in our model.
Background Assumptions. The environment is subject to these assumptions: (BA1) Integrity and confidentiality of data stored in the device.
(BA2) There is no surveillance software (e.g., keylogger) installed on the user's device capable of reading the values that User types.

User Behavior Assumptions.
To enforce a correct execution of the flow and to investigate the security consequences of a stolen smartphone, in our analysis we take into account the following behavioral rules: (UBA1) User enters her IFactor k only in the correct IDOTP app being careful not to be seen by other people. (UBA2) User is the only person using the IDOTP app that stores the IFactor p associated to her identity.

Formal Specification and Analysis of the mID(OTP) Solution: The mHealth Use-Case
In this section, we describe how the semi-formal description of the mID(OTP) solution can be translated into a formal model (in this case, specified in ASLan++). mID(OTP) provides a general solution for several application contexts. Instead of presenting at first the general model and then the formalization of a use-case, for brevity and concreteness, here we describe directly the formalization of a real use-case scenario that involves mHealth (mobile health) apps. All the concepts presented apply in general to every solution based on mID(OTP) (apart from a trivial renaming of the entities). Only the steps and instance-factors related to the particular OTP generator used are specific for this use-case. In Sect. 4.1, we describe the entities and the steps of the OTP-generator approach for this use-case. In Sects. 4.2 and 4.3, we detail the mapping between the assumptions and their formal specification. In Sect. 4.4, we give the formalization of the security goals. In Sect. 4.5, we present the results of our security analysis.

Description of the TreC Scenario
TreC is an acronym for "Cartella Clinica del Cittadino", i.e., "Citizens' Clinical Record". TreC is a platform developed in the Trentino region (Italy) for managing personal health records (PHRs). 2 In addition to the web platform, which is routinely used by around 80,000 users, TreC is currently designing and implementing a number of native Android applications to support self-management and remote monitoring of chronic conditions. These applications are used in a "living lab" by voluntary chronic patients according to their hospital physicians. Examples are: -"TreC-Lab: Diario Diabete", a mobile diary that allows patients to record health data, such as the blood glucose level and physical activity, and -"TreC: Referti", which permits patients to consult their personal health data and medical prescriptions from the smartphone.
In the traditional web scenario, patients access services using their local healthcare system credentials (leveraging a SAML-based SSO [15] solution), but a solution for native SSO was missing. The solution we have proposed will allow patients to access different TreC e-health native mobile apps (and possibly other third-party e-health apps) through a single authentication act. An implementation of the proposed model is currently being tested by TreC users. In the following, we instantiate the entities described in Sect. 3 with the entities involved in TreC: Patient plays the role of User who wants to access her PHR on her smartphone. ADC ("Autenticazione del Cittadino") is the IdP of the local health care system and plays the role of IdP S . OTP -PAT plays the role of IDOTP and manages the generation of OTPs and the SSO experience for the apps installed on the phone that are part of the federation. TreC C (TreC client) plays the role of SP C and is one of the apps that are part of the ADC federation and it is used by Patient to read her PHR. TreC S (TreC server) plays the role of SP S and manages user health data. Figure 2 shows the A-steps of the exploitation phase of mID(OTP) for this use-case. Compared to Fig. 1, we have detailed the OTP generation box (steps A7 a-c), and graphically shown the channel properties, which we will explain in Sect. 4.3. Given that TreC S is not involved in the A-steps, for the sake of brevity, in the rest of the section we refer to TreC C simply with TreC . Steps A7 (a-c) model the behavior of a Time-OTP (TOTP) algorithm [16], which is a time synchronization algorithm that generates OTPs as a function of the time of the execution and a seed (i.e., a shared secret). In general, the TOTP algorithm requires that "the prover and verifier must either share the same secret or the knowledge of a secret transformation to generate a shared secret" [16], without specifying when and how to exchange this secret. In the analyzed usecase, OTP -PAT obtains the seed value as part of the activation phase, and then stores it encrypted with the PIN code ({|seed |} PIN ) selected by Patient. Thus, the OTP generation box depicted in Fig. 1 is replaced here with a PIN request (Steps A7.a), the entering of the PIN (Steps A7.b) and the generation of the OTP as a function of the seed-extracted using the PIN as decryption key-and of time (Steps A7.c).
The TreC scenario corresponds to a multi-factor authentication with 3 instance-factors: token IdP and {|seed |} PIN are IFactor o , and PIN is an In the rest of this section, we present the formalism that we have used to specify this use-case, detailing the initial state and the behavior of the entities, the channels and the security goals. We also describe how we have formalized the assumptions presented in Sect. 3.4. In Table 1, we show each assumption and the corresponding formal specification. In addition, we model what in Sect. 3.3 is indicated as an assumption not valid or not implemented properly by removing it from the formal model, as shown in the last column of Table 1.

Formal Specification of the Initial State and of the Behavior of Entities
Initial States. The initial state of a protocol defines the initial knowledge of the intruder, who is indicated with the letter i, and of all the honest entities that participate in the protocol session, where a protocol session is a particular run of the protocol, played by specific entities, using specific instances of the communication channels and optionally, additional parameters that must be passed as initial knowledge to the different entities. To model the TA assumption, as shown in Table 1, in our analysis we have not considered sessions with i playing the role of OTP -PAT and ADC .
Regarding the registration phase, we have modeled the data provided by the TreC developer as initial knowledge of ADC . In general, after the registration phase, IdP S creates two databases: trustedSPs, containing the relation between the SP C identities and their key hash values, and metadataDB, containing the relation between the key hash and the information (e.g., name and logo) provided by the SP developers. As shown in Table 1 by the ActivA assumption, we have modeled the data obtained as result of the activation phase (token IdP and data required for generating OTPs) as initial knowledge of User , IDOTP Table 1. Mapping between assumptions (Asm(s) for short) and formal specification.

Asm
Formal specification and IdP S . In particular, for the use-case, as result of the activation phase: a Patient knows her PIN value (pinUser), OTP -PAT knows token IDP and {|seed|} pinUser, and ADC creates a DB (usersDB) with Patient, token IDP and seed as entry.

Specification of Asm Removal of Asm
To specify that the intruder knows a message m, we use the ASLan++ predicate iknows(m). As shown in Table 1 for ActivA, BA1 and BA2, the removal of an assumption (which we will do to consider different scenarios of the analysis) boils down to adding some iknows facts to the initial knowledge of the intruder.
Behavior of Entities. The behavior of the honest entities is specified by the evolution of the system, which consists of a sequence of operations performed by each role. For simplicity, Fig. 3 shows the evolution of the protocol using a process view, which describes the messages exchanged in Fig. 2 for each entity as a set of actions (e.g., receive or send a message and DB access). This formal representation can be translated into various role-based formal languages and input to different state-of-the-art security protocol analyzers. In our analysis, we use ASLan++ and SATMC (see [11] for more details on language and tool).
The translation of the process view into ASLan++ is quite straightforward. The complete ASLan++ specification can be found at https://st.fbk.eu/ publications/POST-2018. Here, for lack of space, we provide only an example by considering Steps 1 and 2 of Fig. 2 where Actor is the keyword used in ASLan++ to represent the entity taken into consideration, in our example TreC . In our analysis, we have considered the behavior of a Dolev-Yao intruder [17], who can overhear and modify messages using his initial knowledge and the knowledge obtained from the traffic-this behavior is built-in in the SATMC tool. An operation that is not allowed to i is the reading of the internal state of another entity, where an internal state is a list of expressions known by the corresponding entity. Thus, as highlighted in Table 1, BA1 and BA2 are built-in in the tool.

Formal Specification of Channels
For a detailed definition of the properties of channels between two protocol entities A and B we point the reader to [18,19]. In a nutshell, consider a message M sent on a channel A2B from A to B. A2B is authentic if B can rely on the fact that only A could have sent M . A2B is confidential if A can rely on the fact that only B can receive M . A2B is weakly authentic if the channel input is exclusively accessible to a single, but yet unknown, sender, and A2B is weakly confidential if the channel output is exclusively accessible to a single, yet unknown, receiver. A link between two channels A2B and B2A means that the entity sending messages over the A2B is the same entity that receives messages from B2A. We have represented these properties graphically in Fig. 2 as follows: A •→ B, A •→  B, A →• B, A →• B mean authentic, weak authentic, confidential and weak confidential channel, respectively; moreover, we indicate a link property between two channels with the same trace for the corresponding arrows.
As shown in Table 1, we have modeled as channel properties the tree communication assumptions (ComA1, ComA2 and ComA3) and the two user behavior assumptions (UBA1 and UBA2). The modeling of these assumption is far from a trivial mapping and requires an explanation.
ComA1 is related to the inter-app communication in the mobile. The property expected by the StartActivityForResult method can be modeled by a link property between the two channels used in the mobile: the app that has sent a request is the same app that will receive the result.
ComA3 is modeled with five channel properties (see Table 1) that all together model a TLS/SSL unilateral channel.
Regarding ComA2, we have modeled an Android method, which extracts the key hash value included in the package of an app, using an authentic channel (used by TreC to send its identity to OTP -PAT ) and a DB containing the relations between the SP C identities and their key hash, used by OTP -PAT to read the correct key hash value. This is due to the fact that this methodexecuted by the Android OS-guarantees the authenticity of its output.
We have modeled UBA1 and UBA2 as properties of the channel from Patient to OTP -PAT (P2O). UBA1 is necessary to prevent leakage of the PIN -entered in a malicious app or watched by an intruder during the typing-thus, we have modeled P2O as a confidential channel. UBA2 guarantees the possession of the OTP -PAT app installed in the user's smartphone. Having this assumption, only the valid Patient can communicate with that particular installation of OTP -PAT , thus we have modeled P2O as an authentic channel.

Formal Specification of Security Goals
As described in Sect. 3.3, we have defined G1 MFA in terms of a traditional authentication goal and the strong and weak assumptions. This means that, in the formal model, we consider the traditional authentication goal G1 A and we check whether it holds under the strong assumptions and different (sub)sets of weakassumptions. The property must hold if the intruder is not able to compromise all the instance-factors. G1 A requires that a message is transmitted in an authenticated and fresh manner, thus allowing TreC to authenticate Patient and offering replay-protection at the same time. For the definition of authentication we refer to [20]: whenever the entity B completes a run of the protocol apparently with the entity A, then A has previously been running the protocol apparently with B, and the two entities agree on a message M . In ASLan++, this corresponds to specifying the goal (G1 A ) SP authn U on Request: ( ) Patient *->> TreC ; where *->> indicates authenticity, directedness (i.e., the only (honest) receiver of a message is the intended one [11]) and freshness. In addition, following the definition in [20], associated goal labels are used to specify which values of M the goal is referring to, namely, the Request value in State 1 of the Patient process (in Fig. 3) and the corresponding value in the last state of the TreC process (State 3 in Fig. 3).
Similarly, the OTP properties are checked by means of the goal (G2) IDP authn UA on OTP: ( ) OTP -PAT *->> ADC ; with the associated goal labels specifying for M the values otp generation (Seed,Time) in States 3 of both the OTP -PAT and the ADC processes in Fig. 3, where we have modeled Seed as a constant value shared between OTP -PAT and ADC , and Time as a session parameter (cf. [16]) shared between OTP -PAT and ADC . Thus, ADC will accept only one OTP value for each session, enforcing the property (informally described in Sect. 3.3) that OTP is non-reusable.

Results of the Security Analysis
We are now ready to discuss the results of the security assessment that we have performed on the mHealth use-case. Our focus is determining whether the concurrent execution of a finite number of protocol sessions enjoys the expected security goals in spite of the intruder. To this aim, we have mechanically analyzed the formal model of our use-case using SATMC, a state-of-the-art model checker for security protocols. SATMC carries out an iterative deepening strategy on k. Initially k is set to 0, and then it is incremented till an attack is found (if any) or k max is reached. If this is the case, no attack traces of length up to k max exist, where the length of the trace is computed by taking into account the parallel execution of non-conflicting actions (actions executed in parallel are considered as a single step). The trace includes the actions performed by attacker and honest participants, where most of the actions of the attacker are executed in parallel (and counted as a single step) with the ones of honest participants. We set k max to 1.5 times the length of the longest trace of the protocol when only honest entities participate. As a rule of thumb, with this choice we are reasonably confident that no attack is possible with greater values of k max . In our analysis, the length of the longest trace of the protocol when only honest entities participate is 19, and thus we have set k max = 30. We have considered several scenarios including (at most) three parallel sessions in which the intruder either does not play any role or plays the role of SP C (the TreC app in the usecase). In each session, we used different instances of the channels. The complete set of specifications can be found at the companion website.
In Sect. 3.4, in relation to the security goal G1 MFA (and consequently to G1 A ), we have described a list of strong and weak assumptions that we have Regarding the weak assumptions (BA1, BA2, UBA1, and UBA2), we have performed the following analyses that are detailed in Table 3:

Analysis 2:
We have checked that by removing only one of the four weak assumptions from the model, SATMC does not find any attack on the solution (i.e., the intruder is not able to impersonate the user). Indeed, as shown in Table 3, by removing only one weak assumption, the intruder obtains only 1 or 2 instance-factors. Analysis 3: We have checked that by removing specific subsets of weak assumptions it is possible to compromise all the instance-factors, causing a violation of G1 A . In Table 2, the star (*) denotes that the result

BA1
x No can be "yes" or "no" depending on the chosen subset of weak assumptions. The subsets shown in Table 3 violate G1 A and result in different attack traces. Figure 5 shows the attack trace deriving from removing UBA1 and UBA2 (e.g., a proximity intruder that watches the PIN entered by Patient and then steals the smartphone). In the attack, i initiates a session of the protocol with trec pretending to be patient (indicated as i(patient)). By entering the PIN code (pinUser) when requested by otppat, i is able to impersonate the patient and obtaining the requested resource (resources1). Figure 6 shows the attack trace deriving from removing both BA1 and BA2 (e.g., a hacker that steals the PIN typed by Patient using a keylogger and reads token IdP and {|seed |} PIN exploiting a malware installed on the smartphone). In this case, i is able to generate an OTP and sends a token request to adc.  As expected, when checking the solution w.r.t. the security goal G2-which embodies the OTP properties-under all the (weak and strong) assumptions, SATMC does not find any attack.

Related Work
OAuth 2.0 [21] and OpenID Connect [22] have been designed for light-RESTful API services, and are considered the de-facto standards for managing authentication and authorization. These protocols are well-accepted in the web scenario, but they provide only partial support for mobile apps (frequent use of the expression "out of scope"). This could lead to the implementation of insecure solutions. An in-depth analysis of OAuth in the mobile environment-underlining possible security problems and vulnerabilities-is available in [23,24]. Given the lack of specifications, the OAuth Working Group has released in 2017 a best practice with the title "OAuth 2.0 for Native Apps" [25]. The specification of [25] has two main differences with respect to our solution: the choice of UA (browser vs native app) and the activation phase. The authors of [25] do not described any security issues in using native apps as UA; they discourage this because of the overhead on users to install a dedicated app. Nevertheless, in some scenarios, we consider this to be an advantage rather than a drawback because it allows for easily integrating new security mechanisms (e.g., access control and a wider range of MFA solutions). Concerning the activation phase of our solution, it allows for better mitigation of phishing as users directly interact with our app. Instead, [25] requires a redirection from a (possible malicious) SP C to a browser, thus users can be cheated by a fake browser invoked by SP C . We want to underline that, as described in [7], our solution is not designed from scratch but on top of Facebook; and the formalization that we have presented in this work can be easily extended to also analyze the OAuth solution of [25].
Much research has been carried out to discover vulnerabilities in different implementations of OAuth 2.0 and OpenID Connect in web and mobile scenarios. For instance, Sun et al. [26] analyzed hundreds of OAuth apps focusing on classical web attacks such as Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). Other studies, such as [27,28], analyzed the implementations of multi-party web apps via browser-related messages. In the context of mobile apps, a similar work is described in [29], where Yang et al. discovered an incorrect use of OAuth that permits an intruder to login as a victim without the victim's awareness. To evaluate the impact of this attack, they have shown that more than 40% of 600 top-ranked apps were vulnerable.
Although these techniques are useful for the analysis of a specific implementation (as they are able to discover serious security flaws), it is important to perform a comprehensive security analysis of the standard itself. In the context of web apps, Fett et al. [30] performed a formal analysis of the OAuth protocol using an expressive web model (defined in [31]) that describes the interaction between browsers and servers in a real-world set-up. This formal analysis revealed two unknown attacks on OAuth that violate the authorization and authentication properties. A similar analysis is performed for OpenID Connect in [32]. Two other examples of formalizations of OAuth are [33], where the different OAuth flows are modeled in the Applied Pi calculus and verified using ProVerif extended with WebSpi (a library that models web users, apps and intruders), and [34], where OAuth is modeled in Alloy.
In our analysis (cf. Sect. 4) we used ASLan++ and SATMC. In the past, SATMC has revealed severe security flaws in the SAML 2.0 protocol [15] and in the variant implemented by Google [18]; by exploiting these flaws a dishonest service provider could impersonate a user at another service provider. Moreover, Yan et al. [35] used ASLan++ and SATMC to analyze four security properties of OAuth: confidentiality, authentication, authorization, and consistency.
The aforementioned formal analyses, however, focus on the web app scenario, whereas in this paper we deal with native apps. In [36], Ye et al. used Proverif to analyze the security of a SSO implementation for Android. They applied their approach to the implementation of the Facebook Login and identified a vulnerability that exploits super user (SU) permissions. In contrast, our analysis assumes that the user smartphone cannot be rooted. Indeed, if a malicious app is able to obtain a SU permission, then it can set for itself the permission to access all the data stored in the smartphone, compromising all the user data and the tokens of the other apps installed on the rooted smartphone.
YubiKey NEO [37] is one of the most attractive mobile identity management products on the market. It is a token device that supports OTPs and the FIDO Alliance Universal 2nd Factor (U2F) protocol, and, by integrating an NFC (Near Field Communication) technology, it can be used to provide a second-factor also in the mobile context. Compared to this product, our solution provides a multi-factor authentication solution for native mobile apps without requiring an additional device.

Conclusions
We have presented the design of mID(OTP), a multi-factor authentication solution for native mobile apps that includes an OTP exchange and provides a SSO experience. In addition to the protocol flow, we have detailed the security assumptions and defined two security goals: G1 MFA related to a multi-factor authentication solution and G2 that identifies the properties of a OTP. To perform a security analysis of mID(OTP), we have detailed the OTP-generation approach in the context of a real use-case scenario (TreC). We have formally modeled the flow, assumptions and goals of TreC using a formal language (ASLan++) and checked the identified security goals using a model-checker (SATMC).
The solution we have presented, as well as the formal specification and analysis that we have given, can be generalized quite straightforwardly to other use-cases, which we are currently doing. As future work, we also plan to extend the analysis to other authentication factors, such as biometric traits. In addition, we started exploring an alternative formalization of multi-factor authentication protocols that decomposes the protocol and models the authentication property as a composition of two goals: one related to basic authentication (involving User , UA, SP C and IdP S ) and one related only to the generation and validation of the OTP (without involving SP C ). In this way, a proper separation is kept between the multi-factor authentication performed with IdP S and the basic authentication plus SSO experience offered to SP C . As a preliminary analysis, we can affirm that the two different definitions of goals lead to similar attack traces.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.