2011 19th International Euromicro Conference on Parallel, Distributed and Network-Based Processing

LRAP: A Location-Based Remote Client Authentication Protocol for Mobile Environments

Diana Berbecaru Politecnico di Torino, Dip. di Automatica e Informatica Corso Duca degli Abruzzi 24, 10129, Torino (ITALY)

AbstractMobile networks are driven by the need to provide more advanced services to mobile or nomadic computing devices, such as security services requiring remote client authentication. In such services, the users location might be used as authentication factor, in addition to the typical authentication factors, like passwords, or one time tokens combined with the use of a physical device that a person owns, such as a card or a phone. Since the location information itself is subject to forging attacks, additional mechanisms must be used to certify its integrity. We propose LRAP, a novel protocol combining several authentication factors to securely authenticate a mobile user. In LRAP, the users location can be determined and its correctness is certied by a third trusted party, called Local Element. As use case, we considered the payment service at the self-service gas stations, a widely available service vulnerable to several types of security attacks, and we proposed an LRAP-based service exploiting one time codes and certied position for secure payment operations.

I. I NTRODUCTION Authentication is considered the most important security service staying at the basis of many products and application services nowadays. To perform authentication, various methods with a variable degree of reliability are typically employed. These methods are classied into three main classes or factors: what the user is (e.g. a ngerprint, retinal, voice recognition pattern or other biometric data), what the user has (e.g. an ID card, security token, mobile device or cell phone), and what the user knows (e.g. a static passwords or a one-time code). No single authentication method can fully protect against all types of security attacks. For example, the challengeresponse one-time codes or the application-level PKI-based authentication render phishing and malicious software attacks useless, but they do not protect against man-in-the-middle attacks, even though both methods could be extended to achieve this protection too [1]. Thus, there is a need for stronger authentication methods, especially in remote usage scenarios. The term remote is used here to refer to any infrastructure in which the clients and the service providers are connected via some potential insecure network, like the mobile network. With the appearance and advance of location sensing and social networking technologies, newer authentication classes, such as where the user is, and when [2] or somebody you know [3], might be used in combination with the classical authentication factors [2] [4]. Determining and proving that a user is at a certain location is itself a challenging task as no single location sensing technology has emerged as a clear winner in all kinds of environments. The ground navigation system
1066-6192/11 $26.00 2011 IEEE DOI 10.1109/PDP.2011.32 141

LORAN (LOng Range Aid to Navigation) for example is used in several military and navigation systems, but it cannot be used on wide range in any application scenario. The Global Positioning System (GPS) is the de facto location technology for wide outdoor area, but it does not work in covered areas or indoors and it can be easily spoofed (see Section II). We propose LRAP, a secure location-based remote authentication protocol which can be used to authenticate the remote users in mobile environments. LRAP is based on the use of classical authentication methods (like the static passwords and the one time passwords) combined with user location information at one time. To verify the integrity of the location data, LRAP exploits a dedicated component, named Local Element (LE), which is part of the European Galileo navigation satellite system. As a proof of concept, we designed and implemented an LRAP-based service involving payment with the mobile devices at the gas stations. Organization. The paper is organized as follows: in Section II we present the related work, in Section III we present a use case used as starting point for our work, in Section IV we describe our proposed location-based remote authentication protocol, and in Section V we present the design and implementation of the payment service based on LRAP. Finally, we conclude our paper in Section VI. II. R ELATED W ORK Location as authentication factor. Two-factor authentication is considered not adequate for security problems encountered today, like phishing or identity theft [5]. Historically, biometric identication (such as ngerprints) have been used as the most authoritative method of authentication, but this technology cannot be always deployed on wide scale and requires collection and secure storage of such data. To cope with the new attacks in banking services, new, cost-effective technology tools should be used in every banks online security arsenal to protect their customers against security frauds [6]. Geolocation techology determining the true geographic position may prove benecial in a multifactor authentication strategy, as noted also in the guidance document on the authentication in Internet banking environment [7]. The geo-location information has been used in the past in several location-based services, such as emergency and information services [8], tracking and monitoring systems [9], or even for establishing pairwise keys in the sensor networks [10]. In the security area, some location-authentication schemes have been proposed [11], but the location authentication is still

considered a novel security service [12], mainly because the location data itself needs to be authenticated or certied by a trusted third party in order to be considered reliable. Location authentication problem and some solutions. To obtain the location information, one possible and simple solution is to use the U.S. space-based GPS system. For anyone with a GPS receiver, the system provides accurate location and time information in all weather, day and night, anywhere in the world. However, from the security point of view, the authenticity of the GPS signal is not guaranteed because a false (or spoofed) GPS signal could be generated by a dedicated GPS signal simulator, and a typical GPS receiver would not be able to detect that. Some advanced GPS receivers are enhanced with antispoong modules in order to detect whether the GPS signal comes from the satellite or from a fake GPS simulator. However, in the recent years, more and more advanced GPS simulators have become also readily available (e.g. can be hired relatively cheaply), and thus it is not possible to guarantee that a GPS signal really comes from the right source or not. To cope with the GPS signal authentication problem, Denning & Doran proposed a location signature sensor (LSS) tamper-proof device [11] whose role is to create (and verify) a location signature (LS) containing geodetic position and valid for a short time, e.g. for 5 ms. Thus, an LS acts more or less like an unpredictable one time password. Nevertheless, Kuhn notes some critical points of the LSS-based solution [13], such as this system only provides symmetric authentication and anyone able to verify the output of a LSS in a geographical region will also be able to fake the output of such a sensor from anywhere within the same region. Other solutions, like [14], propose to exploit the location-positioning capabilities of a wireless network to check out the location information. Other solutions proposed to guarantee the authenticity of location information against the most common location-related attacks are shortly presented in [12]. Galileo Local Elements. The European Galileo programme aims to provide users with another satellite system (i.e. Galileo), independent but interoperable with the US GPS system. Galileo will be the rst satellite navigation system specically for civil purposes, generating new opportunities of market and pushing the advance in technology for Europe. The Local Element (LE) is an important element of the ground infrastructure of Galileo, and is in charge with certifying the position and time information. LE will deliver enhanced performance in terms of accuracy, integrity, availability and continuity by combining Galileo/GPS satellite-only services with information coming from external sources. In particular, the LE developed in the GAL-PMI project [15] provides augmentation and certication features using data acquired from Global Navigation Satellite System (GNSS) and Telecom Italia (GSM) cellular networks. Further details on LE design and implementation are given in [16]. One Time Codes. In remote client authentication based on one-time codes, both the prover (the entity whose identity is veried) and the verier share a secret: the prover presents the secret to the server as is, that is the shared secret is the One Time Code (OTC), or in a derived form, e.g. as generated
142

with the RSA SecurID authenticator 1 . Typically, the OTC has a limited validity lifetime (e.g. 60 s) because time itself is used at the OTC generation, and the prover can use an OTC to authenticate to the verier only once. The OTC can be either generated independently by the user, or it can be generated by the verier and sent to the user (provided that the user established a relationship with the verier). The latter method is used by several banks to offer advanced services, such as mobile banking 2 or fund transfers to non-registered third party accounts. In some security products, like in the Clavister SMS One-Time Password service 3 , the OTC is generated by a Gateway controlling the access to the network resources, applications and les of a corporate network, and is distributed to the users mobile phone as a ash SMS. Subsequently, the clients can get access to the protected resources by using any standard Web browser and the OTC received via SMS. We used a somehow similar approach in our protocol, as described in Section IV. III. U SE C ASE : PAYMENT AT S ELF - SERVICE G AS S TATIONS This use case is suitable for our study because it is still subject to various security attacks and because its characteristics (gas stations distributed over wide geographical areas in open environments, pay-at-the pump devices at the gas stations that cannot be considered trusted, as they might be tampered, the necessity to use more secure and exible payment methods in place of the credit and debit cards) makes it a good candidate for our proposed protocol. Service description. When a customer performs the self service at the gas station, the user inserts a payment card supported by the fuel dispenser in the fuel pump incorporating a pay-at-the-pump device, such as a POS device. Subsequently, the user selects a pump number and waits for the pump to be unlocked. In practice, in case of payment with a card, the pay-at-the-pump device typically communicates with the server of the customers bank (via a dedicated payment circuit) in order to check the eligibility of the customer, that is to check the availability of the amount required in the customers bank account. Once the customer has nished using the fuel dispenser and if no error has occurred during the whole operation, a receipt is returned to the user. Some attacks. One of the most common frauds addressing the fuel pumps is the stealing of the credit or debit card data [17]. The thieves install hard-to-detect electronic devices at the gas stations (named also skimming devices) in order to steal credit and debit card data. Subsequently, the skimmed data is used to create cards used at the victims expense. Skimming devices have been used for several years, most often at ATMs. Thieves increasingly target pumps because its a cheap, easy way to steal credit and debit card information. Alternatively, the thieves swapped card readers with their own to wirelessly send PIN numbers and credit card numbers to a remote receiver [18]. So, we can conclude that its the credit or debit card thats the real honey-pot for criminal bees, because
1 http://www.rsa.com/node.aspx?id=1156 2 e.g. 3 http://www.clavister.com/pdf/clavister-dts-sms

http://www.theriverbank.com/online banking/3mobilebanking.htm service.pdf

credit and debit cards typically carry key bank details that do not change with time. Thus, if an alternative payment method is used instead of the card itself, such as as an OTC whose use is limited in a geographical area, the card cloning attack would not be a problem anymore. IV. L OCATION - BASED R EMOTE AUTHENTICATION P ROTOCOL Attacker model. We do not address in LRAP the attacks against lower layers such as the MAC or the physical layer. We assume that the physical layer uses GPS and GSM jammingresilient techniques, such as frequency hopping [19] or BBC and concurrent codes [20], or additional systems or specialized anti-jamming GPS receivers can be used to protect from jamming in critical applications. LRAP Overview. Our protocol, LRAP, is based on three factors: where a person is and when - that is the location of the user associated with the time information, something the user has - such as a GPS and GSM/UMTS aware terminal, and something the user knows, that is a static PIN (Personal Identity Number) used to access the device and an OTC. LRAP architecture involves several actors, i.e. the user and the User Terminal (UT), the Service Provider (SP) and the Galileo LE. The protocol is composed of two phases: a registration phase and an operational phase. In LRAP, the SP (acting as verier) generates an OTC encrypted with a key derived from UT location (called TOKEN) and sends it to the UT to be used for authentication, provided that the user has registered rst with the SP. In the registration phase, the client provides several data to the SP, such as: (1) person identication data, like name, surname, birthplace, scal code; (2) UT identication data, such as the phone number and the IMEI (International Mobile Equipment Identity) code uniquely identifying the UT device in the cellular network; (3) authentication data, that is data required by the authenticated key agreement protocol; (4) other data, such as a bank account number (if a payment operation need to be performed in the service), or service subscription type (silver, gold). To avoid identity theft attacks, the SP might use additional means to check the correctness of the user data. When authenticating the location of the UT, the legitimate user controlls the device when (or immediately before) the evidence about the location has been acquired. In practice, we dont separate the location authentication (that assures the truthfulness of the claimed or presumed location) from the entity authentication, which helps corroborate the veracity of a claimed or presumed partys identity [12]. Since the UT (and implicitly the user controlling the UT) is authenticated based on the OTC, the ownership of the UT, and the position of the UT, we needed a way to combine these types of information together. To combine the position information with the OTC, we used a modied version of the LDEA geo-encryption algorithm [21]. In this way, the user will be able to recover the OTC only if he is in a certain position and he has access to the UT. OTC generation and use in LRAP. The term geoencryption or location-based encryption refer to a security algorithm that limits the access or decryption of some informa143

tion content to specied locations and/or times [22]. The algorithm does not replace any of the conventional cryptographic algorithms, but it adds instead an additional security layer. By using a geo-encryption algorithm, the sender can restrict the location of the receiver for data decryption. The locationdependent data encryption (LDEA) algorithm [21] allows the mobile clients to transmit a target latitude/longitude coordinate for data encryption to information server. The client can only decrypt the ciphertext when the coordinates acquired from the GPS receiver matches the target coordinates. LDEA uses the latitude/longitude coordinates to derive a key called LDEAkey, which is further combined (using an XOR operation) with a random session key to calculate the Final-key: this key is used to encrypt the plaintext data. When a target coordinate is determined for data encryption, the ciphertext can only be decrypted at the expected location. The LDEA algorithm uses public key cryptography to ensure authenticity and integrity of the session key. In LRAP, we derive the LDEA-key as in the LDEA algorithm, but we use the symmetric key encryption with a shared key (named KS e ) to generate the Final-key. The resulting scheme is shown in Fig 1. To ensure the integrity of the OTC, the SP calculates a keyed digest on the OTC and the symmetric key KS a . The TOKEN obtained by encrypting the OTC with a symmetric algorithm (like 3DES) and the Finalkey is different at each session. Since the position determined by the GPS receiver of the UT terminal could be inaccurate and inconsistent depending on how many satellite signals are received, the LDEA algorithm uses an additional parameter named toleration distance (TD) that must be known both by the sender and the receiver. The sender uses the TD (e.g. 0, 5, 10, 15 or 20 meters) when calculating the LDEA-key, and the UT can recover the OTC if it is within TD range.
OTC
Symmetric encrypt TOKEN (16 bytes) GPS receiver Symmetric decrypt Final -key LDEA -key generator TD hash(OTC,KSa ) Hash KSe Compare digests Hash OK/Error

OTC

Final -key

Target UT coordinates LDEA -key generator

Insecure Channel

KSe

TD

SP
Fig. 1.

KSa

KSa

UT

OTC generation and transmission in LRAP protocol.

Security Analysis. In Fig. 1, both T OKEN = E(xor(KSe , LDEA key), OT C) and keyed hash Hash(OT C, KSa ) are shown as passing through an insecure channel. Since, as noted above, an adversary can derive LDEA-key from public data, a dictionary attack could be mounted on suspected weak passwords by choosing exhaustively the all guesses of the ordered pair (KG e , KGa ) from suitable dictionaries DGe and DGa, for the keys KG e and KGa respectively. If the source of the weakness is believed to be the same for both keys (e.g. both keys are human choices), then DGe may be identical with DGa. The adversary then reconstructs LDEA-key from the known

GPS location of the LE and the known TD, and derives OTCG from observations of E(xor(KS e , LDEA key), OT C) and Hash(OT C, KSa ) as: OT CG = D(xor(KGe , LDEA key), E(xor(KSe, LDEA key), OT C)) (1) Then, if Hash(OT CG, KGa ) = Hash(OT C, KSa ) KGe = KSe and KGa = KGa with probability approaching 1 for any cryptographically strong choice of the encryption function E(.), the decryption function D(.) and the keyed hash function Hash(.). The cost of mounting such an attack on an observed E(xor(KSe , LDEA key), OT C), Hash(OT C, KSa ) pair is O(|DGe|.|DGa|). The cost of each computation of E(.), D(.) and Hash(.) is low by design. Even if TD is not known to the adversary, but the set of permitted values of TD, TDx is known, the cost of the attack only increases to O(|DGe|.|DGa|.|T Dx|). The vulnerability of the encryption and authentication keys to a dictionary attack is due to the fact that an adversary who guesses both KG e and KGa correctly is able to verify her guesses with probability very close to 1. The design requirements for low processing cost preclude the use of any well-known methods for secure session key establishment (e.g. Dife-Hellman with certicates). This means that the encryption of OTC is only secure if KS e and KSa are chosen at random from a sufciently large key space. For this purpose, we assume the user exploits a pseudorandom generator for generation of KS e and KSa keys. In addition, we observe that it is also not sufcient that the OTC changes with each session to provide protection against a dictionary attack. The OTC must change in an unpredictable way between sessions. Otherwise an adversary can use the value of a recently-decoded OTC to predict the likely values of OTCs that might be used in the near future. V. LRAP- BASED PAYMENT S ERVICE G AS S TATIONS
AT

Local Element

1: get certified coordinates (Xu, Yu, Zu) for UT

3: generate and send TOKEN (16 bytes) 2: request TOKEN for UT (Xu, Yu, Zu) Gas pump

Service Provider

Bank

5: send OTC
User Terminal 4: decrypt TOKEN (get OTC) 11: if OK, issue receipt

6: send OTC
8: OK/KO

POS

7: verify OTC: OK/KO

9:If OK: select and unlock gas pump

10: If OK: charge If OK: check the amount on user users bank account bank account

Fig. 2.

Architecture and workow of the LRAP-based payment service.

S ELF - SERVICE

This section describes the design and implementation of a LRAP-based payment service at self-service gas stations. The payment operations are performed via the UT communicating with a Point of Sale (POS) device, which is typically available in any gas station providing such a service. Service Architecture. The SP is part of a Private Payment System, which can manage both the payments performed with the UT device and the payments made with the traditional credit or debit cards. However, in our experimental test bed, we developed the procedures to accept and manage only the payments performed with the UT. The user considers the UT as trusted device, and considerations on storing security sensitive information (such as the KSe key) in a tamper-resistant security module on the UT are out of the scope of the current paper. The UT can initiate and manage two types of communication channels: a shortrange channel (e.g. Zigbee or NFC), which is used for the data exchange with the POS Zigbee-ready of the gas station provider, and a long range one (e.g. USSD/SMS, or GPRS) used for the data exchange with the SP and with the LE.
144

Phases. The proposed service is composed of a registration phase and an operational phase. In the registration phase, both the gas station provider and the clients provide several data to the SP. In practice, the client sets the credentials (username and password) required to log-in on to the SP service portal, the contact (name, surname, address) and scal data, the unique identier (that is the IMEI code) of the UT device and the bank coordinates required for the payment operations, the consent for being localized during service provision, as well as the symmetric keys KSa and KSe used for authentication and encryption purposes in the modied LDEA algorithm. The operational phase is composed basically of 11 steps, as illustrated in Fig. 2. First of all, the user unlocks his UT by inserting a secret PIN. Subsequently, the UT acquires from the LE the certied position (step 1). For this purpose, the UT acquires satellite signals (e.g. GPS) and computes the pseudorange measurements relative to the satellites in view; in addition, the UT makes the measurements relative to the GSM/UMTS network and sends them to the LE. The LE calculates the position of the UT based on the measurements received from the UT and by exploiting augmentation techniques implemented. Further details on LE internal operation as well as the format of the location attestation token are out of scope of this paper, but more details on UT-LE protocol can be found in [23]. An interesting discussion on spatial-temporal attestation services can be found in [24]. In our proposed service, the UT manages to obtain from the LE an attestation on UT position, which must be fresh, unforgeable and binded to the UT. The freshness property can be implemented with nonces or timestamps, whereas the binding (location attestation, UT) can be implemented in several ways (e.g. short-lived authenticator token in Kerberos 4 ), that is the SP must be assured that the sender of the location attestation is indeed the owner of the location attestation. In the next step, the UT opens a secure connection to the SP to obtain the TOKEN. Since the UT sends user authentication credentials over this channel, we claim that the protocol used for UT-SP communication must be resistant to snifng attacks.
4 http://web.mit.edu/kerberos/

Using USSD/SMS messages for UT-SP communication might be problematic. As a security mechanism, it is suggested that users supply a PIN along with the USSD communication, however this is not necessary a good thing because, as with SMS the transmission medium is easily accessible by any who have the right tools, and decoding of the data potentially could be easy. Thus, sufcient encryption will need to be utilized to protect transactions and detect spoong of transactions. Also similar to SMS, USSD can support the use of a SIM Toolkit and Smart Card for operators to develop and manage applications, which can uniquely identity subscribers and encrypt data using algorithms such as 3DES. Using General Packet Radio Service (GPRS) for UT-SP is also a good option, because security of information with GPRS is probably one of the most challenging issues facing GPRS. During the course of a GPRS transaction authentication is encrypted using the A3 encryption algorithm. When authenticated the subscriber can choose to have data encrypted as well, using the GPRS encryption algorithm, which is a stream cipher similar to A5 [25]. Authors in [25] also underline another possible and dangerous attack that might produce signicant damage in our case: even if the encryption is not compromised, theft of a subscribers private key from the SIM card (smartcard) allows the thief to use the GPRS network as if they were the targeted user and incur large bills on their behalf. This type of attack requires physical access to the SIM card for some time as well as the technical skills to do it. In case the UT device gets lost or is stolen, we assume the user has the ability to inform the SP about this event within a short time, for example by using an emergency phone number. We assume also that it should be impossible for a malicious application to copy out the sensitive data stored on UT, even if the user presents the correct PIN code. To issue the TOKEN, the SP checks in the rst place whether the UT has been declared lost or stolen (and thus it cannot be used to complete the transaction). If this is not the case, the SP issues a TOKEN (as explained in Section IV), which is valid for a short time, e.g. 5-10 minutes. From the TOKEN, the UT can recover the OTC data, which can be used for the payment purposes (step 5). Finally, the SP veries the correctness of the OTC (in step 7), and unlocks the gas pump in case the OTC verication completed with success (step 9).

R EFERENCES
[1] T. Weigold, T. Kramp, and M. Baentsch, Remote Client Authentication, IEEE Security and Privacy, Vol. 6, Issue 4, pp. 36-43, 2008. [2] R.J. Hulsebosch, M.S. Bargh, G. Lenzini, P.W.G Ebben, and S.M. Iacob, Context Sensitive Adaptive Authentication, Proc. of EuroSSC 2007, LNCS 4793, pp. 93-109. [3] J. Brainard, A. Juels, R. Rivest, M. Szydlo, and M. Yung, Fourth Factor Authentication: Somebody You Know, Proc. of ACM CCS 2006, pp. 168178. [4] H. Zheng, J. Kwak, K. Son, W. Lee, S. Kim, and D. Won, Condence Value Based Multi Levels of Authentication for Ubiquitous Computing Environments, Proc. of ICCSA 2006, LNCS 3981, pp. 954-963. [5] B. Schneier, Two-Factor Authentication: Too Little, Too Late, Communications of ACM, Vol. 48, No. 4, Apr. 2005, 136. [6] M. Alexander, Keeping Online Banking Safe: Why Banks Need Geolocation and Other New Techniques Right Now. http://www.bankersonline.com/security/safebanking.html, May 2005. [7] Federal Financial Institutions Examination Council, Authentication in Internet Banking Environment, http://www.fec.gov/press/pr101205.htm, Oct. 2005. [8] E. Toye, R. Sharp, A. Madhayapeddy, and D. Scott, Using Smart Phones to Access Site-Specic Services, IEEE Pervasive Computing, SpringerVerlag, Vol. 4, Issue 2, pp. 60-66, 2005. [9] M. Gruteser and X. Liu, Protecting Privacy in Continuous LocationTracking Applications, IEEE Security & Privacy Magazine, Vol. 2, Issue 2, pp. 2834, 2004. [10] D. Liu and P. Ning, Location-based pairwise key establishments for static sensor networks, Proc. of the 1st ACM workshop on Security of ad hoc and sensor networks, Fairfax, Virginia, pp. 72-82, 2003. [11] D.E. Denning and P.F. MacDoran, Location-based authentication: grounding cyberspace for better security, Computer Fraud & Security, Vol. 1996, Issue 2, Feb. 1996, pp. 12-16. [12] A.I. Gonz lez-Tablas Ferreres, B. Ramos Alvarez, and A.R. Garnacho, a Guaranteeing the Authenticity of Location Information, IEEE Pervasive Computing, Vol. 7, Issue 3, July-Sept. 2008, pp. 72-80. [13] M.G. Kuhn, An Asymmetric Security Mechanism for Navigation Signals, Proc. of Sixth Intl Workshop Information Hiding (IH) 2004, LNCS 3200, pp. 239-252. [14] R.A. Malaney, A location enabled wireless security system, Proc. of GLOBECOM 2004, 4, pp. 2196-2200. [15] M. Spelat and F. Margary, GAL-PMI Project: Global Navigation Satellite Systems to Support Mobility and Security, Proc. of Space Applications Days 2008, Toulouse (France), 22-25 April 2008, pp. 608612. [16] J. Ringert, E. Wasle, J. Hanley, and S. Scarda, Bringing Galileo Into LBS Market the Agile Project Proc. of IEEE 17th Int. Symp. on Personal, Indoor and Mobile Radio Communications, 11-14 Sept. 2006, pp. 15. [17] K. Lackey, Thieves skim credit card data at fuel pumps, USA TODAY, 5 August 2008, http://www.usatoday.com/money/industries/energy/200808-04-gaspumpskimming N.htm. [18] TruckFLIX LLC, Fuel fraud: Thieves use pay-at-pump technology to steal millions, https://secure.truckix.com/news article.php?newsid=5298, November 24, 2007. [19] C. Bergstrom, and J. Chuprun, Optimal hybrid frequency hop communication system using nonlinear adaptive jammer countermeasures and active fading mitigation, Proc of IEEE GLOBECOM 98, Vol. 6., pp. 3426-3431. [20] Leemon C. Baird III, William L. Bahn, and Michael, D. Collins, Jam resistant communications without shared secrets, Proc. of ICIW08, Omaha, Nebraska, April 24-25, http://leemon.com/papers/2008bbc.pdf. [21] H. C. Liao, Y. H. Chao, C. Y Hsu, A Novel Approach for Data Encryption Depending on User Location, Proc. of PACIS 2006, July 5-9, 2006, http://www.pacis-net.org/le/2006/1117.pdf. [22] D. Qiu, Security Analysis of Geoencryption: A Case Study Using Loran, Proc. of ION GNSS 2007, Texas, USA, Sept. 2007, pp. 11461154. [23] F. Dominici, D. Mazzocchi, P. Mulassano, M. Spelat, G. Boiero, P. Lovisolo, NAV/COM Hybrid Architecture for Innovative Location Based Payment Systems, Proc of CCNC 2009, pp. 1-5. [24] A.I. Gonz lez-Tablas, K. Kursawe, B. Ramos, and A. Ribagorda, Sura vey on Location Authentication Protocols and Spatial-Temporal Attestation Services, Proc of EUC Workshops 2005, LNCS 3823, pp. 797-806, 2005. [25] K. Nichols Randall and Panos C. Lekkas, Wireless security: models, threats, and solutions, Tata Mgraw Hill, 2006.

VI. C ONCLUSIONS In our work, we proposed the LRAP protocol exploiting both traditional and contextual (i.e. location) authentication factors for client authentication in mobile environments. Furthermore, we designed and implemented a proof of concept for the LRAP protocol, in the form of a real case scenario allowing user to perform payments at the self service gas stations. Future work is foreseen on other aspects of our scheme (e.g. privacy issues, tamper resistant security module, sufcient key space or computation and energy costs).
Acknowledgement. This work was supported by the Piemonte Region (Italy) through the European framework known as DOCUP 2000/2006, Measure 3.4 of the Piedmont Regional Council, in the frame of the GAL-PMI project.

145