User Authentication Protocol Based on the Location Factor for a Mobile Environment

The way the internet is used by billions of users around the world has been revolutionized by mobile devices. The capabilities of smartphones are constantly growing, and the number of services available for mobile devices is also increasing. This undeniable trend makes smartphones terminals for accessing services that process confidential data, which make smartphones priceless targets of cyberattacks. Along with an increasing number of mobile services, the methods of securing the confidentiality, integrity and availability of systems used have also evolved and adapted to the capabilities of a mobile environment. One of the important security services is the user authentication process. This process often implements the postulates of strong authentication, multistage authentication based on factors from the knowledge, position and inherence categories. Unfortunately, the implementation of the factors belonging to these categories is not always possible due to the limitations of smartphones, such as the lack of interfaces for the implementation of biometrics or environmental factors - problems with network or internet access in various countries and regions. Therefore, there is a need to analyse the possibility of implementing a strong authentication process based on additional information about users, e.g., based on location data. The article analyses the requirements for the authentication process and authentication factors. Based on the performed analysis, the criteria that each authentication factor must meet were defined. This article presents a proposal for a user authentication protocol based on the location factor for a mobile environment. The method can be used in the case of problems with the implementation of strong authentication or as an additional authentication factor that increases the security of the user identity confirmation process. The presented protocol has been analysed in terms of performance, security and compliance with the requirements related to the authentication factors.


I. INTRODUCTION
The development of mobile technology has made smartphones terminals that allow the implementation of many key services, such as access to confidential information. For this reason, the user authentication process must be performed as securely as possible. Secure authentication of user identities is performed using multifactor authentication, a process that requires the use of more than one factor. This process can be conducted based on a user's knowledge, something that he possesses or a biometric feature [1]. The definition of The associate editor coordinating the review of this manuscript and approving it for publication was Barbara Masini . the strong authentication process is very similar. It consists of confirming a user's identity based on at least two factors belonging to different categories: knowledge, possession, and inherence [2], [3]. The abovementioned definitions show that the key to a secure authentication process is to ensure the greatest number of factors from different categories. Strong authentication is usually conducted by forcing the user of, e.g., e-banking, e-administration, etc. to enter a password (knowledge) and confirm possessing a device assigned to the user to which a one-time code is sent (possession). Undoubtedly, the advantages of this method include the simplicity of the implementation of the authentication mechanism [4]- [6]. Many systems are relying on this factor to VOLUME 10, 2022 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ comply with SCA requirements [2], [7]. However, there are many sources indicating that attacks on OTPs (One Time Passwords), such as SIM cloning, SIM swapping, and message intercepting, are real threats to the identity confirmation process [8], [9]. Moreover, if a one-time code is sent to a user as an SMS message, the range of the cellular network is required to perform the authentication process. If the code is delivered in the form of a push message, the user needs access to the internet. Therefore, the lack of network access may make strong user authentication impossible. Alternatively, the strong authentication process in a mobile environment uses a biometric element based on a fingerprint or facial scan of a user. The use of biometrics in the process of confirming a user's identity is the subject of numerous studies [10]- [13]. This method requires a device with a specific reader. Despite its popularity, a large group of users have devices that do not support biometric authentication. Therefore, to implement multifactor authentication in the absence of internet access or cellular network coverage, the factor of another group should be used. As part of the research conducted by the authors of this article, which is a continuation of research on the implementation of security services in a mobile environment [14], numerous studies on the authentication process and authentication factors were analysed. Based on the analysed sources, the authors defined the requirements that must be met by an authentication factor. Based on the presented requirements, a new group of authentication factors based on a user's location data has been presented. There are many studies that seek to define the authentication process. Each of them indicates that the authentication process consists of confirming a user's identity [1], [2], [3], [15]. Such a definition of authentication can be used to define one of the requirements related to an authentication factor. An authentication factor must uniquely identify the user. Further requirements result from the definition related to the authenticator. An authenticator is defined as a factor that a user possesses or controls and can be used to authenticate a subject's identity [1]. The definition emphasizes the need to associate an authentication factor with a user. Based on this definition, a further requirement for an authentication factor can be defined. An authentication factor must be controlled by a user. Moreover, an authentication factor must be bound to exactly one user. According to the definitions included in the presented sources, authentication is the process of verifying the identity declared by a user. During this process, the pattern data provided to the system during the registration process are compared with the data provided during the authentication attempt to confirm that the user's identity is true. The identity confirmation process can be conducted based on a factor from the categories of knowledge, possession or biometrics. The analysed regulations define the requirements for the enrolment phase [1], [3]. These requirements indicate that the system performing the user authentication process must collect the appropriate data required to confirm and verify a user's identity. Therefore, it should be ensured that the pattern data that will be compared during the identity confirmation process (Table 1) will be obtained and associated with a user before the authentication process is conducted. The conducted analysis shows that the authentication factors from the knowledge, possession and inherence categories meet the criteria established based on the quoted norms and standards. Therefore, if the proposed solution based on a user's location data is to be an authentication factor or a supporting authentication factor, it must also meet the criteria summarized in Table 1. The collected requirements can help to assess whether the proposed authentication factor using a user's location data can be treated as an authentication factor and whether it truly performs the confirmation process of a user's identity and not the task of authorizing access to services. Solutions that use information about a user's location are gaining increasingly more popularity. The use of a location interface is associated with numerous problems, such as the problem with determining the identity of an authenticated entity or relatively low accuracy of information about a location. Moreover, information about a user's location is susceptible to spoofing at the hardware level or at the operating system level [16]. Solving the problem of obtaining a confirmed device location is not the same as solving the issue of using location as an authentication factor as long as the location is not bound to user identity. The use of coordinates representing a user's current location requires in-depth research into how this information can be used to confirm a user's declared identity.

II. RELATED WORKS
Many publications discuss the use of location data to increase the level of security. One way to use location data is to use them as a knowledge factor. A location is information remembered by a user and is entered as a type of password [17]. Using location information in such a way is an authentication process but must not be considered authentication based on location data. In this case, the location plays the role of the knowledge factor. The availability of a GPS interface and the ease of its use in determining the exact location increases the use of location data in processes conducted in a mobile environment. When analysing the latest publications, one of the directions of the user identity confirmation process is online authentication, also called continuous authentication [18]. Online authentication uses data collected by your smartphone and may be based on your location data. Data from a GPS interface or the location determined based on the Wi-Fi network are used by properly prepared classifiers. Based on these data, the algorithm determines whether the person who owns the device is its owner [19], [20]. Not all analysed publications use location data to perform authentication. Granting access to resources when staying in a declared city is the implementation of the authorization service and not confirming a user's identity. Some of the analysed protocols address the topic of confirming the accuracy of location data. The purpose of such solutions is to confirm that the location data are correct and unmodified. However, such information is insufficient to determine a user's identity. One of the ways to obtain information about the location of a device associated with a user is to determine its location based on the delay of the signal sent from the device to the surrounding network devices, e.g., Wi-Fi routers [21]. A user's location can be determined based on the IP address of the router to which a smartphone is connected. The location data obtained from the network provider are used to grant access to the service if the user is in the area declared during user account registration [22]. The analysed protocols actually use data on a user's location, but granting access based on the current location is the implementation of the authorization service, not authentication. Another publication [23] uses location data for the authentication process. However, these coordinates are not associated with a specific user but constitute additional information that can be used by a server to authorize access. As in the case of the previous article, another source [24] presents a scheme based on location data. It makes decisions about granting access to a service. Authorization is performed depending on whether the sent location is correct and whether there is any doubt about its modification. It should be emphasized that the published research lacks proposals regarding the use of user location data for user authentication. That is why this issue is taken up in our article.
In addition, it should be noted that the use of location data may pose a security risk. Information about a user's location can be very valuable to attackers. These issues have led many researchers to address the issue of using location data and ensuring their confidentiality at the same time [23]- [25]. The protocols proposed in these publications use location data and show how to use location data in a way that guarantees their safety in the event of a leak. One of the ways to ensure the confidentiality of a location is to use a schema that generates a k-1 ''dummy location'' [25]. In such a situation, the probability of information leakage about a user's location is reduced to 1/k. The confidentiality of user location data can be ensured by using encryption [23]. In the presented scheme, location data are sent to the server after they have been encrypted with a shared key. Another of the analysed solutions ensures the confidentiality of location data by encrypting the transmitted information [24]. The difference lies in the method of generating the key, which is established between the mobile application and the server. The key is generated based on the carrier frequency offset (CFO) resulting from the use of the Wi-Fi network. The obtained key is used to encrypt the frame consisting of the preamble, MAC header and transmitted data. The issue of using a user's location data with simultaneous location privacy has been considered in our research. Our protocol was designed to meet the requirements of location privacy. The presented solutions [23]- [25] increase the level of security of services but are limited to managing access to services based on data on a user's current location. Moreover, solutions that use only a location determined based on a Wi-Fi network face the problem of location accuracy. This problem prevents the use of location in the authentication process [24]. That is why our solution uses information about the location of the device based on three independent sources: GPS, Wi-Fi and data from the GSM network.
The computing power of smartphones has increased significantly, and these devices are equipped with an increasing number of various types of hardware interfaces. These conditions contributed to numerous studies on new, dedicated security mechanisms in a mobile environment. One of the interfaces from which data can be used to increase the security level is the GPS module. Due to the popularity of the use of location data positioning mechanisms, they have gained increasingly more importance. As research shows, efficiently determining the locations of devices within the assumed radius is not a difficult task. Location accuracy is influenced by the development of new technologies, including the growing popularity of 5G networks. An analysed publication [26] shows that the use of next-generation networks may increase the location accuracy based on the data of the cellular network. The proposed algorithm allows the exact location of a device inside a building to be determined. The location of a device is determined by dividing the coverage area into sectors using a UPA (uniform planar array). Data obtained from GPS, cameras, fingerprint readers, and the NFC interface can be used for the user authentication process. NFC enables communication between two devices, ensuring that these devices are in close proximity to the terminal [27]. One of the analysed multifactor authentication protocols [28] uses the knowledge factor, biometrics and the NFC interface as an implementation of the possession factor. NFC is used for communication between the devices of the sender and the payee. This protocol requires the recipient to confirm the identity of the sender of a payment.
According to the authors, by using the computing power of smartphones and their numerous interfaces (GPS and NFC), properly used data of a user's current location may constitute the fourth authentication factor that does not belong to any of the commonly known groups of authentication factors based on knowledge, possession, inherence. A similar approach was proposed in [29]. The authors of the article propose implementing a process that can be called authentication, not just authorization. The protocol uses location data obtained from a user's device and confirmation of its location by other users acting as witnesses. Packets prepared in this way are sent to an authentication server where the provided data are verified. It should be noted that this scheme authenticates not VOLUME 10, 2022 the user but the location data. This means that the location data, not the user's identity, are confirmed.

III. THE PROPOSED MULTIFACTOR AUTHENTICATION SCHEME
Considering the analysed publications, other research on multifactor authentication methods and the possibility of using location data, we present an authentication scheme based on information about a user's location. The protocol implements the identity confirmation process in two phases. The first stage consists of dynamically declaring a trusted area for a given user u i and temporarily assigning this area to only one user. The area is assigned to the user until authentication is completed or the EXP time (see Table 2 ) expires. The second step confirms that the authenticated user is in the predefined area. Information about the location of the authenticated user is obtained from various sources. A user's location data are confirmed by witness applications installed on the devices of other users nearby. During the first stage, called the declaration of a trusted area, the location is determined based on the interfaces of the mobile device (GPS, Wi-Fi, and cellular network). The coordinates used in the stage of confirming the declared location are obtained from a trusted source against which the user authenticates. For the purposes of the protocol, we assumed that this trusted source may be the POS (point of sale) terminal where the payment is made. The proposed authentication scheme is an extension of the multifactor authentication protocol described in the article ''Multifactor Authentication Protocol in a Mobile Environment'' [14]. The main goal of the research is to increase the level of security of the user identity confirmation process. One way to do this is to increase the number of authentication factors. The level of security can be increased by using factors from different groups (knowledge, possession, and inherence). The proposed protocol shows only the part of the authentication process that uses location data. It should be emphasized that the proposed protocol complements the previously presented multifactor authentication protocol in a mobile environment and can be implemented in the next stage of authentication. Alternatively, the proposed protocol can be used as an authentication factor from a different group in the case of limitations that prevent the use of other authentication factors, e.g., lack of biometric interfaces (inherence factor), no GSM network coverage to receive an SMS (possession factor) or no access to the internet (sending a push message).

A. SYSTEM ARCHITECTURE
A secure authentication protocol should be designed considering the possibilities of the environment in which it will be implemented. In the case of a mobile environment, security mechanisms provided by mobile platforms, e.g., Android, are extremely helpful. The presented authentication protocol based on location data is closely related to the capabilities of the mobile platform. The presented solution consists of the mobile application (MA) of user u i , which is authenticated; and the witness application (WA) installed on the device of another user located near user u i . The authentication process also uses a POS (POS) terminal, which is located in the place where the user attempts to authenticate. The last element of the system is a backend service consisting of an authentication service (AS), which uses firebase cloud messaging (FCM) as a notification service [30]. All elements of the system are shown in the diagram in Figure 1.

B. PREREQUISITES
The presented protocol uses the assumptions and initial conditions necessary for its implementation. The requirements assume that the identity of the user being authenticated is known and that all necessary data have been obtained during the protocol initialization and user registration phases. ''Necessary data'' refers to the data provided upon a user registration, examples could be user identity, password hash, mobile application identifier and device identifier. The registration process and the phase of key sharing are out of the scope of the article's research 1) AUTHENTICATION SERVICES 1) AS stores data of registered user u i who is identified by id i . 2) AS store fcmToki associated with ui. fcmToki is identifier in the FCM service. 3) AS securely stores the private key KPR_AS used to decrypt.

4) AS known KP_MAE, KP_MAS, KP_WA and KP_POS
can be used to encrypt and verify the signatures of messages. 5) AS knows the exact location of the POS and its identity. 6) If the first phase of the protocol is successful, the location sent by the user of the mobile application is locked. After the specified time has elapsed or the authentication process has finished, the location is available again to another user.
2) MOBILE APPLICATION 1) In the registration process, the application generates and stores two pairs of the RSA key with a length of 4096 bytes in the Android secure keystore. The first pair is used to implement digital signatures, and the second pair is used to decrypt the messages sent to the mobile application.
2) Because the proposed protocol consists of two phases, the application possesses two pairs of cryptographic keys. Diversification of the keys used may increase the security level of the protocol. 3) The application is able to use KP_AS to encrypt confidential data. 4) The application is installed on a device equipped with GPS. During the authentication process, the device is able to retrieve location data. The accuracy of the location data is very high. 5) The application is installed on a device equipped with an NFC interface. The user of the mobile application is able to place his own device close to the device of the user of the witness application and to the POS terminal.

3) WITNESS APPLICATION
1) In the registration process, the witness application generates and stores RSA keys with a length of 4096 bytes in the Android secure keystore. The private key is used to sign messages sent to the mobile application. 2) The application is able to use KP_AS to encrypt confidential data.
3) The application is installed on a device equipped with GPS. While supporting the authentication process of the user of the mobile application, the device is able to retrieve location data. The accuracy of the location data is very high. 4) The application is installed on a device equipped with an NFC interface. The user of the witness application is able to place his own device close to the device of the user of the mobile application.
C. PROPOSED USER AUTHENTICATION PROTOCOL 1) PHASE 1: DECLARATION OF TRUSTED USER LOCATION Figure 2 shows the first phase of the user authentication process based on a factor referring to a user's location. The first phase of the process considers the dynamic way in which the trusted location point is determined. The first phase of the protocol guarantees the confidentiality of sensitive data of all users involved in the exchange of messages. This is a reason why location data are encrypted with the public key of authentication services. All messages exchanged between the mobile application and witness application shall be transmitted via the NFC interface. The use of NFC limits the distance between the user performing the authentication process and the witness application of another registered user. Users start the geoauthentication process by pushing the button in mobile applications. The MA seeks to obtain the most accurate location data using GPS, GSM or IP addresses.

Launch geoauthentication
(1) The mobile application encrypts the message consisting of id 1 , session identifier SUUID G , location loc A , timestamp t s1 and pseudorandom value RNDM. The prepared message is VOLUME 10, 2022 encrypted with the authentication service's public key.
The calculated value is signed with the mobile application's private key and sent to the witness application via NFC based on the HCE Android API [32]. M 1 is a message consisting of encrypted message M1 and signature S1.
The witness application receives the message and seeks to obtain the most accurate location data loc B .
The witness application encrypts the message consisting of received message M 1 , location loc B , and timestamp t s2 . The prepared message is encrypted with the authentication service public key.
The calculated value is signed with the witness application's private key and returned to the mobile application.
The witness application prepares an M2 message consisting of encrypted value E2 and signature value S2.
The mobile application sends gained messages to the authentication service. The mobile application could send more than two messages received from the witness application instances. User location can be proven by more than one witness application.
The authentication service decrypts and verifies the messages it has received. The first step of verification is to check the integrity of the processing data. Signature S1 1 was verified with KP_MAS, and signature S 2 was verified with KP_WA. AS decrypts message E 1 with the private key of the authentication service and message from the witness application instances E 2 . Messages from other application are decrypted in the same way. AS extracts the location data of the mobile application and witness application instances and verifies them.
Verified location data are used to set the pending location of user u i . is the process proposes calculating user location based on all of the received coordinates. The pending location is the data that have to be confirmed in the second phase of the protocol.
An authentication service verifies whether the location is not bound to another user. Then, AS locks the pending location for some time and bounds the location to identity id 1 and session SUUID G . The location is blocked until the authentication process is completed.
The authentication service returns to the mobile application status of the processed request.
Response (17) 2) PHASE 2: CONFIRMATION OF DECLARED USER LOCATION Figure 3 shows the second step of the user authentication process based on a factor referring to a user's position. The second phase of the process confirms the position declared by a user. A user starts the second phase of the geoauthentication process by applying their smartphone to a card reader (RFID interface of POS).
Apply mobile phone to card reader (1) The mobile application detects that the POS is nearby and receives a hello message. The MA sends the response indicating the type of emulated applet to the POS.

Hello request
(2) Hello response (3) The POS obtains its own identification number POS_ID, concatenates with random number and signs it with private key KPR_POS. The random number RNDM is added to avoid the risk of a replay attack. The result of the sign operation is value SPOS_ID. The POS prepares an MPOS message consisting of signed value SPOS_ID and value POS_ID.
POS sends the command that writes MPOS_ID to the mobile application. As a result MPOS is saved in memory of the mobile application.

Send MPOS
The mobile application returns a success response.
Success response (7) The POS sends a mobile application command that starts the geoauthentication process.
Geoauthenticate (8) The mobile application prepares messages consisting of id 1 , SUUID G and MPOS, which are encrypted with the authentication service public key KP_AS. Value E 1 is signed with the mobile application private key KPR_MAS. The calculated value is stored in the mobile application memory. The result of the process is sent to the POS as a success message.
Save M 1 to memory (12) Success response (13) The POS receives the success message and sends it to the mobile application command that reads data from the memory where signed value M1 is stored.
The mobile application returns a success response and transmits the bytes of value M1 to the POS.
The POS signs the received message with its own private key KPR_POS. The prepared value M2 is sent to the authentication service. The AS receives the message and returns the server response.
Send S2 (18) Server response (19) The authentication service starts the verification process. Each of the verification steps performed is conducted only if the previous step has been completed. The first step checks the integrity of the received data. The AS verifies signature S2 using the POS public key KP_POS and signature S1 with the mobile application public key KP_MAS. Received encrypted message E1 is being decrypted with AS private key KPR_AS. Then, the authentication service can read the values of id 1 , SUUID G and MPOS.
Verify KP_MAS (S1) The AS checks whether the difference between the generation time of SUUID G and the current timestamp is not greater than the assumed constant EXP. After successful validation, value t sv is set to the current timestamp.

Compare abs(t sg (SUUID
The authentication service verifies the integrity of SPOS_ID using the POS public key KP_POS. Then, AS tries to find the POS location in the trusted AS registry. The trusted POS location is compared to the pending location saved during the first phase of the protocol. The AS verifies whether identity id 1 is equal to the identity to which the loc pen was locked. If values are equal, the AS sets loc pos as the correct user location r . Verify KP_POS(SPOS_ID) (25) loc pos = findLocation(POS_ID) Compare loc pen , loc pos (27) The authentication service tries to inform the mobile application that the authentication process succeeded. The AS prepares encrypted message enc 1 consisting of validation timestamp t sv (SUUID G ). The encrypted value and fcmToken 1 bound to user u 1 's mobile application are passed to the FCM service. Firebase cloud messaging returns the server response.
Send enc 1 , fcmToken 1 Server response (30) FCM passes encrypted message enc 1 to the mobile application. It decrypts enc 1 with the MA private key KPR_MAE; and after calculating the duration time of the process, it shows the user result of the authentication process.
The user can read the authentication status.

IV. PROTOCOL EVALUATION A. SECURITY CONSIDERATIONS
Research experiments based on the presented protocol were conducted. The experiments implemented several possible attack scenarios related to the use of location data as an authentication factor. The results of the experiments and analyses are presented below and collected in Table 3.

1) GPS LOCATION SPOOFING ATTACK
The use of location data to provide security services creates an additional attack risk. Information about a user's current location may be considered sensitive and may be intercepted. Moreover, location information obtained from a smartphone can be manipulated. The presented authentication protocol based on location data has been designed to minimize the risks resulting from the use of location data. In order to eliminate the possibility of conducting an attack consisting of modifying information about a user's location, methods securing the process on two levels were applied. The first level is related to the mobile application, and the second is the protocol level. First, the mobile application obtains location information on the basis of three independent interfaces: GPS signals, data from the GSM provider and an external service that uses information about the IP addresses of Wi-Fi networks available nearby. In order to conduct the authentication process, it was assumed that at least two sources of location data (e.g., GPS and GSM) should be used. In addition, the protocol reduces the risk of an attack using location data modifications by acquiring and comparing location data from various devices -user u i 's smartphone, devices of other users confirming user u i 's identity and a POS terminal located in a specific place where the authentication process is performed. Therefore, an effective attack on authentication based on the location-based factor would have to be conducted on the three elements of the presented protocols of the MA, WA and POS. One of the attack scenarios assumes modifications to the location data of user ui. Suppose in this case that the attacker is able to force the GPS module to return specific coordinates. Then, the location determined on the basis of the GSM network and Wi-Fi network is inconsistent with the GPS data. In such a situation, data manipulation will be detected. Moreover, according to the assumptions, the authentication process based on two sources of position data is possible. Therefore, such a scenario does not prevent the execution of the user identity confirmation process. The second scenario assumed increasing the attacker's potential and that the attacker is able to influence the information returned based on the GSM module and Wi-Fi network. Additionally, in this case, the user authentication process will not occur. The manipulated location data of user u i will not match the data obtained from the user's witness application and the POS location at which the process is performed. Another VOLUME 10, 2022 attack scenario assumed that the attacker is able to modify the location data on user u i 's device and can modify the location data on the device on which the confirming application is installed (the witness application). In this case, the security of the authentication process can be ensured by increasing the number of required confirmations. Assuming that the location data on user u i 's device and on several instances of the witness application are manipulated, the authentication process will not occur. The fraud will be detected because the information obtained from the user's application will not match the location obtained from the other, unattacked witness application instances. This solution will increase the process execution time but will provide a higher level of security for the factor based on location data. If we increase the attacker's potential, we can assume that all packets from the acknowledgement devices (M 1, M 2, . . . , M N ) sent to the POS terminal and to the authentication server have been modified and the coordinates sent in them are consistent with each other. In this case, the authentication process will also fail because the attacker is unable to modify the information about the POS location. The attack on the mobile application and the witness application allows for the manipulation of only the data sent in the first phase of the declaration of the user's location. The second phase, confirming the user's location, is conducted based on a trusted POS device whose location is known and verified based on cryptographic methods.

2) LOCATION PRIVACY
In the case of location privacy, the scenario that has been tested assumed the possibility of tracking a user and a case of data leakage or interception. It seems that the proposed scheme also considers the requirements of ensuring the confidentiality of the location data used in the authentication process. At each step of the protocol implementation, the location data sent to the next node are encrypted with the public key of the authentication service. As a result, only the AS is able to read the location of a particular device. This solution makes it impossible to track devices; and in the case of data leakage or interception, the devices cannot be read.

3) MAN-IN-THE-MIDDLE ATTACK
Another verified scenario is a man-in-the-middle attack. In this case, an attack was unsuccessful because the cryptographic key pairs were exchanged between the authentication service and the other units involved in the communication.
Each of the messages between the POS, mobile application, witness application and authentication service is signed. Therefore, an attempt to implement an MITM attack at any stage of the protocol implementation will be detected on the side of the authentication service. The security of the protocol in terms of an MITM attack has also been formally verified, and the results of this analysis are presented in Chapter 4.B.

4) REPLY ATTACK
The last of the examined scenarios relied on conducting a reply attack. In this case, the attack failed because pseudorandom numbers were added to the protocol to protect against a reply attack. Each of the exchanged messages contains an RNDM component that is added to the message before it is encrypted. This allows you to verify if the messages sent to the server were not intercepted by the intruder and used again for a reply attack. After decrypting a message, the random number is verified. If this number is repeated, the query is not processed. A formal protocol security analysis in terms of a replay attack was conducted, and the results are presented in Chapter 4.B.

B. PERIOD FORMAL VERIFICATION OF THE CORRECTNESS AND SAFETY OF THE PROTOCOL
Since the 1990s, researchers have proposed several methodologies for protocol property verification. In addition to simple real or virtual simulation, several mathematical methods, including inductive and deductive methods, were proposed [33], [34]. Such methods allow formal proof of whether the considered protocol possesses an investigated security property [33]. Today, the most efficient methods in this area are model checking of transition systems that encode users' behaviours, including their knowledge, during a protocol's executions [35]- [41]. For several years, it has been crucial to consider the properties of time-dependent protocols. It is not easy to consider rather complicated time models. There are only a few well-grounded approaches that allow investigation of the time dependencies between protocols' parameters or users' behaviours [42]- [44]. Additionally, as the protocols are expanded with new security techniques, such as location in our case, there is a need to find current verification methods. The consistency, internal correctness, and the probability of an attack occurring upon the authentication and confidentiality properties of the protocol will be formally examined. Here, we propose formal multilevel verification of the proposed protocol. First, we examine the untimed version of the protocol seeking attacks of malicious intruders upon authentication and secrecy properties. After concluding that the untimed version is safe, we proceeded to consider a time protocol version. Here, we can strictly compute the minimal lifetime values that allow protocol execution and compute maximal values that guarantee the protection of the protocol against all undesirable, malicious man-in-the-middle behaviours. In our investigation, we consider the well-known and most commonly used Dolev-Yao model to verify an intruder [45].
Starting our work, we must initially make some assumptions. First, we assume the perfect cryptography assumption where an intruder will not be able to break the cipher without knowing the key. We also assume that users and the server have a set of locations considered to be appropriate for a specific user, which are, in some sense, its identifiers. The server has the necessary keys, passwords, and data used for communication. We also assume that users have a mobile device equipped with private keys and a biometric reader.
For formal protocol verification using a particular verification tool, we need to describe the specification languages used by the tool. Here, we must apply strict language rules that make it impossible to apply descriptions used before to determine, for example, protocol messages. First, we present the protocol specified in the so-called Alice-Bob notation. In this case, for the subsequent considerations, a symbol A denotes the user who is being authenticated (that uses the mobile application), S denotes the authentication service (server), B denotes the proving application, and P denotes the pointof-sale terminal.

A → S: i(A)|N A K AS
. S → A : N P K + P In this notation, N and t denote nonces and timestamps, respectively; X K denotes a message X encrypted with the key K ; and X |Y is the concatenation of X and Y . K + A and K − A denote the public and private keys of A, respectively. In the considered protocol, there are several messages with multilevel encryption. An exam- where there is message i(A)|t A | N P first signed by private key K − P , then encrypted by public key K + S and next signed two times with private keys with K − A and K − P . As we can see, in this way, we can strictly specify each of the protocol's steps. Using such notations, we can start formal analysis and specify all the protocol's steps in other, more complicated languages connected with suitable verification tools.
The practice of protocol verification techniques shows that at the beginning of the study of the correctness of the protocol, usually an untimed version of the protocol should be examined. For this purpose, we chose AVISPA [35] due to the popularity and capabilities of this tool. AVISPA was the result of a large project cocreated by scientists and industry. It consists of four modules, each of which can test the protocol differently. It requires the specification of a protocol in HLPSL language [35]. Below we illustrate a specification of role A: Because we are investigating the authentication properties between A and S and secrecy properties of the nonces used, we have the following security goals written in HLPSL: secrecy_of na, n1a, n2a, ns, n1s, n2s, n3s, n4s, n5s, nb, n1b, np authentication_on alice_server_ns authentication_on alice_server_n1s authentication_on alice_server_n2s VOLUME 10, 2022 authentication_on alice_server_n3s authentication_on alice_server_n4s After several minutes of computations, the AVISPA tool reported that the untimed version of the protocol is consistent, internally correct and safe according to attacks upon authentication and the security of confidential data.
In the case of time-dependent properties, there are at least two types of problems. The first is the protocol's vulnerability to replay attacks. The second is the protocol's vulnerability to malicious man-in-the-middle behaviour when a passive intruder can only retransmit data sent between honest users [44]. Such behaviour cannot be treated as a real attack upon the protocol because the authentication process is not corrupted and secret data are not compromised, but such behaviour is at least undesirable in the network. The lifetime values for subsequent timestamps should be chosen well to protect the protocol against such vulnerabilities.
To solve these problems, we need to use another formalism and methodology than presented previously.
Among the methods currently leading is timed model checking, which is efficient and possesses the ability to use many different formal models. In our study, we use some type of transition systems model based on a network of synchronized timed automata in which the tested values will be checked through the reachability of specific states [38].
For our tool, we need the specification in ProToc language that allows for the description of time-connected dependencies [40]. Such a specification method allows this description and investigates two types of time primitives: time values of many timestamp generations and lifetime values. Using this, we can investigate the possibility of an attack as a function of time dependencies between the aforementioned values.
As an example of the protocol's steps specification, we present the first four steps of the protocol: Here, we can see that each step consists of five sections. In the first of them, we can find the sender and the recipient of the step. The second section consists of all primitives that are necessary to create the message. The third section includes the primitives that must be generated for the current step. The fourth section consists of a time condition. In the last section, we can find a message that will be sent in the current step.
Let us analyse the first and second steps of our protocol described in ProToc [46].
The sender in the first step is A (p_1), and the recipient is the trusted server (p#1). The sender needs three primitives to compose the message: A's identifier (i(p_1)), A's nonce (n_1(1)) and a symmetric key shared between A and server (k_1#1 (1)). At the beginning of this step, the sender does not have the nonce (n_1(1)), so he must generate this primitive. Such information is contained in the third section. There are no time conditions imposed on this step, so the fourth section informs us that all time conditions are met (true). In the last section, we can find a message (<k_1#1(1),i(p_1)|n_1(1)>) created with primitives from the second section of the specification.
The sender in the second step is the trusted server (p#1), and the recipient is A (p_1). The sender needs two primitives to compose the message: the server's timestamp (s#1(1)) and a symmetric key shared between A and the server (k_1#1(1)). The server must generate its timestamp (third section). In this step, the time condition assigned as c[s#1(1)] is imposed. Such notation denotes the time condition τ S < L f , where τ S is the period from the ticket generation time t S to the current moment in the considered protocol execution, and L f is a lifetime value of timestamp t S . In short, this means that assumptions of the time condition must be compared with the timestamp (s#1 (1)). In the last section, we can find a message (<k_1#1(1),n#1(1),s#1(2)>) created with primitives from the second section of the specification. The remaining steps should be considered in the same way. Now, let us briefly introduce the formal model used for verification. Protocol modelling and verification using networks of synchronized automata were introduced in [38]. In such works, there are two types of automata in the network: those representing protocol executions and those representing users' knowledge. Knowledge research causes unrealistic steps to be excluded from the entire network, which is impossible to perform due to the lack of knowledge of the user, server, or intruder about the elements required in the step. Execution automata allow synchronization and ensure the correctness of the steps interlaced in different executions of the same protocol.
The synchronized automata network finally creates the so-called product automaton, which is encoded into a Boolean propositional formula. The formula, due to its size, is tested using the SAT solver. Then, we can check the reachability of the states equivalent to an attack. The tool then verifies the timestamps. Finally, we simulated the latency times in the network using different probability distributions: uniform, normal, Poisson, Cauchy and exponential. For the tests, we used a computer with the Linux Ubuntu operating system, an Intel Core i7 processor and 16 GB RAM.
In the case of tests with the SAT solver, we received the result UNSAT, which means that the protocol is safe. The SAT solver worked with path lengths equal to 70,62516 clauses and 146540 literals and used 10.29 MB of memory. The study lasted 21.9515 s.
Next, we performed timed analysis of executions (TAoE). First, we assumed the following: • The encryption and decryption times were equal to 2 tu. • The generation time of confidential information was equal to 1 tu.
• The range of delay in the network was equal <1 tu, 5 tu>.  • The current delay in the network value was equal to 1 tu. Next, we calculated minimal session time (111 tu), maximal session time (179 tu) and lifetime in the following steps. The lifetime values for TAoE are presented in Table 4. During the calculation of the lifetime values, the values of encryption and decryption times, generation of confidential information and network delays were considered.
We obtained the following results: • Structure creation time: 0.043302 ms • Time of timed analysis: 0.380163 ms • Total protocol study time: 0.427735 ms During this research phase, the duration of all executions was analysed. Only fair execution proved to be feasible. In the others, the intruder could not acquire the appropriate knowledge by seeking to take additional steps. These executions failed in 'failure to meet the imposed time' conditions. Next, we performed simulations of executions (SoE). First, we assumed the following: • The encryption and decryption times were equal to 2 tu. • The generation time of confidential information was equal to 1 tu.
• The range of delay in the network was equal <1 tu, 5 tu>. The current value of the delay in the network was randomly generated according to the mentioned probability distributions.
Next, we calculated the minimal session time (111 tu), maximal session time (264 tu) and lifetime in the following steps. The lifetimes values for TAoE are presented in Table 4.
We show the obtained timed results in Figure 4. During this phase of the research, simulations of all executions were conducted considering the random delay in the network values. These values were randomized according to selected probability distributions (uniform, normal, Poisson, Cauchy and exponential). Each execution has been tested in 100 test series. Similar to the analysis of the times, only fair executions proved possible. In the others, the intruder could not acquire the appropriate knowledge by seeking to take additional steps. These executions failed to meet the imposed time conditions.
The results presented in this section proved that the proposed authentication protocol is consistent, internally correct and safe from authentication and secrecy attacks. Additionally, if the proposed values of timestamp lifetimes are used, the protocol is safe from replay attacks and the man-in-themiddle malicious behaviour.

C. PERFORMANCE
Designing an authentication protocol is a complex and complicated issue because it is related to user interaction. In addition to confirming the effectiveness and safety of the presented protocol, its performance and the feasibility of implementation in a dedicated environment should be verified. In order to test the performance of the proposed protocol, we prepared a test model that performs multifactor authentication based on the presented scheme [14] and the location-based authentication factor proposed in the article. The aim of the conducted experiments was to evaluate whether the time of the authentication process, based on the factor using location data in the manner presented in the protocol, differs from the authentication steps using the factors of other categories. The determination of the efficiency of the factor was made by comparing the duration of the authentication with the duration of the authentication based on the possession and inherence factors. The prepared model implements the architecture shown in Figure 1. The possession factor was implemented as an OTP code sent as a push notification, and the inherence factor was based on the fingerprint in accordance with the information presented in previous studies [14]. The model was extended with the witness application and a module in the mobile application, which implemented communication within the presented protocol (Figure 2 and Figure 3). Additionally, a POS emulator was prepared for the second phase ( Figure 3). The results of the conducted research are presented in Table 5.
The tests were conducted in an environment running on a public internet network. The average values were determined on the basis of n = 200 samples, which determines the number of attempts made in the multifactor authentication process. Each of the authentication processes was performed by the user without automating any of the steps. Such tests were designed to reproduce the authentication process in real conditions. The architecture of the prepared model is the environment in which the presented protocol could be implemented.
The average authentication time based on location data ignores the waiting time for determining a location based on GPS or other location sources because the goal is to compare the implementation of individual authentication steps, not the speed of individual interfaces of the device. The time for obtaining the location was also omitted because it depends on the environment in which the user is located. The presented results indicate that the use of the factor based on location data may be more efficient and faster than the implementation of the authentication factor based on the OTP code sent to the user. The obtained results confirm that the use of the proposed authentication factor does not significantly affect the duration of the authentication process. The next stage of the research is to compare the performance of the multifactor authentication protocol [14] extended with the proposed scheme using the factor based on location data. For this purpose, the existing prototype has been parameterized in such a way that the authentication process can be performed based on selected authentication factors. The conducted ' is a knowledge-based factor, ''P'' is a factor from the possession category, ''I'' is a factor from the inherence category, and ''L'' is a factor implemented on the basis of location data, as shown in Figure 2 and Figure 3. The following diagram, Figure 5, presents a comparison of the authentication process performance for different sets of authentication factors. The presented results show that in a situation where the location-based factor has replaced a factor from another category, there is no significant change in the duration of the authentication process. The differences between the various sets of authentication factors used are relatively small.

V. DISCUSSION
The presented protocol uses a user's location data in the authentication process and can be used in the multifactor authentication process or as an additional factor supporting the existing multifactor authentication systems. In order to determine whether the location-based factor can be treated as an authentication factor, it is necessary to verify the compliance of the proposed solution with the specific requirements related to the authentication factor ( Table 1). The first requirement is related to the verification of the user's identity. The proposed protocol signs the location data using user u i 's private key. During the verification of the received data, the authentication service is able not only to verify the integrity of the data received but also to confirm the identity of the user who sent the data. The presented authentication scheme meets the requirement according to which the authentication factor must be controlled by the user. This feature is ensured by the private key property that was generated in the user's mobile device system keystore. The private key property [47] allows the key to be used only after the user has been authenticated. Therefore, only the real smartphone user who controls all authentication factors is able to release the authentication factor based on location data. The third issue is related to the association of the authentication factor with the user identity, and this is an issue that has not been clearly described in previous publications on location-based authentication. It is hard to assume that the location will be associated with a specific user, similar to other authentication factors that are related to the identity of a specific user. The limitation of the factor based on location data allows us to solve this problem in two ways. The first approach assumes that a specific location can only be assigned to one user, provided that only one user has access to a given area. In a one-toone relation, an authentication system receiving data from a particular location is able to determine the identity of the user being authenticated. Considering the operating conditions of a real system, the implementation of such an assumption is almost impossible. The second approach assumes adjusting this requirement to the conditions in such a way that the implementation of authentication based on the location-based factor is possible in any place. In this case, it should be assumed that a certain area is assigned to a specific user identity. The implementation of this requirement consists of assigning an area to a user and, at the same time, blocking the possibility of another user using this area for a specified period of time. The data obtained in this way are compared with a trusted location obtained from another source, which is a resistant to attempts to modify the location data (e.g., from a POS terminal). As a result, the location-based factor meets the requirements of the authentication factor that must be associated with the user. The last assumption is related to the issue of comparing the reference data to the data provided during the authentication process, as in the case of authentication based on factors from the knowledge, possession and inherence groups. This process is also similar when using the factor based on location data. The difference is that the pattern data are not transferred during the registration process and are transferred during the first phase of the authentication process ( Figure 2). The presented results of the analysis indicate that the proposed authentication factor using location data meets the requirements for authentication factors. The most important step in designing the location-based authentication factor is the assumption of assigning a specific location to only one identity at a time. This assignment can be done in two ways: statically and dynamically. In the case of a static assignment of an area to an identity, only one person can be authenticated in a given area. In the case of dynamic assignment, a given location is associated with the identity of the user for a specified period of time and may be associated with the identity of another user after the end of the process. If the time condition is not met and a given area is not associated only with the identity of one user, we would not be able to identify the identity of two users standing next to each other. Therefore, it can be concluded that location may be a feature assigned to a user only at a specific time. Moreover, in order to perform the authentication process based on the location data, it is necessary to possess location data from two different sources. The data from the first source come from a device associated with the user and act as challenge data that are compared with the reference data. The data from the second source are the reference data and are determined by the trusted device. The methods used to determine a user's location data should be resistant to attacks, including modification attempts. This requirement has been met by the use of appropriate mechanisms during location determination and at the protocol design level (Chapter IV. A).

VI. CONCLUSION
This article presents a new authentication protocol that uses a user's location data in the user authentication process. The requirements of the authentication process and collection of the features that characterize the authentication process and authentication factors have been presented. These features have been analysed in detail because location data are very often used in schemes that perform the authorization task and not user authentication. Several publications related to the use of location data for the implementation of security services in a mobile environment have been referenced, and other methods of user authentication in a mobile environment have been discussed. Based on this detailed analysis, a user authentication protocol based on location data has been proposed. It should be emphasized that according to the authors' best knowledge, the authentication process based on location data is presented here for the first time. The process must be conducted in two steps and should consist of the phase of declaring the user's location and confirming the declared location. The presented scheme has been verified in terms of authentication performance based on the location-based factor. Its performance was compared to the systems using other factors from the knowledge, possession and inherence categories. The conducted research has been experimentally verified. The implementation allowed the configuration of factors that were used for authentication in a given test scenario. Moreover, security analysis, which used the prepared security tests and allowed formal verification of the protocol's resistance to man-in-the-middle attacks and reply attacks, was conducted. The results indicate that the proposed scheme uses location data in a way that allows the data to be treated as an authentication factor associated with a user. The authors of the article recommend using the location-based factor as an alternative to traditional authentication factors when it is not possible to use multifactor authentication based on knowledge, possession or inherence. Alternatively, the proposed scheme based on location-based factors can be used as an additional authentication factor, increasing the security of the identity confirmation process in a mobile environment.
IMED EL FRAY received the M.Sc. degree in naval automation from the Szczecin University of Technology, the Ph.D. degree from the Faculty of Maritime Technology, and the D.Sc. degree from the Faculty of Computer Science. He is currently a Professor with the West Pomeranian University of Technology (ZUT), Szczecin, Poland. He is the author and coauthor of four book chapters and over 80 research papers on risk assessment and risk management, information systems audit, security information and event management, and common criteria.
MIROSŁAW KURKOWSKI received the M.Sc. degree in mathematics from the Jan Dlugosz University of Czestochowa, the Ph.D. degree in mathematics and computer science from the Institute of Computer Science, Polish Academy of Sciences, and the D.Sc. degree in computer science from the Faculty of Mechanical Engineering and Computer Science, Technical University of Czestochowa. He is currently a Professor with Cardinal Stefan Wyszynski University, Warsaw, Poland. He is the author and coauthor of four books and over 60 research papers on applied mathematical logic and formal methods for the verification of software systems, especially security protocols and cryptography.
SABINA SZYMONIAK received the M.Sc. degree in computer science from the Czestochowa University of Technology, Czestochowa, Poland, and the Ph.D. degree in computer science from the Faculty of Mechanical Engineering and Computer Science, Czestochowa University of Technology. She is currently an Assistant Professor with the Czestochowa University of Technology. She is the author or coauthor of 20 research articles on the verification of security protocols and cryptography.
OLGA SIEDLECKA-LAMCH received the M.Sc. degree in engineering and the Ph.D. degree in computer science from the Czestochowa University of Technology. She was a Scholarship Holder at the Polish Academy of Sciences. Currently, she is an Assistant Professor with the Czestochowa University of Technology. She is the author or coauthor of over 30 research articles and published on formal modeling and theory of automata. VOLUME 10, 2022