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 authen-
tication 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 au-
thentication 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. INTRODUCTION
Authentication is considered the most important security
service staying at the basis of many products and application
services nowadays. To perform authentication, various meth-
ods 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 challenge-
response 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
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 au-
thentication 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 imple-
mentation of the payment service based on LRAP. Finally, we
conclude our paper in Section VI.
II. RELATED WORK
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 technol-
ogy 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
2011 19th International Euromicro Conference on Parallel, Distributed and Network-Based Processing
1066-6192/11 $26.00 2011 IEEE
DOI 10.1109/PDP.2011.32
141
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, Den-
ning & 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 cer-
tifying the position and time information. LE will deliver
enhanced performance in terms of accuracy, integrity, avail-
ability 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
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 prod-
ucts, 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. USE CASE: PAYMENT AT SELF-SERVICE GAS
STATIONS
This use case is suitable for our study because it is still sub-
ject 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. http://www.theriverbank.com/online banking/3mobilebanking.htm
3
http://www.clavister.com/pdf/clavister-dts-sms service.pdf
142
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. LOCATION-BASED REMOTE AUTHENTICATION
PROTOCOL
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 jamming-
resilient 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 sev-
eral 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 authen-
ticating 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 geo-
encryption or location-based encryption refer to a security
algorithm that limits the access or decryption of some informa-
tion content to specied locations and/or times [22]. The algo-
rithm 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 location-
dependent 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 LDEA-
key, 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 algo-
rithm, 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 Final-
key 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.
SP UT
OTC
Symmetric
encrypt
Hash
LDEA-key
generator
Final -key
KSe
Symmetric
decrypt
Compare
digests
LDEA-key
generator
Final -key
KSa
TOKEN (16 bytes)
OTC
hash(OTC,KSa )
KSe
Hash KSa
TD
OK/Error
TD
Insecure
Channel
GPS
receiver Target
UT coordinates
Fig. 1. OTC generation and transmission in LRAP protocol.
Security Analysis. In Fig. 1, both TOKEN =
E(xor(KS
e
, LDEA key), OTC) and keyed hash
Hash(OTC, KS
a
) 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
, KG
a
)
from suitable dictionaries DGe and DGa, for the keys KG
e
and KG
a
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
143
GPS location of the LE and the known TD, and derives OTCG
from observations of E(xor(KS
e
, LDEAkey), OTC) and
Hash(OTC, KS
a
) as:
OTCG = D(xor(KG
e
, LDEA key),
E(xor(KSe, LDEAkey), OTC)) (1)
Then, if Hash(OTCG, KG
a
) = Hash(OTC, KS
a
)
KG
e
= KS
e
and KG
a
= KG
a
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(KS
e
, LDEAkey), OTC), Hash(OTC, KS
a
) 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|.|TDx|). 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 KG
a
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 es-
tablishment (e.g. Dife-Hellman with certicates). This means
that the encryption of OTC is only secure if KS
e
and KS
a
are chosen at random from a sufciently large key space.
For this purpose, we assume the user exploits a pseudo-
random generator for generation of KS
e
and KS
a
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 SERVICE AT SELF-SERVICE
GAS STATIONS
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 consid-
erations on storing security sensitive information (such as the
KS
e
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 short-
range 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.
POS
6: send OTC
4: decrypt
TOKEN
(get OTC)
2: request TOKEN for UT (X
u
, Y
u
, Z
u
)
7: verify OTC:
OK/KO
If OK: check the
users bank account
8: OK/KO
11: if OK,
issue
receipt
3: generate and send TOKEN (16 bytes)
Local Element
Service
Provider
Bank
User
Terminal
9:If OK: select
and
unlock gas pump
Gas pump
5: send OTC
10: If OK: charge
amount on user
bank account
1: get certified coordinates
(X
u
, Y
u
, Z
u
) for UT
Fig. 2. Architecture and workow of the LRAP-based payment service.
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 KS
a
and KS
e
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 tech-
niques 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 at-
testation 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/
144
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).
VI. CONCLUSIONS
In our work, we proposed the LRAP protocol exploiting
both traditional and contextual (i.e. location) authentication
factors for client authentication in mobile environments. Fur-
thermore, 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.
REFERENCES
[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. 168-
178.
[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, Commu-
nications 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, Springer-
Verlag, Vol. 4, Issue 2, pp. 60-66, 2005.
[9] M. Gruteser and X. Liu, Protecting Privacy in Continuous Location-
Tracking 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 alez-Tablas Ferreres, B. Ramos Alvarez, and A.R. Garnacho,
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 Sig-
nals, 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. 608-
612.
[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/2008-
08-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 com-
munication 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. 1146-
1154.
[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 alez-Tablas, K. Kursawe, B. Ramos, and A. Ribagorda, Sur-
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.
145