Provisional Access Control Model for Mobile Ad-Hoc Environments: Application to Mobile Electronic Commerce

Article excerpt

INTRODUCTION

Mobile devices with wireless communication capabilities have become part of our lives. In a mobile environment, compared to the static desktop environment, network resources are constantly accessed through these devices while users are still moving. In this new mobile environment, it is easy to form a mobile ad-hoc network where neighboring mobile devices are forming a self-configuring network connected by wireless links. Examples include vehicular ad-hoc networks (VANETs) where neighboring vehicles communicate important information on road conditions or ride-share, social networks for finding friends, navigation advice in transportation, asset tracking, and mobile collaborative work. Especially, application to mobile electronic commerce is in our particular interests such as online ad-hoc auction market environment where auctioneers allow bidding from neighboring potential buyers.

In this environment, each mobile user is treated as a peer because one can retrieve data from one's neighboring mobile devices, and at the same time, one can provide the information as the other people request the information that she brings. This local search-and-discover action is performed by each peer without connecting to the centralized server.

In order to protect one's own resources, each peer specifies its own security/privacy policies. In a mobile peer-to-peer environment, access control decision depends on (i) specific actions performed before the decision is taken and (ii) also spatio-temporal attributes. First, connection between peers is arbitrary; and thus, it would be more appropriate if the access control decision is based on the conditions that the resource-holding peer has. For example, in online ad-hoc auction market, an auctioneer allows bidding of only serious users who meet the criteria such as reading and signing the contract beforehand. Second, access control decisions are also based on current locations (i.e., spatial attribute) of neighboring peers within the specific time durations (temporal attribute). For example, in location-based services (LBS) applications, a mobile user wants to receive promotion deals only if the current location of the user is within a certain distance from the merchant during the evening hours in order not to be overwhelmed by spam mails from merchants.

The Role-based access control (RBAC) model is popular because it can handle complicated enterprise-wide access requests where the traditional access control models such as Mandatory Access Control (MAC) and Discretionary Access Control (DAC) cannot handle. In RBAC, a role denotes a job function, and permissions to perform certain operations are assigned to specific roles instead of users. Then, each user is assigned to particular roles. Although facilitating resource sharing with enforcing security/privacy policies in a static environment has been discussed (Maruoka, Memati, Barolli, Enokido & Takizawa, 2008; Park, An, & Chandra, 2007; Park & Hwang, 2003; Ravichandran & Yoon, 2006; Silva et al. 2005), it is not applicable to a mobile ad-hoc environment due to the following reasons.

First of all, existing RBAC cannot be directly applicable to a mobile ad-hoc environment since peers are constantly moving over time and the policies are updated based on time and space. A naive solution would use a trusted party which authenticates each user and makes an access control decision. However, this is not practical especially for mobile a-hoc environment where participating peers are not predetermined and do not have the capability to connect to the central server. Also, it creates an issue with scalability of the system because the trusted server must be able to deal with all the access control requests and evaluates each peer's security policies. Considering the fact that these policies are based on space and time as well as specific actions that each peer has performed, overheads to the system to enforce these policies would not be scalable. …

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.