The Second International Conference on Emerging Security Information, Systems and Technologies
Controlling Access to Location-Based Services in Vehicular Mobile
Pervasive Environments
Sameerchand Pudaruth, Nevin Vunka Jungum, Soulakshmee D. Ghurbhurrun
and Leckraj Nagowah
Computer Science and Engineering Department, University of Mauritius, Rduit, Mauritius
s.pudaruth@uom.ac.mu, nevin.vunka@umail.uom.ac.mu, s.ghurbhurrun@uom.ac.mu,
l.nagowah@uom.ac.mu
Abstract
Management of access control to location-based
services in vehicular mobile pervasive environments
presents several new challenges such as invisibility,
localized scalability and privacy. To our knowledge,
merging location-based services in pervasive
environments with vehicular mobile environments is
still in its infancy. To this end, we present a descriptive
architecture for controlling access to services. Based on
a comparative analysis of different access control
models, we devised a new set of access control
requirements for such environments and show their
integration in the proposed architecture.
Keywords: vehicular networks, location-based
services, access control, requirements, architecture,
pervasive environment
1. Introduction
Vehicular Ad-Hoc Network (VANET) communication
has recently become an increasingly popular research
topic in the area of wireless networking as well as the
automotive industries. The goal of VANET research is
to develop a vehicular communication system to enable
quick and cost-efficient distribution of data for the
benefit of passengers safety and comfort. Built on top
of such infrastructures are value-added services such as
location-based services (LBS). In vehicular mobile
environments, LBS are beneficial for drivers in the
sense that they provide information about various
services such as restaurants, cinemas, shopping centers
discounts and so on. Consider the scenario where a
driver/ car passenger can actually browse a cinemas
program and subsequently book seats while
approaching the cinema hall despite of being some
100m away. Or consider the case of an employee who
can actually access a gate service, while approaching
his workplace in his car. It is worthwhile to point-out
that, technologies to enable such scenarios already exist
and the costs of such developments are relatively
reasonable and within reach for developed countries.
978-0-7695-3329-2/08 $25.00 2008 IEEE
DOI 10.1109/SECURWARE.2008.41
To this end, questions that need to be asked are: why
are we not experiencing extensive proliferation of such
systems? How far have deployed systems been accepted
by the end-users, i.e., the drivers? How to ensure the
sustainable growth of such systems for the enhancement
of peoples life? How far are end-users willing to give
private/confidential information to have access to these
personalised services? Answers to these questions are
subjective, but most would agree that security is
essential for the wide deployment and acceptance of
such systems. We firmly believed that for the wide
deployment and sustainable growth of such services,
security is important, more precisely, access control,
i.e., controlling access to them.
For the development of a secure access control system,
a well defined, modular and extensible structure and
clearly defined architectural components are necessary.
Even though several access control models have been
developed, our work shows that none of them are
concrete and reliable enough to be deployed in a non-
simulated real life pervasive environment. The
fundamental requirements needed by an access control
system have been analyzed for deployment in a
pervasive environment. Precision and completeness in
basic access control requirements formulation is of
paramount importance as it is this foundation work that
will mostly influence the design of the access control
model. We performed an access control analysis to
verify the degree of importance of requirements for the
building up, support and completeness of an access
control system.
After comparative evaluation of the existing access
control models, a new vital requirement is identified for
consideration by future models, namely autonomous
behavior, i.e. the ability of the access control system to
be able to monitor the users interaction patterns to
enable it to auto-correct future access control errors by
using knowledge gain from previous interactions.
Hence, access control models should be self-healing.
This work will be of great asset to researchers and
designers in the field of access control for optimizing
the design of secure pervasive systems.
The rest of the paper is as follows: Section II
presents a vehicular mobile pervasive environment
transport service with some motivating scenarios.
22
Section III describes the fundamental requirements of
an access control system, followed by an analysis of
existing access control models to verify whether they
meet the requirements discussed. The access control
architecture is illustrated in Section IV with detailed
description of the different components involved.
Section V explains how the access control architecture
manages the access control process. Finally, Section VI
concludes the paper.
2. Motivating Scenario
Vehicles participating in the vehicular service
infrastructure (Figure 1) are equipped with an
embedded microprocessor with a display interface, a
GPS receiver, a class 1 Bluetooth sensor node, and an
onboard diagnostics (ODI) interface. Some vehicles
may have alternative wireless network connectivity
support based on an on-board cellular communication
device. The ODI is used to acquire a small set of data
values from mechanical and electronic sensors mounted
on the vehicle. All subsystems (GPS, ODI, wireless
networking and Bluetooth links) are connected and
forward data to the embedded microprocessor. A
navigation software system enables the association of
the vehicles geographic position to an internal data-
structure representing the road networks of a large
geographic area around the vehicle. This type of data
structure is easily constructed from publicly available
geographic referencing systems [23], [24].
Alternatively, the vehicle can also be equipped with a
Bluetooth-enabled mobile phone onto which the client
application supports collaborative navigation system.
Consider the scenario in Figure 2 again. The driver of
vehicle X is moving to the west of William Street to
reach the last building in that street where he actually
works. While he approaches the building with his car,
the wireless stations of his workplace along the roadside
detect his presence and automatically alert him via the
navigation system, running on a computer embedded in
his vehicle or mobile phone, whether he wants the gate
to be opened. He chooses yes and soon as he was
only a few meters away from the gate, the latter opens
automatically. This scenario clearly indicates that
access to relevant resources in a mobile pervasive
environment is not only based on the users authenticity
or domain of access but also largely influenced by the
location of the user. An additional piece of information
that this service could have considered before
authorizing access to a resource is time. If it was around
2300 hours and the employee of vehicle X is not
scheduled to work during night time, then the gate
service alert would never have been sent.
To handle the above scenario and access control
management in general, a flexible and dynamic access
control framework is required to be integrated within
the service infrastructure that uses contextual
information such as users information (e.g., working
schedule), location (e.g., near workplace) and time (e.g.,
23
2300 hrs) information before deciding upon the
allocation of a resource.
Newton St.
X
William St.
King St.
X Workplace
Traffic direction
Wireless station
Building
Bluetooth Connection Vehicle
Figure 1. Access to services in an IVC scenario
3. Access Control Requirements
Pervasive environments impose new security
requirements, especially in the domain of access control
such as interoperability, scalability, usability, privacy
and trust management [1][2]. In this section, the
functional requirements of an access control model
implemented in a vehicular mobile pervasive computing
system are discussed. The aim is to highlight some of
the unique characteristics brought on by the vehicular
ad-hoc networks and pervasive computing, to point out
access control architectural implications.
A. Flexibility in the definition of access policies
One very important requirement is the ability to create
and maintain flexible access control policies [3] to
make easy the management task of specifying and
maintaining the security specifications. The access
control system should be expressive for specifying in a
flexible way different protection requirements that can
be imposed on different objects. An example of
ensuring flexibility, is by the inclusion of contextual
information [4][5] to influence access control decisions.
The model should define a generic access control policy
and later be able to customize it for specific scenarios
by the incorporation of external rules/events and
parameters. Contextual information [5] includes the
users security policy, systems security policy,
environmental parameters, position of the interacting
entities, user interaction type, etc. Flexibility also means
the ability of adding new, removing, and/or modifying
existing security constraints. Hence, the generated
access control policies during run-time of the
application should be simple to facilitate the
management of the maintenance of the policies in real-
time.
B. Invisibility
One of the key motivators of pervasive environment
advocated by Langherich [6] is the invisibility issue.
Providing high degree of invisibility is extremely
important [5]. After all, the automation of daily
activities is one of the aims of pervasive computing
technology. Therefore it is ideal to provide entirely
human-free interactions [7]. Complete disappearance of
pervasive computing technology should be considered
in access control applications. An access control
mechanism [8] must work with minimal active
participation from the user. Determining access rights
correctly requires the consideration of a complex set of
drivers representing relationships between entities and
the current context governing those entities. Hence, for
authorizing an access to a service, it is necessary to
gather sufficient and different credentials of the user.
The framework should hide the existence of real
interactions that will also result in less user distraction.
C. Critical Events
Most of the actual existing access control mechanisms
do not take critical events [9] into consideration.
Examples are Role-Based [10], Time-Based [11],
Location-Based [12], Proximity-Based [13], Task-
Based [14], Team-Based [15], Attribute-Based [16],
Token-Based [17] and Context-Aware Role-Based [18].
In general, all systems have two modes: normal and
abnormal. Critical events occur when a system is in an
abnormal state, thus service requirements may changed
radically. In a pervasive environment covering, for e.g.,
a small city, standard access control policies may
prevent, for e.g., fire brigades, access to certain
buildings which are on fire. For example, fire brigades
brought in from neighboring cities in response to a fire
disaster may not automatically be granted access to
buildings in the smart city.
A pervasive computing system needs to be able to
observe its environment continually and to take
corrective measures in case of environmental changes
which can cause the system to enter an abnormal state.
Such an environmental change is known as Critical
Events. Once a critical event has been detected, the
system should take immediate (as soon as the criticality
is detected) action to control its effects.
D. Privacy/Anonymity/Client-side Restriction
The more a system knows about the users and the
application environment, the more it can provide fine-
grained access control to protected resources. But this
also implies an increase in the risk of compromising the
users privacy. An example is location privacy [19].
Location information of users captured by sensors on
an ongoing basis generate an enormous amount of
potentially sensitive information. Privacy of location
information is about controlling access to this
information. This cannot be stopped because some
applications use this information to provide useful
services, but it should be in control. One way for an
24
access control system to ensure privacy protection is by
frequently changing pseudonyms or by generating a
multiple digital identities so that users are avoided from
being identified by the locations they visited but at the
same time they can fully enjoy a service that require
their location information.
E. Overall Performance
An access control system should be fast and consume
minimal amount of resources. Designing the flow of
data in the system must not be complex. The overheads
associated with it must be minimized. For example, if
the access control system is able to collect sufficient
credentials about its users without putting their privacy
at stake, this will result in a reduction of the overheads
associated with the repeated exchange of information at
different authentication points.
F. Autonomous behaviour
The model needs to be able to monitor the users
interaction patterns to enable it to auto-correct future
access control errors or enhance services list, by using
knowledge gained from previous interactions. That is, it
should be self-healing.
TABLE I. ANALYZING ROLE AND IMPACT OF REQUIREMENTS
Requirements Role and impact on an access control
model
- The model should define a basic/generic
access control policy and later be able to
customize it for specific scenarios.
Flexibility in - The model should be simple to ease the
the definition of management of the different tasks and
access policies maintenance of the security specifications.
- It must be flexible enough to add new,
remove and/or modify existing security
constraints.
- Usage of contextual information to further
enhance the flexibility of the model.
- The model must be able to gather sufficient
Invisibility credentials to authenticate a user but at the
same time hide the interactions between the
user and the system.
- The model must have a component that will
be responsible for continuously monitoring
the system in case a critical event occurs.
Critical events - The model should be able to change
policies in response to a critical event.
- Changes in policies should not affect the
normal working of the system.
- Configuration of privacy access control
policies.
Privacy/Anonymity/ - Management of privacy requirements of the
Client-side owner of the information, that of the collector
restriction and possible privacy laws.
- Privacy rules must be attached to the data
during their movement in the system among
different parties.
- Consumers of the data must manage the
data only by following the privacy rules.
- The model should allow users to specify
their own restrictions when their information
is accessed by a third party.
- The system must not be resource greedy,
Overall minimize overheads and must follow a
performance simple design.
 - The model need to be able to monitor the
Autonomous users interaction patterns to enable it to
behavior auto-correct errors by using knowledge gain
from previous interactions, that is, it should
be self-healing.
discussed in Section II. We proceed with the detailed
description of the different components of the
architecture.

We further analyzed five existing access control models J2SE Environment

to verify their degree of validity in such environment, Policy
Manager
i.e., we have checked whether they meet the above Pattern Identifier
Policy
requirements or to what extent, as shown in Table III. Information
The scaling of 1 to 5 is used, where 1 denotes No
Consideration and 5 denote Absolute Consideration. Access Control
Engine
Refer to Table II below for more scaling details. Service
User
Manager Manager
Service
TABLE II. SCALING LEVEL USED FOR MODEL ANALYSIS Information User
Information
Privacy
Rating Degree of consideration Authorization
Unit
Manager

1 Nil / No consideration Critical Unit

2 Weakly / Less than average
3 Partially / Medium / Reasonable
4 Mostly / But not complete
5 Fully / Strongly / Absolute consideration Service
Request / Response
TABLE III. AC MODELS REQUIREMENTS ANALYSIS
Figure 2. Access Control Architecture
Role Location Attribute Team C-A
Based Based Based Base Role Controlling access to services in this system is based on
Requirements [10] [12] [16] d [15] Based
[18] an extended client-server computing model. In this
Flexibility 2 5 5 5 5 model, a driver located in a particular road, requests for
Invisibility 5 5 5 5 5 a service via a Bluetooth-enabled mobile device. This
Critical events 1 1 1 1 1 request is sent toward the wireless base station of that
Privacy 3 3 3 3 3 road segment. The server processes the request and
Overall Perf. 3 3 3 3 3 decides whether access should be granted or not.
Auto. Behavior 1 1 1 1 1
Below are the functions of the different components of
the architecture:
At design time of Role Based AC model, there is The Service Manager (SM) deals with all the services
moderate flexibility to specify complex context-aware hosted on the server. It has the responsibility of
authorization policies. In Context-Aware Role Based managing the services stored in the Service Information
AC, there is the Policy Adaptation mechanism to ensure (SI) repository.
a smooth flow of operations in new scenarios and rules The Policy Manager (PM) has the task of adding new
have to adapt to unforeseen events. policy and deleting existing ones when required in the
Team Based AC mechanism allows us to create a Policy Information (PI) repository. Adding new policies
general structure (class/definition) of a team with role- occurs when new services are added by the SM. The
based permission assignments to object-types. PM is also accountable to identify conflicts between
However, when a team is instantiated, the user context fired rules and to resolve them. A conflict occurs when,
can be used to tailor the role-based permissions defined based on the current context, more than one policy is
on object types to user-specific permissions on fired while some of them result in granting the access
individual object instances considered to be part of a while others result in revoking the access. Works such
team's resources. as [20][21] discusses conflict detection and resolution
As pointed out above, the model needs to be able to based on the context changes.
monitor the users interaction patterns to enable it to The User Manager (UM) deals with user information.
autocorrect future access control errors by using The UM authenticate users based on their request to
knowledge gained from previous interactions, that is, it access services. The UM manages the users
should be self-healing. But none of the models above information stored in the User Information (UI)
takes this requirement into consideration. The same repository. It also provides users preferences
applies for critical events. information and profiles when required by the Access
Control Engine (ACE).
4. Access Control Architecture The Privacy Unit (PU) ensures the privacy protection
of users. It is responsible to frequently change the users
In this section, we present an access control architecture pseudonyms so that the users are avoided from being
(Figure 2) that takes into consideration the requirements identified by the locations they visited through man-in-

25
the-middle attacks and at the same time can fully enjoy
a service that require their location information.
The Pattern Identifier (PI) identifies patterns in the
users interaction behavior so as to enhance services
retrieval list and reduces processing time. It uses
information stored in the UI repository. This component
ensures the autonomous characteristic of the access
control model.
The Access Control Engine (ACE) uses location
information, time, user information and policies to
decide whether to grant or revoke access to services.
The Authorization Manager (AM) receives different
access requests for different services. It passes the
requests to the ACE. Based on the response obtained
from the ACE and the Critical Unit (CU), the AM
decides whether access should be granted or not.
In the case of critical events as described in Section II
(C), the Critical Unit can largely influence access
control decision made by the AM thus overriding
policies if necessary.
5. Access Control Process
This section explains how the access control model
deals with incoming service requests and manages the
access control process. The process is divided into five
main stages. The description of each stage is as follows:
1. Initiation: When a vehicle enters a serviced zone and
is detected by a server which requests for its
authentication information (e.g., userID and
userPassword). If the user is a valid one, the server will
next try to find a list of services for that user.
2. Service Discovery: The ACE passes the userID
reference as parameter to the SM. Upon receipt of a
request for a list of services based on the received
parameter, the SM starts to find a set of suitable
services. It then makes a service list comprising of
serviceID and serviceName as attributes which
represents the id of a service and its corresponding
name respectively. This service list is then sent as a
response to the ACE request.
3. Firing Policies: The ACE needs some policies for
making decision for each and every service in the
service list. After sending a request for some policies
based on the current context such as time, date, location
and serviceID to the PM, policies will be fired. If there
is a need for some extra-information about the user, a
request for them will be send to the UM.
4. Decision Process: The ACE will then decide
whether access to a service is granted or not based on
the policies. If it is granted, the service will be put in an
accept stack list to be sent later to the AM. If it is
revoked, the ACE will add this service to a reject stack
list which will also be sent to the AM. It will then check
the service list to see if another service exists, and the
whole process starts again until the service list becomes
empty, after which, the accept stack list and reject stack
list are both sent to the AM.
26
5. Authorization: Firstly, the AM puts all service
names and their corresponding ids, extracted from the
accept stack list, in an authorized service list. Secondly,
it will listen for input from the CU in case of critical
events. In there are no critical events, the input
parameter supplied by the CU to the AM is NULL. On
the contrary, a critical list comprising of serviceIDs is
supplied and this is compared with the reject stack list.
serviceID that matches, are quickly added to the
authorized service list together with the corresponding
serviceName attribute. This process is looped until the
critical list is empty. Once the latter is empty, the
authorized service list is assumed to be complete and is
thus sent to the concerned vehicle.
There is some additional processing that is performed.
In stage 3, when a request is sent to the UM for
additional information, the latter invoke the PI with
userID as parameter to identify behavioural patterns of
the concerned user. An example of a typical data set is
shown in Figure 3 below.
Figure 3. A typical data set
To extract behavioural patterns in the User
Interaction Data Set, shown in Figure 3 above, two sets
of pattern are considered: firstly, patterns in user service
invocation and secondly, patterns in user location
and/or time. Sequence analysis [22] identifies
sequential patterns in a large volume of transaction
data. A sequential pattern consists of a sequence of
items that frequently occur in the data. A possible
pattern could be: Seminar Restaurant. This indicates
that when the user visited a Seminar service he also
subsequently visited the Restaurant service.
6. Conclusions
In this paper, we performed a comprehensive
analysis of access control requirements reported in the
literature for the past ten years. Based on our
evaluation, we conclude the event criticality is a key
ingredient for access control models. Some works
reviewed propose access control for pervasive
environments, but most of them do not take an
extensive context requirement of the user and the
system into account in a satisfying way, though it must
be central in pervasive environments. These models do
not address some pervasive-related issues. The
originality of our analysis relies in the specification
possibilities to define access control requirements
precisely and easily secure policies useful in a vehicular
mobile pervasive environment, thanks to a strong
theoretical background. We then present an access
control architecture that satisfies the requirements
identified and furthermore describe the access control
process. Currently, we are developing a low-cost
prototype based on Bluetooth technology to finally
proceed with testing in a real environment.
References
[1] Yeun C., Lua E., and Crowcroft J., Security for
Emerging ubiquitous networks, IEEE International
Conference one-Vehicular Technology, Volume 2, pp.
1242-1248, 25-28 September 2005.
[2] Wang J., Yang Y., and Yurcik W., Secure Smart
Environments: Security Requirements, Challenges and
Experiences in Pervasive Computing, NSF
Infrastructure Experience 2005, NSF/CISE/CNS
Pervasive Computing Infrastructure Experience
Workshop , Siebel Center for Computing Science
University of Illinois at Urbana-Champaign, July 27,
2005.
[3] Iachello G., and Abowd G. D., A Token-based Access
Control Mechanism for Automated Capture and Access
Systems in Ubiquitous Computing, GIT Technical
Report GIT-GVU-05-06, Georgia Institute of
Technology, GVU Center, 2005.
[4] Damiani E., De Capitani di Vimercati S., and Samarati
P., New Paradigms for Access Control in Open
Environments, Proceedings of the Fifth IEEE
International Symposium on Volume , Issue , 18-21 Dec.
2005 Page(s): 540 545
[5] Javanmardi S., Hemmati H., and Jalili R., An Access
Control Framework For Pervasive Computing
Environments, presented at International Conference on
Pervasive Systems & Computing PSC'06, Nevada, USA,
2006.
[6] Langeheinrich M., Privacy by Design Principles of
Privacy Aware Ubiquitous Systems, in UBICOMP
2001, LNCS 2201, pp 273-291, 2001.
[7] Garlan D., Siewiorek D.P., Smailagic A., and Steenkiste,
Project Aura: toward distraction-free pervasive
computing, Pervasive Computing IEEE, Volume 1, pp.
22 31, Issue 2, April-June 2002.
[8] Kottahachchi B., ACCESS: Access Controls for
Cooperatively Enabled Smart Spaces, In MIT Student
Oxygen Workshop. Ashland, MA. September, 2004.
[9] Gupta S. K. S., Mukherjee T., and Venkatasubramanian
K., Criticality Aware Access Control Model for
Pervasive Applications, In Proc of 4th IEEE Conf on
Pervasive Computing, Pisa, Italy, March 2006.
27
[10] Sandhu R., Coyne E., Feinstein H., Youman C., Role-
Based Access Control Models, IEEE Computer, vol. 29,
num. 2, p. 38-47, 1996.
[11] Bertino A.E., Bonatti P.A., Ferrari E., TRBAC: A
Temporal Role-based Access Control Model, ACM
Transactions on Information and System Security, 4(3),
August 2001, pages 191-233.
[12] Ray I., and Kumar M., Towards a Location-Based
Mandatory Access Control Model, Computers &
Security, 25(1), February 2006.
[13] Gupta S. K. S., Mukherjee T., Venkatasubramanian K.
K. and Taylor T. B., Proximity Based Access Control in
Smart-Emergency Departments in PerCom Workshops
2006, pp 512-516.
[14] Zhang C-x., Hu Y-x., and Zhang G-b., Task-Role Based
Dual System Access Control Model, IJCSNS
International Journal of Computer Science and Network
Security, VOL. 6 No. 7B, July 2006.
[15] Thomas R. K., Team-based Access Control (TMAC): A
Primitive for Applying Role-based Access Controls in
Collaborative Environments, in proceedings of the
RBAC 97 Fairfax Va USA, 1997.
[16] Wang L., Wijesekera D., and Jajodia S., A Logic-based
Framework for Attribute based Access Control, in
proceedings of the CCS04, October, 2004.
[17] Iachello G., and Abowd G. D., A Token-based Access
Control Mechanism for Automated Capture and Access
Systems in Ubiquitous Computing Georgia Institute of
Technology GVU Center Technical Report GIT-GVU-
05-06.
[18] Shen H. and Hong F., A Context-Aware Role-Based
Access Control Model for Web Services proceedings of
the ICEBE 2005, pp 220-223.
[19] Beresford A. R., and Stajano F., Location Privacy in
Pervasive Computing, Pervasive Computing Magazine,
2003.
[20] Syukur E., Loke S.W., and Stanski P., Methods for
Policy Conflict Detection and Resolution in Pervasive
Computing Environments, In Policy Management for
Web workshop in conjunction with WWW2005
Conference, Chiba, Japan, 10-14 May 2005.
[21] Kamoda H., Yamaoka M., Matsuda S., Broda K., and
Sloman M., Policy Conflict Analysis Using Free
Variable Tableaux for Access Control in Web Services
Environments, Policy Management for Web, A
WWW2005 Workshop 14th International World Wide
Web Conference, 10 May 2005, Chiba, Japan, pp. 5-12,
May, 2005.
[22] Srikant R. and Agrawal R., Mining sequential patterns:
Generalizations and performance improvements,
Technical Report, IBM Almaden Research Centre, 1999.
[23] U.S. Census Bureau. Topologically Integrated
Geographic Encoding and Referencing system,
http://www.census.gov/geo/www/tiger/ (accessed on 31st
January 2008).
[24] T. Nadeem, S. Dashtinezhadd, C. Liao, and L. Iftode,
Trafficview: Traffic data dissemination using car-to-car
communication, ACM Sigmobile Mobile Computing and
Communications Review, Special Issue on Mobile Data
Management, vol. 8, no. 3, pp. 619, July 2004.