Samy Kambou
email: samy.kambou@imt-atlantique.fr

Ahmed Bouabdallah
email: ahmed.bouabdallah@imt-atlantique.fr

A Strong Authentication Method for Web/Mobile Services

Keywords: strong authentication, multi-factor authentication, internet of things, one-time password, diversity, cloud-based web service

This paper presents an original and strong authentication method for cloud services from smartphones. It is based on a two-factor scheme improved by the diversity of devices and network channels. It combines an OTP 1 -based approach using an IoT 2 object as a secondary device. Authentication factors are transmitted over different channels implementing distinct protocol stacks (LTE 3 , LPWAN 4 , ...). The proposal uses end-to-end encryption for the transfer of sensitive data. An experimental application of the method is illustrated by analyzing authorization access issues to cloud services located in a trusted zone. A platform developed to test the approach is briefly presented.

I. INTRODUCTION

The smartphone has gradually become the indispensable companion for all daily tasks. Its mobility capabilities, combined with its growing processing power and autonomy, allow end users to access most online cloud services from anywhere at any time. Such a change of use thus leads the smartphone to gradually move from the position of secondary device to that of primary device (formerly occupied by the laptop computer).

Such an evolution has many impacts including those related to two-factor authentication methods for cloud services from a computer and involving the smartphone as a second terminal. In this case, the first step of authentication takes place between a service located in the cloud and the end user connected from a computer. If successful, the service sends a specific code by SMS to the end user's smartphone. The latter relays it to the service via his computer. The service validates this second step if the code received is the same as the one sent initially. The multiplicity of devices and communication channels of such a scheme reduces its attack surface and is at the origin of its robustness. But this one will be clearly lost if applied with a smartphone used both as a primary and secondary device.

It is however possible to keep the principle of this scheme and at the same time maintain its robustness by introducing a smart-Thing [START_REF] Kuniavsky | Smart things: ubiquitous computing user experience design[END_REF] as secondary device. We build on this approach to design and develop an authentication protocol that provides a high level of assurance. In the proposed solution the end user submits with his mobile phone the first authentication factor and then directly access a cloud service. The second factor which is OTP-based [START_REF] Eldefrawy | OTP-Based Two-Factor Authentication Using Mobile Phones[END_REF], is exchanged between the smart-Thing and the service through a protocol of the LPWAN family [START_REF] Krupka | The issue of LPWAN technology coexistence in IoT environment[END_REF]. To the best of our knowledge, there have been no other authentication scheme proposed in the literature using an LPWAN network as an alternative channel to provide two-factor authentication from a mobile to cloud-based web services.

The paper begins with some background about authentication schemes and quickly sketches the IoT environment. The proposed authentication method is then described in detail. To illustrate the approach, a common use case of authentication is then conducted by analyzing authorization access issues to cloud services. A platform developed to test the approach is briefly sketched.

II. RELATED WORKS A. Authentication methods

Authenticating an information consists in verifying its authenticity. In our case it consists in being able to remotely attest the authenticity of a claimed identity. Almost all existing approaches involve checking a predefined link [START_REF] Gorrieri | Varieties of Authentication[END_REF] between the targeted identity and other dedicated information that we will call credential. Credentials are usually classified as :

• "something you know" which can be seen as a knowledge credential (KC). We may quote for example textual or graphical passwords, personal identification numbers (PIN), lock patterns etc. • "something you have" which falls in the possession credential (PC) class. We can mention smart cards, hardware tokens etc. • "something you are" which belongs to the inheritance credential (IC) category. We can cite mainly physiological features as fingerprint, iris, voice, DNA, etc. This list is far from being exhaustive because it is indeed possible to use other kind of credentials (for example "where you are" like geographical location, IP address, ... or more generally contextual information).

The intensity of attacks against authentication methods has necessitated their reinforcement by the verification of additional credentials in the framework of multi-factor methods [START_REF] Roberto | A two-factor mobile authentication scheme for secure financial transactions[END_REF]. Several multi-factor authentication systems have been proposed for a wide variety of purposes. Some of the most recently proposed mobile-based authentication are as follows.

TDAS [START_REF] Teh | TDAS: a touch dynamics based multi-factor authentication solution for mobile devices[END_REF] is a touch dynamics based multi-factor authentication system for mobile devices. The proposed approach aims to study the feasibility and benefits of adopting an authentication method based on touch dynamics mechanism (IC) by integrating it with the PIN-based authentication method (KC). The authors presented how the data set may be used to strengthen the protection of resources that are accessible on mobile devices.

Another approach is by Crossman and Liu [START_REF] Crossman | Two-factor authentication through near field communication[END_REF], who propose a two-factor authentication based on NFC smart-phone devices. Firstly, users are asked to enter a password (KC) which unlocks the protection of the key on their mobile phones. Then, the key (PC) is transferred through NFC to complete the authentication process. In this system, the two factors are managed by the same mobile phone. This assumes a central point of vulnerability that can potentially be used by an attacker. Indeed, if the attacker compromises the mobile phone, the two authentication factors will be easily available. Barkadehi et al. [8] proposed another two-factor authentication system by using the mobile phone as a mirror. In their proposed system, a web application uses a username/password as an authentication factor (KC) in the first step and then a white box will be shown to the users. The users cannot see the mouse cursor in the box but must move their mouse in the box in order to click the right second password. At the same time, they receive a notification on their mobile phone (PC) to open the mirror application. Then, they must accept the received request to continue the authentication process and they will see their web-based cursor on a shuffled keyboard in their mobile application. To conclude the authentication process, the users need to select their second password. After a valid authentication process, the users will have access to a web service through their laptop. Our scheme involves the use of a mobile phone to access a cloud-based web service. Another smart device is integrated to improve the security.

Our solution is also based on OTP-based two-factor authentication and is divided into two main steps:

• the mobile phone will be used to control the first factor.

• the smart device will have to manage the second factor.

B. IoT environment

With rapid development of Internet services and wireless technologies, intelligent mobile devices are well integrated into our daily life to provide customized Internet of things (IoT) to individuals. Every intelligent mobile object is now capable of interconnection, storing data and receiving user command to accomplish tasks requested by users. Heterogeneous system architectures are formed in which different types of devices as well as the relevant communication techniques are deployed. Conventional security mechanisms must therefore be refined to fit the requirements from IoT environment.

An IoT device is integrated into our OTP-based two-factor authentication scheme. This smart-Thing must implement a network stacl of the LPWAN family [START_REF] Krupka | The issue of LPWAN technology coexistence in IoT environment[END_REF] such as LoRa/SigFox networks or one of the latest 3GPP technologies dedicated to the IoT solutions which are LTE cat m1 and NB-IoT networks. The IoT device must also be an active object meaning that it must have its own power supply and be able to perform some cryptographic operations.

III. STRONG MOBILE AUTHENTICATION SCHEME FOR WEB/MOBILE APPLICATIONS

Strong authentication is a technique relying on more than one authentication credential. By combining something you know and something you have, an adversary needs to physically steal your hardware token and also learn your password. This two-factor authentication scheme provides improved protection. In addition communication channels' and devices' diversity is another way to further improve it. By this way, attacks such as man in the middle or eavesdropping are much more difficult to carry out since the adversary must simultaneously control both channels and devices. We introduce below a strong authentication method on mobile using an IoT device and exploiting these two improvements.

To authenticate a user on his smartphone and using an IoT device as a security token, certain components must be in place. Fig. 1 shows the basic architecture and the main components used to design the proposed scheme. The user must have a smartphone (M ) connected to Internet through LTE (or WIFI) and also be in possession of an IoT device (O). These two devices must be equipped with BLE 5(or NFC 6 ) technology that is increasingly be leveraged to create more mobile-friendly experiences. By using his mobile, the user can access to web services located in the Cloud subject to prior authentication. These web services hosted by servers disseminated in the Cloud are connected to S which is the front-end that will manage the authentication process. S is also connected to a LPWAN network through Internet allowing in this way its communication with the IoT device O.

We propose a strong authentication scheme involving two distinct user's devices which communicate over different networks. One important point concerns the fact that both devices are controlled by the same user. This is ensured by a closed loop going through all the components involved in our architecture illustrated in Fig. 1. The loop starts in the mobile requesting the service, goes through the network with S and then via the IoT device and back to the mobile. This closed loop can be realized in several ways. Below, we describe how to use it in our strong authentication scheme.

IV. AUTHENTICATION PROTOCOL IN DETAIL

We first summarize in the following table, all the notations used in the descriptions below. The protocol rests on several security services. We first describe the main steps of the protocol while abstracting security issues. We then provide a detailed account of the required underlying security services.

A. Protocol description

The proposed method rests on three distinct channels:

• a primary channel between the mobile phone M and the authentication server S • a secondary channel between S and the IoT device O • a tertiary channel between O and M In the developed prototype, we instantiate these three categories respectively with LTE, LoRa and BLE. There are therefore many other choices that must however take into account the technical constraints imposed by the devices. These channels require at least confidentiality and integrity for exchanged messages. To avoid depending on the protocol security specificities used to instantiate a channel, we use a security layer detailed in section IV-B to independently guarantee the requirements for each communication channel.

We now focus on the flow of information required for an authentication as outlined in Fig. 2, the steps of which are detailed below: 1) By using his mobile phone M , the user submits a username (u id ) and password (pwd) to the authentication server S. These credentials (F1) are transmitted over an LTE link. This is the initial step of the authentication protocol during which the first something you know factor is used.

M → S : [u id , pwd] LT E
2) S verifies the received data. If the data match with those stored in the database (DB), S replies with an authentication token (t 1 ) and an OTP secret (sec OT P ).

B. Security enforcement of the protocol

Security brings a panoply of challenges in the authentication protocol design. It is therefore very difficult to build a secure authentication protocol [START_REF] Abadi | Prudent engineering practice for cryptographic protocols[END_REF]. Formal proofs could provide guarantees on the correctness of the protocol. However failing to provide a formal proof which at the time of writing this paper is still in progress, we introduce below the sound principles followed in the design of this protocol.

Firstly, OTP is introduced in our proposal as the second authentication factor. The OTP codes are generated by the IoT device and can therefore appear totally random. As the name suggests, each OTP code is only used once. By changing each time an OTP code is needed, OTP solution introduces liveness. This is an important issue in security. we took advantage of JWT [START_REF] Jones | JSON Web Token (JWT)[END_REF] which are tokens using a container to transport data between interested parties in JSON. These tokens are base64-encoded. We use them to authenticate all exchanged requests in a RESTFUL approach. They are defined with an expiration time that avoids forever valid tokens. The tokens are also protected against replay attacks by applying timestamps.

Thirdly, the three communication channels are secured with encryption algorithms.

1) LTE Channel: Mobile Phone ↔ Authentication Server

• Key Agreement: Before any data transmission, ECDH(E) (Elliptic Curve DiffieHellman, where final "E" stands for "ephemeral") and ECDSA (Elliptic Curve Digital Signature Algorithm) algorithms are used to create a secure channel between each mobile phone and the authentication server. These algorithms allow to define a trusted session key (ms). ECDH [START_REF] Maryam | Diffie-Hellman and its application in security protocols[END_REF] is a well-known key agreement protocol used to define a shared secret over an insecure channel. Each involved party must have an elliptic curve public-private key pair. ECDH(E) is a variant of ECDH which provides temporary key pair instead of trusted static key pairs (via a certificate). ECDSA [START_REF] Don | The elliptic curve digital signature algorithm (ECDSA)[END_REF] is a variant of Digital Signature Algorithm (DSA) which uses the elliptic curve cryptography. This algorithm is used by a signatory to affix a digital signature on data and by a checker to prove the validity of the signature.

Each party involved has a public-private key pair.

The private key operates in the signature generation process and the public key is used for the signature verification. ECDSA provides message authentication, integrity and non-repudiation. a) M generates its keys pair (K priv m , K pub m ) and sends its public key and its signature to S. M :

K priv m , K pub m M : Sg K pub m (h 1 (id m )) M → S : [K pub m , Sg K pub m (h 1 (id m ))
] LT E b) S verifies the received signature to ensure that the data come from M (we make the assumption that S has previously registered the respective identities of all the legitimate devices which can be used for a user authentication). If the data come from a known device, S generates its pair of keys (K priv s , K pub s ). Then, it computes the session key (ms) using its private key and the public key of M . Finally, S replies to M with its public key and its signature.

S : XSg K pub m (h 1 (id m )) =?Sg K pub m (h 1 (id m )) S : K priv s , K pub s S : ms = Compute [K priv s , K pub m ] S → M : [K pub s , Sg K pub s (h 1 (id s ))] LT E
c) M verifies the received signature to ensure that the data come from S (we make the assumption that M has previously registered the identity of the authentication server S). Then M computes the session key (ms) using its private key and the public key of S. M :

XSg K pub s (h 1 (id s )) =?Sg K pub s (h 1 (id s )) M : ms = Compute [K priv m , K pub s ]
• Symmetric Encryption: After the key negotiation, the channel is secured with AES cipher [START_REF] Saicheur | An implementation of AES-128 and AES-512 on Apple mobile processor[END_REF] (standard recommended by NIST) using the key (ms) to provide end-to-end data encryption and integrity (E ms ( * )). Furthermore, OTP secret is signed (Sg idm ( * )) by the authentication server using the mobile identifier as a seed. Thus, the secure data are completely binded to a specific mobile phone which is by the way ensured that sensitive information received on this channel come from the authentication server. The complete respective expressions of step 1 and 2 introduced in section IV-A are thus:

M → S : [E ms (u id ), E ms (h 2 (pwd))] LT E S → M : [E ms (t 1 ), Sg id M (E ms (sec OT P ))] LT E
2) BLE Channel: Mobile Phone ↔ IoT device This channel is secured with symmetric AES encryption. More precisely, the AES cipher with 128-bit pre-shared key length (mo) is implemented to provide end-to-end data encryption. The data being transferred over this channel are tokens and OTP secrets which are already secure.

Step 3 and step 6 of IV-A are refined below:

M → O : [E mo (E ms (t 1 )), E mo (sec OT P )] BLE O → M : [E mo (E ms (t 2 ))] BLE
3) LoRa Channel: IoT device ↔ Authentication Server This link is secured with the AES cipher with 128-bit pre-shared key length (so) to provide end-to-end data encryption.

Step 4 and step 5 of IV-A are refined below:

O → S : [E ms (t 1 ), E so (cod OT P )] LoRa S → O : [E so (E ms (t 2 ))] LoRa V. PROTOTYPE IMPLEMENTATION
We have set up a test platform to experimentally evaluate the proposed strong authentication method. However, an authentication mechanism is usually associated with an authorization process that allows an authenticated user to access a specific part of an application server. In order to evaluate the proposed authentication method in a common context, we have investigated in the following paragraph a possible integration of our authentication method with an authorization control giving access to a cloud-based web service. We look at the particular case of services located in a trusted area, which deserves attention because it is very common in practice. An extension of this approach relaxing this trust-assumption by integrating our method in a general frameworks such as OpenId Connect and OAuth 2.0, is presented in [START_REF] Kambou | Using structural diversity to enforce strong authentication of mobiles to the cloud[END_REF].

A. Authorization control for a web service deployed in a trusted area

In this configuration, the authorization to access to services is also granted by the previous authentication server (S) thanks to the accessToken (t 2 ) obtained after authentication process. The idea is to first limit access to the trusted area before granting or not the protected service, requested by an authenticated user. In the rest of the paper, we consider the authentication and authorization server (AAS) instead of the authentication server (S).

Fig. 3 shows the data flow needed to authorize access to an application server (AS) located in the trusted area. First, the authenticated user initiates a request to access to a protected resource or service using an authorization parameter. This parameter contains the encryption value of the AccessToken (t 2 ) concatenated with a random value (RAN D). As we have introduced in the previous sections, t 2 is a sensitive data required for any secure request toward the trusted area which can not be observed in plain text. It must pass through the network in encrypted form. To improve the security, RAN D is introduced to ensure that previous access requests cannot be reused in replay attacks. AES encryption is used with a 128-bit pre-shared key (E mas ( * )) length only known by M and AS to secure the link.

M : Generate RAN D M → AS : [E mas (t 2 ||RAN D)]
RAN D is also transmitted by M to AAS. It is used to compute a response to the challenge (RES) giving access to a protected resource or service.

M → AAS : [t 2 , RAN D] AAS : Compute RES = h 3 (RAN D)
AS decrypts the received data and computes its own version of the response to the challenge (XRES) using RAN D. Then, AS used t 2 to make a valid request to AAS by sending XRES. a) A Reverse Proxy: it is the entry point to the trusted area. It channels all requests from the Internet and forwards them to the appropriate servers.

b) An Authentication Authorization Server (AAS): It processes an authentication request to define if a previously registered user is really who he claims to be. After successfully authentication, an authorization mechanism determines precisely whether this authenticated user has access to a requested service by evaluating the authorization policy associated to his profile.

c) A DataBase (DB): It collects all user data (user name, password, email, etc) in an organized manner to facilitate access, management and updating. The cross-platform document-oriented MongoDB [START_REF] Kyle | MongoDB in action[END_REF] database has been selected. d) Applications Servers (AS): For the sake of experiment, we have implemented two different application servers: a WebRTC server [START_REF]WebRTC Web Site[END_REF] which provides real-time peer-to-peer audio, video or data (i.e. multimedia) communications by leveraging a set of plugin-free APIs that are available in browsers and a WebSocket server [START_REF] Fette | The WebSocket Protocol[END_REF] which allows full duplex communication over a single TCP connection. It has been used to establish a bi-directional real-time message flow.

2) End User devices: There are two types of device managed by the end user. A smartphone which represents the primary user device and an IoT device which is the secondary user device. a) User primary device: We used Samsung Galaxy S8 powered with Android Oreo to initiate an authentication process and to perform either a audio/video call or chat in an instant messaging service. Therefore an application (apk) has been developed using Ionic [START_REF]Ionic Web Site[END_REF] framework. Ionic works with Cordova [START_REF]Cordova Plugin Web Site[END_REF] plugins for the use of some phone resources such as Bluetooth, Camera, GPS, etc. Moreover, Ionic can also creates apk for Android, iOS or Windows systems.

b) User secondary device: We use the Next Generation IoT Platform (Pycom) [START_REF]Pycom Web Site[END_REF] which provides powerful and affordable MicroPython enabled, multi-network micro-controller development boards. FIPY board [START_REF]Pycom Web Site[END_REF] is the one we have chosen based on its network communication capabilities: BLE, LoRa, SigFox, LTE Cat-M and NB-IoT.

VI. CONCLUSION

This paper introduces an original and strong authentication method for cloud services from mobile phones. It combines an OTP-based approach with an IoT object as a secondary device. The proposal implements a multi-factor scheme using channel and device diversity. To avoid depending on the protocol security specificities instantiating a particular channel, we introduce a security layer which provides end-to-end encryption of each involved channel. A platform that implements this method has been developed and tested through the use case of authorization access to cloud services located in a trusted zone.

Fig. 1 .

 1 Fig. 1. Architecture of mobile authentication using an IoT device

Fig. 2 .

 2 Fig. 2. Data flow of Authentication Procedure

Fig. 3 .

 3 Fig. 3. Authentication and Authorization in a Trusted Area

Fig. 4 .

 4 Fig. 4. Platform Architecture

  t 1 is represented as a JWT (JSON Web Token) containing at least the u id and works as a session identifier. sec OT P is a random number generated at each authentication request. It is used as a seed in step 4 below. S : u id ; pwd =? DB{u id ; pwd} S → M : [t 1 , sec OT P ] LT E 3) M verifies that S generated the OTP secret sec OT P . Both received data are sent to O through a BLE link.

M : Generator(sec OT P ) =? S M → O : [t 1 , sec OT P ] BLE 4) O generates an OTP code (cod OT P ) by applying a function (f unc) involving sec OT P . cod OT P has a predefined validity period and is associated with t 1 to build a new credential (F2) needed to the second step of the authentication protocol. This second something you have factor is sent to S via a LoRa network. O : cod OT P = f unc OT P (sec OT P ) O → S : [t 1 , cod OT P ] LoRa 5) S computes its own version of the OTP code (Xcod OT P ) and compares it to the one contained in the credential (F2). If the data match, S validates the authentication. In anticipation of access authorization aspects analyzed in section V-A, S replies with an access token (t 2 ). We will explain in the section V-A how t 2 can be used to access to resources or services. S : cod OT P =? Xcod OT P S → O : [t 2 ] LoRa 6) O forwards the access token to M via the BLE link. O → M : [t 2 ] BLE

BLE: Bluetooth Low Energy

NFC: Near Field Communication

VII. ACKNOWLEDGMENT

The authors thank the company Acklio which graciously provided them with access to their LoRa network.

This work has received funding from the France Brittany region research and innovation program AAP PME 2016, under grant agreement number 16004254, V2OLTERES project. 1 OTP: One-Time Password Long Range Radio Wide Area Network


Samy Kambou
email: samy.kambou@imt-atlantique.fr

Ahmed Bouabdallah
email: ahmed.bouabdallah@imt-atlantique.fr

Using structural diversity to enforce strong authentication of mobiles to the cloud

Keywords: authentication, multi-factor authentication, internet of things, one-time password, diversity, cloud-based web service, OpenId Connect

Modern portable devices such as smartphones are enhanced by advanced functionalities and may therefore soon become both the preferred portable computing device (thereby substituting laptops) and the personal trusted device. They are also increasingly used to access to online cloud services, including those particularly sensitive which require high security. This paper introduces an original and strong authentication method for mobiles. It involves a two factor scheme enhanced through network channels and devices diversity. Our solution combines an OTP-based approach using an IoT object as secondary device in addition to the smartphone. The diversity of the network's channels rests on the use of one of the LPWAN networks together with LTE or WIFI networks. Authentication factors are therefore transmitted over different channels through different devices thus greatly reducing the attack surface. The proposal is also enhanced by end-to-end encryption of the transferred sensitive contents. The link with the authorization issues is analyzed and the integration of our approach to OpenID Connect/OAuth 2.0 is investigated. A platform that implements this scheme has been developed, tested and evaluated under different attack scenarios.

I. INTRODUCTION

Due to the rapid development of wireless technologies, Internet services and cloud capabilities, many companies are deploying part of their information system in the cloud and opening it to their different partners. It is therefore crucial to know the company's protected resources and services and to restrict the access to legitimate users. Mobile network operators for example define subscriber profiles which are made of several kinds of services. Customer who has subscribed to particular services must be able to access them as soon as he registers. Operators must therefore provide access while protecting their infrastructure from illegal access attempts by a person who has not subscribed to those services. Usually, the first step is to authenticate subscribers by checking the validity of proof of their identity.

Likewise, user authentication from a smartphone is a common requirement for cloud-based web services, as more and more personalized and controlled access services are operating online. Being the explicit support of the mobility capability This work has received funding from the France Brittany region research and innovation program AAP PME 2016, under grant agreement number 16004254, V2OLTERES project.

gives the smartphone the privilege of accompanying its owner everywhere. It is therefore inevitable that it will gradually become the indispensable companion for all daily tasks while inaugurating a real change of use by allowing a subscriber to access permanently and from anywhere to the majority of online cloud services. From the security point of view, the smartphone is also gradually moving from the position of secondary device to the one of primary device (formerly occupied by the traditional computer). Unfortunately, several services always use weak authentication solutions (traditional log-in/password) that are vulnerable to attacks. To ensure that subscribers are who they claim to be, modern systems that imposed a higher level of security must integrate robust identity protection based on strong authentication approach.

In this paper, we study and develop an authentication protocol that delivers a higher level of authentication assurance based on two-factor authentication [START_REF] Roberto | A two-factor mobile authentication scheme for secure financial transactions[END_REF] and OTP (One-Time Password) [START_REF] Eldefrawy | OTP-Based Two-Factor Authentication Using Mobile Phones[END_REF] [START_REF] Aloul | Two factor authentication using mobile phones[END_REF]. The proposed solution involves the use of two handheld devices:

• A mobile phone to submit the first authentication factor and then directly access a secure web service, • A smart-Thing [START_REF] Kuniavsky | Smart things: ubiquitous computing user experience design[END_REF] which provides another wireless link, such as one of the Low-Power Wide-Area Networks (LPWAN) family [START_REF] Krupka | The issue of LPWAN technology coexistence in IoT environment[END_REF] and allows to exchange the second OTP-based authentication factor.

To enhance security, each wireless link is secured with an efficient end-to-end encryption algorithm. Therefore, making it more difficult for attackers to undertake traditional attacks such as phishing, eavesdropping, man-in-the-middle, hijacking, replay, online guessing, brute force, etc. To the best of our knowledge, there have been no other authentication scheme proposed in the literature that use a LPWAN network as an alternative channel to provide two-factor authentication from a mobile phone to cloud-based web services. Authentication is the first step leading to access to controlled or AAA1 networks [6] [7]. The possible solutions to articulate the proposed authentication approach with the authorization issues to access to controlled resources or services are investigated. We show how the integration of our approach to OpenId Connect [START_REF] Sakimura | OpenID Connect Core 1.0 incorporating errata set 1[END_REF] and OAuth 2.0 [START_REF] Hardt | The OAuth 2.0 Authorization Framework[END_REF] frameworks can be done.

A Proof of Concept has been conducted to experimentally evaluate the proposed method.

The paper begins with some examples of multi-factor authentication schemes and a brief introduction to the IoT environment. Next, we present the proposed strong authentication method and describe in detail the authentication protocol together with its security evaluation. The articulation of our authentication approach with authorization issues is also discussed. At the end, we describe the proof of concept used to test our scheme.

II. RELATED WORKS A. Multi-factor Authentication

Multi-factor authentication is a security mechanism that requires more than one category of credentials used for identity verification. These categories of credentials are called authentication factors and the most commonly used are :

• A Knowledge factor (Kf): referred to as something you know, which is information known by users that they submit for authentication process, e.g. password, personal identification number (PIN), etc. • A Possession factor (Pf): referred to as something you have, which is something that users must have in their possession for authentication, e.g. hardware token, ID card, smart-phone or smart-Things etc. • An Inheritance factor (If): referred to as something you are, which are biometric characteristics of users that are compared during authentication process, e.g. fingerprint, facial, iris or voice recognition, DNA, etc. The multi-factor credentials are managed by one or more devices and in the latter case the one from which the authentication involving the first factor is called the primary device. Several multi-factor authentication systems have been proposed for a wide variety of purposes. We focus on some of the most recently proposed mobile-based authentication methods. TDAS [START_REF] Teh | TDAS: a touch dynamics based multi-factor authentication solution for mobile devices[END_REF] is a touch dynamics based multi-factor authentication system for mobile devices. The proposed approach aims to study the feasibility and benefits of adopting an authentication method based on touch dynamics mechanism (If ) by integrating it with the PIN-based authentication method (Kf ). The authors presented how the data set may be used to strengthen the protection of resources that are accessible on mobile devices. Another approach is by Crossman and Liu [START_REF] Crossman | Two-factor authentication through near field communication[END_REF], who propose a two-factor authentication based on NFC 2 smart-phone devices. Firstly, the user is asked to enter a password (Kf ) which unlocks the protection of the key on its mobile phone acting as primary device. Then, the key (Pf ) located in a passive object acting as secondary device, is transferred through NFC to complete the authentication process. In this system, the two factors are managed by the same mobile phone. This assumes a central point of vulnerability that can potentially be used by an attacker. Indeed, if the mobile phone is compromised, the two authentication factors will be easily available.

2 NFC : Near Field Communication Barkadehi et al. [13] proposed another two-factor authentication system by using the mobile phone as a mirror. In their approach, a web application launched from a desktop uses a log-in with a password as an authentication factor (Kf ) in the first step and then a white box will be shown to the users. They can not see at first the mouse cursor in the box but must move their mouse in the box in order to click the right second password. By doing this, they receive a notification on their mobile phone (Pf ) to open a mirror application. Then, they must accept the received request to continue the authentication process, and they will see their web-based cursor on a shuffled keyboard in their mobile application. To conclude the authentication process, the users need to select their second password. After a valid authentication process, they will have access to a web service through their desktop.

We are convinced that the use of two factors in the authentication process strengthens it in an interesting way. We argue, however, that its interest in reducing the attack surface of the authentication process can be advantageously improved by combining it with the use of multiple devices operating different protocol stacks. Our approach illustrates this point by using a smart-phone as primary device and a smart-Thing as secondary one.

B. IoT environment

With the rapid development of Internet services and wireless technologies, smart devices are well integrated into our daily life to provide customized IoT (Internet of things) to individuals. IoT interoperability appears as one of the greatest challenges for the IoT industrial environment [START_REF] Zhao | A Survey on the Internet of Things Security[END_REF] and limits the technology industry to achieve even larger IoT deployments. By achieving efficient interoperability between applications, sensors and networks, IoT is paving the way for the development of new and various services. Currently, smart-Things are able to interconnect, store data, send and receive commands to perform tasks requested by users. Heterogeneous system architectures are formed in which various types of devices and relevant communication techniques are deployed. Therefore, conventional security mechanisms [START_REF] Zhang | IoT security: ongoing challenges and research opportunities[END_REF] must be refined to fit the requirements from IoT environment.

An IoT device is integrated into our OTP-based two-factor authentication scheme. This smart-Thing must provide a network of LPWAN family such as LoRa or SigFox or one of the latest 3GPP technologies dedicated to the IoT which are LTE cat-M and NB-IoT technologies. The IoT device must be an active object. It must have its own power supply and be able to perform certain cryptographic operations.

III. STRONG MOBILE AUTHENTICATION SCHEME FOR WEB/MOBILE APPLICATIONS

Strong authentication is a technique relying on more than one authentication factor. By combining something you know and something you have, an adversary needs to physically steal your hardware token and also learn your password. This twofactor authentication scheme provides improved protection. In addition, communication channels' and devices' diversity is another way to further improve the security of an authentication system. By this way, attacks such as man in the middle or eavesdropping are much more difficult to carry out since the adversary must simultaneously control both channels and devices. We introduce below a strong authentication method on mobile phone that uses in addition an IoT device and exploits these two improvements.

To authenticate a user through his smartphone and using an IoT device as a security token, certain components must be in place. Fig. 1 shows the basic architecture and the main components used to design our strong authentication scheme. The user must have a smartphone (M ) connected to the Internet via the 3GPP LTE technology or WIFI network and also be in possession of an IoT device (O). Both devices must be equipped with a BLE 3 or NFC connection. With his mobile phone, the user can access to web services located in the cloud, subject to prior authentication. These services hosted by servers disseminated in the cloud are connected to S which is the front-end that will manage the authentication process. S is also connected to a LPWAN network (LoRa, SigFox, LTE Cat-M or NB-IoT) through Internet allowing the link with the IoT device O.

We propose a strong authentication scheme involving two distinct end user devices which communicate over different networks. One important point concerns the fact that both devices are controlled by the same user. This is ensured by a closed loop going through all the components involved in our architecture, illustrated in Fig. 1. The loop starts in the mobile phone requesting a service, goes through the network with S and then via the IoT device and back to the mobile phone. This closed loop can be realized in several ways. Below, we describe how to use it in the proposed strong authentication scheme.

IV. AUTHENTICATION PROTOCOL IN DETAIL

We first summarize in the following table, all the notations used in the descriptions below.

The protocol rests on several security services. We first describe the main steps of the protocol while abstracting security issues. We then provide a detailed account of the required underlying security services.

A. Protocol description

The proposed method rests on three distinct channels:

• a primary channel between the mobile phone M and the authentication server S • a secondary channel between S and the IOT device O • a tertiary channel between O and M In the developed prototype we instantiate these three categories respectively with LTE, LoRa and BLE. There are thus plenty of other choices which must however take into account the technical constraints imposed by the devices. These three channels require at least confidentiality and integrity for the exchanged messages. To avoid depending on the security specificities of the protocol used to instantiate a channel, we use a security layer detailed in section IV-B to independently guarantee the requirements necessary for each communication channel.

We now focus on the flow of information required for an authentication as outlined in Fig. 2, the steps of which are detailed below: 1) By using his mobile phone M , the user submits a username (u id ) and password (pwd) to the authentication server S. These credentials (F1) are transmitted over an LTE link. This is the initial step of the authentication protocol during which the first Kf factor is used.

M → S : [u id , pwd] LT E
2) S verifies the received data. If the data match with those stored in the database (DB), S replies with an authentication token (t 1 ) and an OTP secret (sec OT P ).

B. Security enforcement of the protocol

Security brings a panoply of challenges in the authentication protocol design. It is therefore very difficult to build a secure authentication protocol [START_REF] Abadi | Prudent engineering practice for cryptographic protocols[END_REF]. Formal proofs could provide guarantees on the correctness of the protocol. However failing to provide a formal proof which at the time of writing this paper is still in progress, introduce below the sound principles followed in the design of this protocol.

Firstly, OTP is introduced in our proposal as the second authentication factor. The OTP codes are generated by the IoT device (Pf ) and can therefore appear totally random. As the name suggests, each OTP code is only used once. By changing each time an OTP code is needed, OTP solution introduces liveness. This is an important issue in security.

Secondly, we took advantage of JWT [START_REF] Jones | JSON Web Token (JWT)[END_REF] which are tokens using a container to transport data between interested parties in JSON. These tokens are base64-encoded. We use them to authenticate all exchanged requests in a RESTFUL approach. They are defined with an expiration time that avoids forever valid tokens. The tokens are also protected against replay attacks by applying timestamps.

Thirdly, the three communication channels are secured with encryption algorithms.

1) LTE Channel: Mobile Phone ↔ Authentication Server

• Key Agreement: Before any data transmission, ECDH(E) (Elliptic Curve DiffieHellman, where final "E" stands for "ephemeral") and ECDSA (Elliptic Curve Digital Signature Algorithm) algorithms are used to create a secure channel between each mobile phone and the authentication server. These algorithms allow to define a trusted session key (ms). ECDH [START_REF] Maryam | Diffie-Hellman and its application in security protocols[END_REF] is a well-known key agreement protocol used to define a shared secret over an insecure channel. Each involved party must have an elliptic curve public-private key pair. ECDH(E) is a variant of ECDH which provides temporary key pair instead of trusted static key pairs (via a certificate). ECDSA [START_REF] Don | The elliptic curve digital signature algorithm (ECDSA)[END_REF] is a variant of Digital Signature Algorithm (DSA) which uses the elliptic curve cryptography. This algorithm is used by a signatory to affix a digital signature on data and by a checker to prove the validity of the signature.

Each party involved has a public-private key pair. The private key operates in the signature generation process and the public key is used for the signature verification. ECDSA provides message authentication, integrity and non-repudiation. a) M generates its keys pair (K priv m , K pub m ) and sends its public key and its signature to S.

M :

K priv m , K pub m M : Sg K pub m (h 1 (id m )) M → S : [K pub m , Sg K pub m (h 1 (id m ))
] LT E b) S verifies the received signature to ensure that the data come from M (we make the assumption that S has previously registered the respective identities of all the legitimate devices which can be used for a user authentication). If the data come from a known device, S generates its pair of keys (K priv s , K pub s ). Then, it computes the session key (ms) using its private key and the public key of M . Finally, S replies to M with its public key and its signature.

S : XSg K pub m (h 1 (id m )) =?Sg K pub m (h 1 (id m )) S : K priv s , K pub s S : ms = Compute [K priv s , K pub m ] S → M : [K pub s , Sg K pub s (h 1 (id s ))] LT E
c) M verifies the received signature to ensure that the data come from S (we make the assumption that M has previously registered the identity of the authentication server S). Then M computes the session key (ms) using its private key and the public key of S. M :

XSg K pub s (h 1 (id s )) =?Sg K pub s (h 1 (id s )) M : ms = Compute [K priv m , K pub s ]
• Symmetric Encryption: After this negotiation, the channel is secured with the AES cipher [START_REF] Saicheur | An implementation of AES-128 and AES-512 on Apple mobile processor[END_REF] (standard recommended by NIST) using the session key (ms) to provide end-to-end data encryption and integrity (E ms ( * )). Furthermore, OTP secret is signed (Sg idm ( * )) by the authentication server using the mobile identifier as a seed. Thus, the secure data are completely binded to a specific mobile phone which is by the way ensured that sensitive information received on this channel come from the authentication server.

V. SECURITY EVALUATION

This section presents a security assessment of the proposed strong authentication method. This assessment is divided into four different scenarios. Each scenario examines potential threats and then discusses possible countermeasures.

A. Scenario I : End user devices

Threats:

• Physical attack : an adversary might try to steal the user devices to impersonate a legitimate user. • Software attack : a malicious application can gain access to sensitive data stored on mobile phone or IoT device. • Spoofing : an attacker might try to tamper with the IoT device to learn the shared key. Countermeasures:

• Trusted Execution Environment (TEE) [START_REF] Pinto | IIoTEED: An Enhanced, Trusted Execution Environment for Industrial IoT Edge Devices[END_REF] is created to allow mobile phones and connected objects to achieve their requirements for speed and security. It is an isolated area inside the main processor that verifies the confidentiality and integrity of the code and information loaded in the TEE. • Security Encrypted (SE) [START_REF] Anwar | An alternate secure element access control for NFC enabled Android smartphones[END_REF] is a tamper-resistant chip inside the modern mobile devices. It is completely separated from the main processor with its own CPU, RAM and persistent memory. It provides a very high level of security by saving sensitive information such as secret keys and nothing stored inside can be uploaded by an attacker. • End user devices can easily be revoked by the authentication server in case of theft thanks to their unique identifier used during the authentication process.

B. Scenario II : Channel Mobile Phone -Authentication Server

Threats:

• Phishing : an adversary might try to impersonate a user by guessing his password. • Eavesdropping : an attacker might try to eavesdrop on the link to learn the OTP secret. • Man-in-the-middle (MITM) : an adversary might try to position himself between the user mobile phone and the authentication server in order to read or/and alter all information. Countermeasures:

• The proposed scheme is protected with the user chosen password. This results in a two-factor authentication preventing misuse of stolen password even more a hash version of password is transmitted over the network and not the plain text password. • The well-known cryptographic algorithm AES is used to avoid eavesdropping and MITM attacks. In additional, the OTP secret is signed by the authentication server. Thus, the secure data are intended for a given mobile phone that ensures that received information come from the real authentication server.

C. Scenario III : Channel Mobile Phone -IoT device

Threats:

• Online guessing or dictionary attack: an attacker might try to listen on the BLE channel to learn sensitive information.

Countermeasures:

• The BLE channel is secured with a symmetric encryption algorithm (AES) to perform end-to-end data encryption and integrity. In addition, the data being transferred over this BLE channel, are a token and a secret which are already secure by introducing liveness.

D. Scenario IV : Channel IoT device -Authentication Server

Threats:

• Hijacking : an adversary might try to hijacking the authentication token to get unauthorized access. • Replay attack : an adversary might try to repeat or delay a valid sensitive data. Countermeasures:

• The link between the IoT device and the authentication server is secured by a symmetric encryption algorithm (AES) to provide end-to-end data encryption and integrity over the link. • The tokens are protected against replay attacks by using timestamps. • OTP codes are not possible to guess since they appear as random numbers. Each code is only used once.

VI. ACCESS TO SERVICES

AAA networks [6] [7] provide resources that can be accessed by users following different authorization policies. Authentication is the first step to manage access to previously registered users. In this part, we investigate a possible solution to articulate our new authentication scheme with the authorization control to access to resources or services. In a previous work, we studied the particular case of services located in a trusted area [START_REF] Kambou | A Strong Authentication Method for Web/Mobile Services[END_REF] which is very common in practice. We investigate here the general case ("untrusted" area). We show how our strong authentication approach can be integrated into the OpenId Connect [START_REF] Sakimura | OpenID Connect Core 1.0 incorporating errata set 1[END_REF] and OAuth 2.0 [10] frameworks.

A globally "untrusted" area may consist of several trusted islands representing distinct administrative domains operated by different actors. Depending on the trust relationship between these different actors, it often happens that a successful authentication to access a resource in one domain is reused to access another resource of a second one. Even if we do not deal with the issues of the federation of domains and the Single Sign One (SSO), we choose the approach based on OpenId Connect [START_REF] Sakimura | OpenID Connect Core 1.0 incorporating errata set 1[END_REF] and OAuth 2.0 [START_REF] Hardt | The OAuth 2.0 Authorization Framework[END_REF] which may easily be enriched to support the SSO use case.

A. Authentication and Authorization in the Cloud

Access delegation has generated a lot of interest and work to finally lead through OAuth 2.0 [START_REF] Hardt | The OAuth 2.0 Authorization Framework[END_REF] to a relatively stable and proven solution [START_REF] Fett | The Web SSO Standard OpenID Connect: In-Depth Formal Security Analysis and Security Guidelines[END_REF] that has become essential for the development of the Cloud. By underestimating the importance of authentication, the initial proposal of OAuth created one of its own major weakness. The introduction of OpenID Connect [START_REF] Sakimura | OpenID Connect Core 1.0 incorporating errata set 1[END_REF] as an identity layer on top of the OAuth 2.0 protocol solved the issue. OpenId Connect with OAuth 2.0 can be used to manage the access to an application server called RP (Relying Party) providing resources or services. This access requires a preliminary authentication step summarized by the generation by an IdP (Identity Provider) of an IdToken for the authentication and an AccessToken for the authorization. The approach is sufficiently flexible and rich to be adapted to multiple configurations. The standard lists four main configurations [START_REF] Hardt | The OAuth 2.0 Authorization Framework[END_REF], of which we indicate below the mode Code Authorization considered the most secure [START_REF] Fett | The Web SSO Standard OpenID Connect: In-Depth Formal Security Analysis and Security Guidelines[END_REF].

B. Our solution

OpenId Connect associated to OAuth 2.0 provides a flexible framework the modularity of which can be exploited to integrate the proposed strong authentication method. This one is used as a preliminary step before controlling the access to an application server represented by RP in Fig. 4. We associate the IdP with our previous authentication server S to form a complete Authentication and Authorization Server named S/IdP .

The main idea consists in substituting to the basic authentication step (cf. "green block" of Fig. 3), our two factors method based on channel and device diversity. Due to constraints related to IoT environment, the integration of our twofactor authentication scheme with OpenId Connect/OAuth 2.0 requires several adaptations. The messages from S/IdP to O may contain a significant amount of information (Authtoken2, Code, State and Issuer) the processing of which will require high power consumption for the IoT device. Moreover, due to efficiency reasons applications on mobile phone are rarely browser-based. They are usually implemented as specific binaries one can download from some applications' store. For our purpose, we developed a dedicated one noted apk in Fig. 4. It

VII. PROOF OF CONCEPT

A platform has been developed to experimentally evaluate the proposed method. It rests on two open source certified OpenID Connect implementations: node openid-provider [24] and node openid-client [25] representing the IdP and the RP respectively. We experiment our approach using the two wellknown services WebRTC and WebSocket represented by RP 1 and RP 2 in Fig. 5. This one shows the proposed architecture where two main parts can be distinguished. The first represents the "untrusted" area (i.e. the cloud) in which different servers have been implemented using mainly the open-source, crossplatform JavaScript run-time environment, called Node JS [26] [27]. The second part puts together the end user devices.

A. Cloud components

The cloud area contains a powerful physical infrastructure that uses virtualization software to provide three virtual servers. In addition, two application servers from different This component collects all users information (name, password, address, email, etc) in an organized way so that data are easy to access, manage and update. For this component, we used MongoDB [START_REF] Kyle | MongoDB in action[END_REF] [29] which is a well-known cross-platform documentoriented database. • Authentication and Authorization Servers (S/IdP ): Authentication server is one of the main component of the platform. It processes and responds to requests in order to determine if previously registered users are really who they claim to be. Authorization process occurs after a user is successfully authenticated. Its purpose is to determine precisely if an authenticated user has access to the requested resources or services by evaluating the authorization policy associated to his profile. • Applications Servers: Different application servers can be deployed in the cloud. This approach requires a minimum security effort since web servers are distributed in an "unsecured" area and can be accessed by everyone. Therefore HTTPS) is used for any data exchange with the deployed servers. For the sake of experiment, we have implemented two application servers located in two different domains with digital certificates for encrypting the communication protocol (HTTPS):

-The WebRTC server (RP1) [START_REF]WebRTC Web Site[END_REF] which provides realtime peer-to-peer audio, video or data (i.e. multimedia) communications by leveraging a set of pluginfree APIs that can be operated in both mobile phone and desktop browsers. Previously, external plugins were needed to obtain similar features to those offered by WebRTC. -The WebSocket server (RP2) [START_REF] Fette | The WebSocket Protocol[END_REF] for a Chat Message Service. Websocket is an application layer protocol that allows full duplex communication over a single TCP connection. That protocol is used for a bidirectional real-time message flow in our application.

B. End User devices

There are two types of device managed by the end user. A smartphone or a tablet running under Android Oreo that represent the primary user device and an IoT device as the secondary one.

1) User primary device: The mobile phone (Samsung Galaxy S8) or the tablet (Samsung Galaxy Tab S3) is used to initiate an authentication process, and to perform either a We-bRTC audio video call or chat in an instant messaging service. For this purpose, we used Ionic [START_REF]Ionic Web Site[END_REF], which is an open-source hybrid mobile application development framework, to develop a mobile application (apk). Ionic uses Cordova plugins [START_REF]Cordova Plugin Web Site[END_REF] to access to the mobile phone or tablet features such as GPS, bluetooth, camera, microphone, etc. Furthermore, Ionic can build apk for Android, iOS, or Windows.

2) User secondary device: As a secondary user device, we use the Next Generation IoT Platform (Pycom) [START_REF]Pycom Web Site[END_REF] which provides powerful and affordable MicroPython enabled, multinetwork micro-controller development boards. According to our needs in terms of communication capability, we have chosen the latest Pycom product on the current market. This is the FiPy board [35] which allows the following five communication stacks: BLE, LoRa, SigFox, LTE Cat-M and NB-IoT.

In the IoT environment, energy issues are critical. The hardware selected for our experiments makes it possible to explore the problem in an extensive way because of the numerous protocol stacks proposed, but it is however expensive in terms of energy consumption. We introduce a switch that obeys the automaton below (Fig. 6) in order to avoid energy waste. The proposed solution to control the device energy consumption is quite simple. We have set two possible operating modes that form the behavior of the IoT device:

• An Active Mode in which all processes are initialized and ready. The IoT device waits for an authentication request via a BLE connection from the mobile phone, then computes the OTP code, encrypts the data and exchanges them with the authentication server via a LoRa network. At the end, the result of the authentication request is sent back to the mobile phone.

Fig. 1 .

 1 Fig. 1. Architecture of mobile authentication using an IoT device

  3 BLE : Bluetooth Low Energy

5 )

 5 S computes its own version of the OTP code (Xcod OT P ) and compares it to the one contained in the credential (F2). If the data match, S validates the authentication. In anticipation of access authorization aspects analysed in section VI, S replies with an access token (t 2 ). We will explain in the section VI how t 2 can be used to access to resources or services.S : cod OT P =?Xcod OT P S → O : [t 2 ] LoRa6) O forwards the access token to M via the BLE link. O → M : [t 2 ] BLE

Fig. 2 .

 2 Fig. 2. Data flow of Authentication Procedure

Fig. 3 .

 3 Fig.3. OIDC call flow -Code Authorization[START_REF] Fett | The Web SSO Standard OpenID Connect: In-Depth Formal Security Analysis and Security Guidelines[END_REF]

Fig. 4 .

 4 Fig. 4. Strong authentication call flow with OIDC from mobile phone application (apk) and browser

Fig. 5 .

 5 Fig. 5. Proof-of-concept Architecture

•

  Reverse Proxy Server (P ): This component is the entry point to the trusted area. It channels all requests from the Internet and then forwards them to authentication, authorization or application servers.• Data Base Server (DB):

Fig. 6 .

 6 Fig. 6. Automaton to manage the energy consumption of the IoT device

TABLE I NOTATIONS

 I

	Notations	Description
	u id	User identifier
	pwd	User password
	M	Mobile phone
	O	IoT device
	S	Authentication server
	idm	Mobile phone identifier
	ids	Server identifier
	t 1	Authentication token
	t 2	Access token
	sec OT P	OTP secret
	cod OT P	OTP code
	K priv *	Private key
	K pub *	Public key
	h 1 , h 2	Hash functions
	Esec( * )	Encrypt function with the secret sec
	Sgsee( * )	Signature encryption with the seed see
	XSgsee( * )	Signature verification with the seed see

  t 1 is represented as a JWT (JSON Web Token) containing at least the u id and works as a session identifier. sec OT P M verifies that S generated the OTP secret sec OT P . Both received data are sent to O through a BLE link. M : Generator(sec OT P ) =? S M → O : [t 1 , sec OT P ] BLE 4) O generates an OTP code (cod OT P ) by applying a function (f unc) involving sec OT P . cod OT P has a predefined validity period and is associated with t 1 to build a new credential (F2) needed to the second step of the authentication protocol. This second Pf factor is sent to S via a LoRa network. O : cod OT P = f unc OT P (sec OT P ) O → S : [t 1 , cod OT P ] LoRa

is a random number generated at each authentication request. It is used as a seed in step 4 below. S : u id ; pwd =? DB{u id ; pwd} S → M : [t 1 , sec OT P ] LT E

3)

  Authentication ServerThis link is secured with the AES cipher with 128-bit pre-shared key length (so) to provide end-to-end data encryption. Step 4 and step 5 of IV-A are refined below:O → S : [E ms (t 1 ), E so (cod OT P )] LoRa S → O : [E so (E ms (t 2 ))] LoRa

The complete respective expressions of step 1 and 2 introduced in section IV-A are thus:

M → S : [E ms (u id ), E ms (h 2 (pwd))] LT E S → M : [E ms (t 1 ), Sg id M (E ms (sec OT P ))] LT E 2) BLE Channel: Mobile Phone ↔ IoT device

This channel is secured with the AES symmetric encryption scheme. More precisely, the AES cipher with 128-bit pre-shared key length (mo) is implemented to provide end-to-end data encryption. The data being transferred over this channel are tokens and OTP secrets which are already secure.

Step 3 and step 6 of IV-A are refined below:

M → O : [E mo (E ms (t 1 )), E mo (sec OT P )] BLE O → M : [E mo (E ms (t 2 ))] BLE

3) LoRa Channel: IoT device ↔

AAA : Authentication, Authorization and Accounting

• A Deep Sleep Mode: By pressing a push button, the IoT

device saves its status (networking) and stops all main processes and stacks.

7 shows the variation in energy consumption according to the IoT device's operating mode. In active mode the average consumption is approximately 165 mA and in deep sleep mode the average consumption drops to 0.33 mA.

VIII. FUTURE WORKS

The proposal implements a two-factor authentication using the diversity of channels and devices. End-to-end encryption of each involved channel enforces the overall security of the protocol. Its extension to more than two factors could be considered. For example, a method involving in additional contextual factors such as "time" or "location" would likely improve the robustness of the authentication scheme.

The proposed method involves a first traditional factor (login/password) enforced by a second strong factor based on OTP. It offers an interesting framework to study the substitution of the first factor by other user friendly and cheap authentication methods. This issue concerns the development of an authentication method which is simultaneously highly robust, ergonomic and user friendly.

A platform that implements this method has been developed, tested and evaluated under different attack scenarios. This first assessment of the robustness of the presented protocol will be completed by a comprehensive analysis involving formal proofs.

IX. CONCLUSION

This paper proposed an original and strong authentication method dedicated to mobile phones resting on IoT devices. The user owning an LPWAN-enabled hand-held device may directly access any cloud-based web service through his mobile phone. To the best of our knowledge, this is the first authentication scheme using an LPWAN network as an alternative channel to provide two-factor authentication from a mobile phone to cloud-based web services. Using an IoT device as an authentication token provides a very flexible and secure solution. It appears as a very interesting alternative to all the existing authentication solutions that use the mobile phone as a security token. Smart things for authentication are very likely to become a popular choice for many users and companies in the near future.

The web services which can be accessed through the mobile phone are located in the Cloud. Our authentication method is integrated in a general framework like OpenId Connect articulating at the same time this work with authorization and federation approaches. The first results show how the integration of our approach can be done to the framework of OpenId Connect and OAuth 2.0.

X. ACKNOWLEDGMENT

The authors thank the company Acklio which graciously provided them with access to their LoRa network.


Improving strong mobile authentication with structural diversity and user-friendliness Samy Kambou & Ahmed Bouabdallah

IMT Atlantique IRISA, UMR CNRS 6074 F-35576 Cesson Sévigné, France {samy.kambou, ahmed.bouabdallah}@imt-atlantique.fr Abstract-This paper introduces an original and strong authentication method using a two-factor scheme enhanced by network channels and devices diversity. The proposed solution combines an OTP-based approach using an IoT object as secondary device in addition to the mobile phone. Authentication factors are transmitted over different channels (LTE, LPWAN, ...) via different devices thus greatly reducing the attack surface. To avoid depending on the protocol security specificities used to instantiate a channel, we use a security layer ensuring end-toend encryption of the transferred sensitive contents. In addition, diversity can be leveraged by exploiting its inherent modularity to infer other approaches. We give an example of another authentication method equivalent for the robustness to the first one but which is more ergonomic and user friendly.

Index Terms-strong authentication, multi-factor authentication, internet of things, one-time password, diversity, ergonomic authentication

I. INTRODUCTION

The improvement of smartphones with their advanced features has gradually made them the preferred portable computing devices (replacing laptops) and personal trust devices. They are also increasingly used to access online services, including those particularly sensitive and/or critical ones requiring high security. Generally, the technique used consists in authenticating the subscribers by verifying the validity of the proof of their identity. Even if user authentication is a common requirement for those Web/Mobile online services, many still use weak authentication solutions (username/password) vulnerable to attacks. The design of modern systems combining mobility and criticality requires a higher level of security, which can only be achieved by incorporating robust identity protections based on strong authentication approaches.

Multi-factor authentication (MFA) [START_REF] Ometov | Multi-factor Authentication : A Survey[END_REF] has emerged as an effective way to fill gaps and strengthen initial authentication techniques based on a single factor. By deftly combining several simple one-factor authentication methods, they reduce the overall attack surface of the entire method and thus increase its robustness. When the authentication process requires as in our case, to remotely attest the authenticity of a claimed identity, we argue that the multi-factor principle must also be applied to the communication channels as well as to end point devices.

We investigate this view by designing a two-factor (2FA) method [START_REF] Eldefrawy | OTP-Based Two-Factor Authentication Using Mobile Phones[END_REF] resting on two distinct end points defined by a smartphone and a smart-Thing [START_REF] Kuniavsky | Smart things: ubiquitous computing user experience design[END_REF] and involving also distinct communication stacks when interacting with the authentication server. The mobile phone submits through LTE1 (Wi-Fi is also possible) the first factor to the authentication server. After its validation, this one bootstraps the second OTP2 based authentication by transferring a nonce to the smart-Thing through the mobile phone. The smart-Thing finally computes the challenge and directly sends it to the authentication server using a communication protocol from the LPWAN3 [START_REF] Krupka | The issue of LPWAN technology coexistence in IoT environment[END_REF] family. To remain independent of the security features of the various communication stacks used, we introduce a security communication layer which ensures end-to-end encryption for the sensitive data. To the best of our knowledge, there have been no other authentication scheme proposed that use an LPWAN network as an alternative channel to provide 2FA from a mobile to web services.

The paper starts by recalling some iconic examples of multifactor authentication schemes and a brief introduction to IoT4 environment. It continues with a presentation of the proposed strong authentication method with a detailed description and analysis of the authentication protocol. The paper is concluded with an illustration of the inherent modularity involved by the diversity. We give an example of derivation of another authentication method as robust as the first one but which is more ergonomic and user-friendly.

II. RELATED WORKS

A. Multi-factor Authentication

Several MFA systems have been proposed for a wide variety of purposes. Some of the most recently proposed mobile-based authentication are as follows.

TDAS [START_REF] Teh | TDAS: a touch dynamics based multi-factor authentication solution for mobile devices[END_REF] is a touch dynamics based MFA system for mobile devices. The proposed approach aims to study the feasibility and benefits of adopting an authentication method based on touch dynamics mechanism by integrating it with the PIN-based authentication method. The authors presented how the data set may be used to strengthen the protection of resources that are accessible on mobile devices.

Another approach is by Crossman and Liu [START_REF] Crossman | Two-factor authentication through near field communication[END_REF], who propose a 2FA based on NFC 5 smartphone devices. Firstly, users are asked to enter a password which unlocks the protection of the key on their mobile phones. Then, the key is transferred through NFC to complete the authentication process. In this system, the two factors are managed by the same mobile phone. This assumes a central point of vulnerability that can potentially be used by an attacker. Indeed, if the attacker compromises the mobile phone, the two authentication factors will be easily available.

Barkadehi et al. [START_REF] Barkadehi | A novel two-factor authentication system robust against shoulder surfing[END_REF] proposed another 2FA solution by using the mobile phone as a mirror. In their proposal, a web application uses a username/password as an authentication factor in the first step and then a white box will be shown to the users. The users cannot see the mouse cursor in the box but must move their mouse in the box in order to click the right second password. At the same time, they receive a notification on their mobile phone to open the mirror application. Then, they must accept the received request to continue the authentication process and they will see their web-based cursor on a shuffled keyboard in their mobile application. To conclude the authentication process, the users need to select their second password. After a valid authentication process, the users will have access to a web service through their laptop.

B. IoT environment

With the evolution of wireless networks and Internet services, intelligent objects are well integrated into our daily life to provide customized IoT to individuals. Currently, smart-Things are able to interconnect, store data, send and receive commands to perform tasks requested by users. Heterogeneous system architectures are formed, in which different types of smart devices and relevant communication techniques are deployed. Therefore, conventional security mechanisms [START_REF] Zhang | IoT security: ongoing challenges and research opportunities[END_REF] must be refined to fit the requirements from IoT environment.

We used an IoT device in the proposed OTP-based 2FA scheme. This smart-Thing must provide a network of the LPWAN family such as LoRa/SigFox networks or more recently the 3GPP technologies dedicated to the IoT which are LTE Cat-M and NB-IoT. The device must be an active object capable to perform cryptographic operations.

III. STRONG AUTHENTICATION FOR WEB SERVICES

Strong authentication is a technique relying on more than one authentication factor. By combining "something you have" defined as a Possession factor (Pf) and "something you know" representing a Knowledge factor (Kf), an attacker needs to physically steal your hardware token and also learn your password. This 2FA scheme provides improved protection. In addition, communication channels' and devices' diversity is another way to further improve the security of an authentication scheme. By this ways, attacks such as man in the middle 5 NFC : Near Field Communication or eavesdropping are much more difficult to carry out since the attacker must simultaneously control both channels and devices. We introduce below a strong authentication method on mobile using an IoT device and exploiting these two improvements.

To authenticate a user on his smartphone and using an IoT device as a security token, some components must be in place. Fig. 1 shows the basic architecture and the main components used to design the proposed strong authentication scheme. The user must have a smartphone (M ) connected to Internet through LTE or Wi-Fi and also be in possession of an IoT device (O). These two devices must be equipped with BLE 6or NFC technology that is increasingly be leveraged to create more mobile-friendly experiences. By using his mobile, the user can access to web services subject to prior authentication. The web services hosted by servers disseminated in the Cloud are connected to S which is the front-end that will manage the authentication process. S is also connected to a LPWAN network (LoRa/SigFox) via Internet allowing in this way its communication with O.

We propose a strong authentication scheme involving two distinct user's devices which communicate over different networks. One important point concerns the fact that both devices are controlled by the same user. This is ensured by a closed loop going through all the components involved in our architecture illustrated in Fig. 1. The loop starts in the mobile requesting the service, goes through the network with S and then via the IoT device and back to the mobile. This closed loop can be realized in several ways. Below, we describe how to use it in our strong authentication scheme.

IV. AUTHENTICATION PROTOCOL IN DETAIL

We first summarize in the following table, all the notations used in the descriptions below.

A. Protocol description

The proposed method rests on three distinct channels:

• a primary channel between the mobile phone M and the authentication server S • a secondary channel between S and the IoT device O encrypt function with the secret sec Sgsee( * )/XSgsee( * ) signature/verification with the seed see

• an inter device channel between O and M In the developed prototype, we instantiate these three categories respectively with LTE, LoRa and BLE. There are thus plenty of other choices which must however take into account the technical constraints imposed by the devices. These three channels require at least confidentiality and integrity for the exchanged messages. To avoid depending on the security features of the protocol used to instantiate a channel, we use a security layer detailed in section IV-B to independently guarantee the requirements for each communication channel.

We focus on the data flow required for an authentication as outlined in Fig. 2, the steps of which are detailed below: 1) By using his mobile phone M , the user submits a username (u id ) and password (pwd) to the authentication server S. These credentials (F1) are transmitted over an LTE link. This is the initial step of the authentication protocol during which the first Kf factor is used.

M → S : [u id , pwd] LT E
2) S verifies the received data. If the data match with those stored in the database (DB), S replies with an authentication token (t 1 ) and an OTP secret (sec OT P ).

B. Security enforcement of the protocol

Security brings a panoply of challenges in the authentication protocol design. It is therefore very difficult to build a secure authentication protocol [START_REF] Abadi | Prudent engineering practice for cryptographic protocols[END_REF]. Formal proofs could provide guarantees on the correctness of the protocol. However failing to provide a formal proof which at the time of writing this paper is still in progress, we introduce below the sound principles followed in the design of this protocol.

Firstly, OTP is used as the second authentication factor. The OTP codes are generated by the IoT device (Pf ) and can therefore appear totally random. Each OTP code is only used once. By changing each time a code is needed, OTP solution introduces liveness. This is an important security issue. Secondly, we took advantage of JWT (JSON Web Token) which are tokens using a container to transport data between interested parties in JSON. We use them to authenticate all exchanged requests in a RESTFUL approach. They are defined with an expiration time that avoids forever valid tokens. The tokens are also protected against replay attacks by applying timestamps. Finally, The three communication links are secured with encryption algorithms.

1) Channel Mobile Phone ↔ Authentication Server: a) Key Agreement: Before any data transmission, ECDH(E) (Elliptic Curve DiffieHellman, where final "E" stands for "ephemeral") and ECDSA (Elliptic Curve Digital Signature Algorithm) algorithms are used to create a secure channel between each mobile phone and the authentication server. These algorithms allow to define a trusted session key (ms). ECDH [START_REF] Maryam | Diffie-Hellman and its application in security protocols[END_REF] is a well-known key agreement protocol used to define a shared secret over an insecure channel. Each involved party must have an elliptic curve public-private key pair. ECDH(E) is a variant of ECDH which provides temporary key pair instead of trusted static key pairs (via a certificate). ECDSA [START_REF] Don | The elliptic curve digital signature algorithm (ECDSA)[END_REF] is a variant of Digital Signature Algorithm (DSA) which uses the elliptic curve cryptography. This algorithm is used by a signatory to affix a digital signature on data and by a checker to prove the validity of the signature. Each party involved has a public-private key pair. The private key operates in the signature generation process and the public key is used for the signature verification. ECDSA provides message authentication, integrity and non-repudiation.

• M generates its keys pair (K priv m , K pub m ) and sends its public key and its signature to S.

M :

K priv m , K pub m M : Sg K pub m (h 1 (id m )) M → S : [K pub m , Sg K pub m (h 1 (id m ))
] LT E • S verifies the received signature to ensure that the data come from M (we make the assumption that S has previously registered the respective identities of all the legitimate devices which can be used for a user authentication). If the data come from a known device, S generates its pair of keys (K priv s , K pub s ). Then, it computes the session key (ms) using its private key and the public key of M . Finally, S replies to M with its public key and its signature.

S :

XSg K pub m (h 1 (id m )) =?Sg K pub m (h 1 (id m )) S : K priv s , K pub s S : ms = Compute [K priv s , K pub m ] S → M : [K pub s , Sg K pub s (h 1 (id s ))] LT E
• M verifies the received signature to ensure that the data come from S (we make the assumption that M has previously registered the identity of the authentication server S). Then M computes the session key (ms) using its private key and the public key of S. M :

XSg K pub s (h 1 (id s )) =?Sg K pub s (h 1 (id s )) M : ms = Compute [K priv m , K pub s ]
b) Symmetric Encryption: After this negotiation, the channel is secured with the AES cipher [START_REF] Saicheur | An implementation of AES-128 and AES-512 on Apple mobile processor[END_REF] (standard recommended by NIST) using the session key (ms) to provide endto-end data encryption and integrity (E ms ( * )). Furthermore, OTP secret is signed (Sg idm ( * )) by the authentication server using the mobile identifier as a seed. Thus, the secure data are completely binded to a specific mobile phone which is by the way ensured that sensitive information received on this channel come from the authentication server. The complete respective expressions of step 1 and 2 introduced in section IV-A are:

M → S : [E ms (u id ), E ms (h 2 (pwd))] LT E S → M : [E ms (t 1 ), Sg id M (E ms (sec OT P ))] LT E
2) Channel Mobile Phone ↔ IoT device: This channel is secured with the AES symmetric encryption scheme. More precisely, the AES cipher with 128-bit pre-shared key length (mo) is implemented to provide end-to-end data encryption. The data being transferred over this channel are tokens and OTP secrets which are already secure. Step 3 and step 6 of IV-A are refined below:

M → O : [E mo (E ms (t 1 )), E mo (sec OT P )] BLE O → M : [E mo (E ms (t 2 ))] BLE
3) Channel IoT device ↔ Authentication Server: This link is secured with the AES cipher with 128-bit pre-shared key length (so) to provide end-to-end data encryption. Step 4 and step 5 of IV-A are refined below:

O → S : [E ms (t 1 ), E so (cod OT P )] LoRa S → O : [E so (E ms (t 2 ))] LoRa

V. LEVERAGING DIVERSITY OF THE PROPOSED METHOD A. Modularity of the authentication

The diversity of the proposed approach can be nicely leveraged to clarify the modular structure of the protocol. Fig. 3 gives an abstract representation of the main components of the protocol by emphasizing this diversity. The proposed approach consists of two separate phases each one centered on a device and articulated to each other via the authentication server S. We define the first phase φ 1 of our method as the one involving the first authentication factor password. Similarly, the second phase φ 2 is the one resting on the second factor OTP code. Each phase φ includes an ascending part written φ up defined by the transfer and the validation of the authentication factor and a descending one written φ down consisting in the distribution of the result towards the primary device:

• φ up 1 : PD → PC → S • φ down 1 : S → PC → PD • Articulation between the two phases : S • φ up 2 : S → PC → PD → IDC → SD → SC → S
: S → SC → SD → IDC → PD The robustness of the protocol is ensured by the second phase. We argue that the granularity of the previous decomposition can be leveraged to derive another protocol satisfying complementary requirements while keeping the same robustness. We are interested in what follows to improve the ergonomy of our approach. We will in this way focus on modifying the first phase which concerns the relation between the end user and his primary device. Such modification has to be transparent to the second phase.

B. Ergonomic alternative to password

As modern portable devices, smartphones have become widespread and are often used as the main gateways for many online services requiring authentication. However, traditional authentication method using username/password credentials may not be convenient or applicable in certain use cases. For example, people with difficulties in fine motor control or soldiers on a battlefield may not be able to enter their credentials in a timely manner. Furthermore, it has been demonstrated that username/password authentication causes serious security vulnerabilities for people and web services since they are easily guessed, difficult to manage across a variety of systems, susceptible to major hacks and stolen.

Biometric authentication is a system that uses a unique physiological characteristic of the user to replace the need for a username/password. Indeed, many persons already use fingerprint scanner on their smartphones to avoid manually typing a password every time they want to unlock their mobile. Using fingerprint approach to log into a web service can be a natural way to improve the robustness of the traditional username/password credentials and also make the authentication process fast and easy to use. In this section, we propose to substitute the first traditional password factor (Kf ) with a biometric factor defining an Inheritance factor If and referred as something you are. As illustrated in Fig. 4, fingerprint process is simple and intuitive. With his mobile M , a user just needs to rest his thumb on the mobile's fingerprint scanner. Once the user's thumbprint is locally confirmed, some data that codes the user's biometric identity is encrypted and transmitted to the authentication server S for verification. S decrypts that information and after its verification triggers the second phase.

VI. ACKNOWLEDGMENT

The authors thank the company Acklio which graciously provided them with access to their LoRa network.

VII. CONCLUSION

In this article, we have proposed an original and strong authentication method dedicated to mobile phones based on IoT devices. The user owning an LPWAN-enabled hand-held device may directly access any web-based service through his mobile phone. Using an IoT device as a secondary device provides a very flexible and secure solution appearing as a very interesting alternative. As far as we know, this is the first authentication scheme using an LPWAN network as an alternative link to provide two-factor authentication from a mobile to web services.

The proposed method involves a first traditional authentication factor enforced by a second factor based on OTP. The inherent modularity of the global approach allows the transparent substitution of the first factor by other user friendly and cheap authentication methods. We have shown how this works by moving from the first factor to a basic biometric technique. This last part concerns the development of an authentication method which is simultaneously highly robust, ergonomic and user friendly. It will deserve more attention and it will be systematically investigated in a future work. A test platform has been implemented to evaluate the feasibility of the proposed schemes.

Fig. 1 .

 1 Fig. 1. Architecture of mobile authentication using an IoT device

Fig. 2 .

 2 Fig. 2. Data flow of Authentication Procedure

Fig. 3 .

 3 Fig. 3. Generic two-factor mobile authentication (2FA)

Fig. 4 .

 4 Fig. 4. Fingerprint authentication with smartphone

LTE : Long Term Evolution

OTP : One-Time Password

LPWAN : Long Range Radio Wide Area Network

IoT : Internet of Things

BLE : Bluetooth Low Energy

This work has received funding from the France Brittany region research and innovation program AAP PME 2016, under grant agreement number 16004254, V2OLTERES project.