EUROCON 2005
Serbia & Montenegro, Belgrade, November 22-24, 2005
Using Sensor and Location Information for Context-Aware Access Control Laurent Gomez, Luminita Moraru, David Simplot-Ryl, and Konrad Wrona, Members, IEEE Abstract —In ubiquitous computing environments, context information (such as user’s location, time, etc) can have an impact on business applications and can be used to adapt the security parameters of such applications. In this paper, we are proposing a framework for enforcing security rules dependent on the current state of the environment. We define proximity-based and context aware access control, by including context information as an element of access control policies.
Keywords — Access control, context-aware security, ehealth applications, sensor networks
I. INTRODUCTION Access control is concerned with limiting the access of the authenticated users to services and resources. The highlevel rules specifying the conditions under which users are allowed to access resources are defined by access control policies. Different mechanisms for implementing security policies are available, most of them using proprietary languages. This limits both the interoperability between domains and the reuse of the policies for a different type of applications. Currently, access control decisions are made accordingly to the standard Role Based Access Control (RBAC) [1] model. The purpose of the RBAC model is to simplify the management of permissions in an organization. Each user has associated one or several roles and permissions to objects (data) are defined for each role. This model does not include context information. In order to address this problem, some solutions have been proposed (e.g. GRBAC (generalized RBAC) [2] and Dynamic Role Base Access Control model (DRBAC) [3]). GRBAC generalizes the notion of a role with environment roles, such that the policies evaluation considers the state (active or not) of the environment roles for each authorization decision. It is defined using languages based on predicate logic. The framework we are proposing is addressing the contrast between the ease of use of XML and conventional L. Gomez is with the SAP Research, Av. du Dr Maurice Donat 805, 06250 Mougins, France, email:
[email protected] L. Moraru was with INRIA futurs, POPS research group, IRCICA / LIFL, University of Lille 1, France, email:
[email protected] D. Simplot-Ryl is with INRIA futurs, POPS research group, IRCICA / LIFL, University of Lille 1, France, email:
[email protected] K. Wrona is with the SAP Research, Av. du Dr Maurice Donat 805, 06250 Mougins, France, Phone: +33 492 286 285, email:
[email protected] This work has been partially sponsored by European Commission within FP6 IST Project 4636 (MOSQUITO).
mechanisms of securing data. We are integrating context information into access control decisions by extending XACML [4], an XML derived language, used for building security policies. The evaluation of policies takes into account both identity/role of a requester and the environmental context. Access is restricted only to the authorized users and only in specific circumstances. Since the user has to provide personal information, both the confidentiality and the integrity of the shared data are required. We are achieving this by using security mechanisms such as encryption and digital signature. The use of digital context information has also the advantage of providing authentication of the signer. The first targets for the proposed framework were medical emergency applications, where location and medical information acquired by a personal area network are used for providing permissions. Based on context aspects, defining, e.g. the proximity of authorized medical personnel and readings from the health status sensors, we enable doctors to get an emergency access to otherwise confidential medical information about the patient. The framework for context-aware access control includes mechanisms for analyzing the full path of context data, from the acquiring phase to the policy evaluation phase. Context information provided by a wireless sensor network is also integrated. Sensor networks are particularly suited for health and environment monitoring, due to the integration of sensing and communication capabilities into small embedded devices. II. E-HEALTH SCENARIO We based our solution on a scenario that includes context aware security. In our scenario, one of the patient’s devices is storing his medical history. Medical history is helpful in providing the first aid (e.g. to decide what treatment should be applied). But it represents a confidential data, which the patient might not want to disclose. The legal requirements for access control to electronic medical data, also introduce an important security challenge. Our solution consists of a health monitoring system connected to a rescue center for emergencies. This system will detect the potential health risks and will alert a rescue team. Once the information about the location is received, the intervention team will look after the patient. The device of the physician will send a request to access personal medical files. The request is including into a digital certificate the information about its location. If the physician is close to the patient and the patient health is in danger, the access to personal data is permitted. The access
decision will be made based on the information encoded into the certificate and those retrieved from the patient devices. The patient’s GPS is providing de location and a pulse measuring device is providing the health status. Access decisions are made by evaluating security policies. These security rules are written by extending the XACML language to include environmental data, as described below. III. SECURITY RULES A. Policies XACML supports the standard RBAC model [5]. The model based on roles differentiates between two types of policies: role policies, which associates a role with set of permissions and permission policies, containing the conditions necessary for a positive evaluation of an access request. Each role policy references the set of permissions policies defined for the specified role. Policies’ applicability to a request is determined by matching actions, subjects and resources .Each time a request is received by the system, it identifies the owner by its role, stated as a property of the subject. Based on this, a policy referencing the policy set that must be evaluated is defined. Role based policies are not enough to support context evaluation in access control. The standard mechanism provided by XACML, and which we used for verifying if the environmental context is compliant with requirements, is represented by the rules contained into a policy. Defining the same environment condition for each role is increasing the complexity of the policies and makes it more difficult to understand them. We considered separate policies that take the conditions imposed by the changing environment into account, while separating roles and environment. PPS:physician:role < /PolicySetIdReference> ContextPolicySet:PhysicalContext:Proximity < /PolicySetIdReference> ContextPolicySet:UserContext:MedicalCondition < /PolicySetIdReference>
B. Syntax extension A policy contains a domain of applicability, defined by the target field and checked for any request. It also contains an authorization decision: permit or deny, defined by the rules field of the policy. Most of the time, conditions are imposed for the decision to be valid. Conditions are also part of the rule. They are composed of functions evaluating values of different parameters. XACML provides a vocabulary for defining access control policies. For this, it uses a syntax mainly composed of basic data types and enabling functions for evaluating them. At the same time, it provides an extension mechanism to enable evaluation of user defined parameters. Multiple taxonomies were defined for the location and characteristics of a person. The classification used in our
implementation is found in [6], where authors differentiate between four basic categories of context: user, physical, temporal and computing system context. Our extensions cover location and health status: Context:Attribute:HeartRate Context:Attribute:BloodPressure Context:Attribute:Temperature Context:Attribute:Latitude Context:Attribute:Longitude Context:Attribute:Distance
XACML specifications allow additional functions with the restriction that the result should only depend on the parameters specified into the policy and not on hidden parameter values. For this scenario, the distance using the geographical coordinates is evaluated in order to determine if the proximity condition is verified: Context:Function:CloseTo
Another evaluation is made about the health condition of the patient. A critical result of medical status will positively evaluate a file access request: Context:Function:IsEmergency
Often, more than one restriction is defined, and a method for generating a response that considers all the conditions is necessary. Once the set of applicable policies is found and evaluated, a final decision is made by considering all evaluation responses. XACML apply policy combining algorithms to make authorization decisions based on the evaluation of a set of policies and rule combining algorithms to conclude the evaluation of multiple rules. Each rule has defined a request decision, which is permit or denies and is returned after a positive evaluation of the rule’s condition. If the conditions are not positively evaluated, the rule is considered as not applicable to a specific request and if the parameters value is not found, the conditions are considered as indeterminate. Standard combining algorithms (denyoverrides, permit-overrides, first-applicable and only-oneapplicable) were not found proper for this case. The suitable algorithm only permits access if all policies are evaluated to permit: Context:CombiningAlgorithm:PermitIfAllPermit
For example, if the communication link with one of the sensors is lost, the result will be indeterminate. Also, for the policy that checks the health monitoring parameters, to see if it is emergency, if the health status of the patient is not evaluated to critical the rule evaluating the medical condition is not applicable. In this case, of a non-emergency situation, the policy will also be not applicable. In both cases, it is necessary to restrict access, and the algorithm applied above deals with all these situations. C. Request evaluation Each time an authorization request is received, it is evaluated by the context aware policy decision point (CAPDP) (Fig. 1).
CERTIFICATE STORE
CA - PDP
INFERENCE MODULE
SENSOR PROXY
SENSOR MODULE SENSOR MODULE
Fig. 1 Context data flow The CA-PDP evaluates policies by comparing the values of the attributes stored in policies with the current values of the context associated parameters. There are two sources for the values of context parameters stored in a CA-PDP. First, the request contains attributes provided by the user as part of the digital certificate. They are identified in a request with the user-context value of the AttributeId. A mapping function between the attributes stored into the certificate and XACML data types is defined. The Name field of the attribute from the certificate becomes a new class instance. All the attributes are instantiated through a proxy. If a data type is not defined, the attribute is dropped. Only attributes describing the user can be found in a request, not those describing the environment. For retrieving environment attributes, a sensor interface is used. It offers a common interface to different acquisition modules (e.g. GPS receiver, pulse sensor). There are two communication possibilities between the interface and the sensor modules: by listening for all the incoming events from a sensor or by sending a request for a value each time it is needed. The inference module verifies if, based on existing parameters, new data types can be instantiated. For example, the HealthStatus is evaluated based on raw values of the health parameters: the pulse and the heart rate. The inference module contains a mapping between data types that can be obtained by inference and the required data types. D. Digital certificates Since the access control mechanism makes the decision of whether or not a party can be granted access based on properties of that party, a secure way of transporting these properties must be provided. The method preferred here is based on digital certificates. Digital certificates contain statements about their holder, certified by trusted entities. X.509 represent the most common format of digital certificates. Designed as identity certificates, they were extended to support the binding of a public key with attributes of a request. We used proprietary EureCA attribute certificates, based on XML. These certificates were chosen due to their data structure flexibility. They include the common fields for a digital certificate: the holder, the issuer, a validity period, attributes and the signature of the issuer. The advantages provided by this type of certificates are that they have both a human readable form and an extension point for defining new attributes.
We will preserve the structure used for roles, while using the extension points for transferring context information. A user will send enclosed into a certificate data provided by a sensor (e.g. geographical coordinates indicated by a GPS receiver). The values measured by a sensor are included into the attributes fields of the certificate. An example is presented below: < xac:Attribute xsi : type = ”xac : AttributeType” > < xac : Name > Location < /xac : Name > < xac : Value > Hospital < /xac : Value > < xac : Description > Holder current location < /xac : Description > < /xac : Attribute >
IV. CONTEXT SENSING A. Health monitoring The first purpose of our framework is to enforce context aware access control for medical emergency applications. The permission decision is made based on the health indicators connected to a patient. The choice of sensing devices represents a compromise between non-intrusitivity, wearability and the accuracy of measurements. The most precise method for measuring the heart rate implies attaching electrodes to the chest of the patient. A non-invasive method of monitoring, that we choose, is a finger pulse oximeter. A pulse oximeter measures the oxygen concentration in blood, by monitoring the pulsations in the capillaries produced by the heartbeats. B. Location tracking In order to provide location information, the most important factor that must be taken into account is the coverage area of the chosen positioning technology, because location awareness is a permanent condition. The second is the accuracy since the position of the rescue team relative to the patient is a decision factor in access decision. A description of the available location sensing technologies is made in [7]. They spread from coarse grain technologies like Global Positioning System(GPS) (for outdoor coverage) and Wireless Networks technologies (Bluetooth, Wi-Fi) based systems inside the buildings to fine grain technologies based on ultrasound or ultra wide band radio signals. A positioning mechanism, based on devices commonly used in a personal area network (PDA, laptop) without the need of additional devices, is described in [8]. Since the GPS system is restricted for indoors use, a complete connectivity can be achieved by combining the two methods. Another option is to use the mobile telephony service provider, which will compute the location and send it to the user. The drawback of this method is the low accuracy: around 100 meters and possible legal issues generated by sharing the location information between the operator and third party service providers. We used a GPS receiver; model GS-R230 from Guidetek Technology, suited for devices with Bluetooth support. Similar to all the sensors used, a proxy is defined in order to provide a common interface for accessing all environmental variables.
The GPS is configured to work in push mode, which means that it periodically sends the information acquired from the satellites. The proxy used for communicating with the GPS interprets the standard format of messages used by the location devices, defined by the NMEA protocol. It further makes available the values for geographical coordinates through a TCP/IP socket connection. C. Sensor network For the sensor networks we used devices provided by Crossbow The used architecture includes sensor boards to acquire information, radio transceivers to route information from one point to another, and gateways to provide network connectivity to a PC or to the Internet. Each network node has sensing capabilities. The information available from sensors indicates the temperature, the light level, the acceleration and the magnetic field. A node also needs to forward or/and process the measured data. These tasks are accomplished by a Processor Radio board, MicaZMote. It is compliant with the Zigbee standard that provides low power consumption for radio transmission. In the case of ad hoc networks, the connectivity of the nodes to the base station is provided by multi-hop routing. The base station, a Stargate board, is used to forward the measurements requested by the application. It is based on a Linux embedded operating system and provides support for Wireless, Bluetooth and Ethernet connections. It represents the proxy for the environment variables measured by the sensors. In order to disseminate the sensed information, a Mote retrieves the DC level of the port used to communicate with a specific sensor. The gateway translates between the DC values to international measurement units. Similar with the location it provides a server over a TCP/IP socket, which listens for incoming connections and delivers an up to date value for the requested parameter. V. CONCLUSIONS AND FUTURE WORK In this paper we proposed a solution for defining security rules dependent on the changing context. For this we used a language suitable for a large group of applications (e.g. web services). It can be used in distributed environments, due to the interoperability with other XML languages, (e.g. Security Assertion Markup Language, used to transfer security assertions). Both the utility and the efficiency were proved by a demonstrator for an eHealth scenario. In this scenario the access of a physician to the patient’s files is allowed only if he is in the proximity of the patient and the patient is in a critical state. Context information is represented by the location and the health status of the patient. It was integrated by two types of devices: GPS receivers and a health monitoring equipment. Context data was also obtained from a sensor network, integrated for environmental monitoring. Sensor networks are used frequently, due to their sensing, communicating and ease of deployment capacities.
The target for our framework is represented by devices usually found in a personal area network, (e.g. PDA). This imposes constraints on both processing power and memory capacity. Another solution is to integrate all the sensors with the same gateway used by the motes. It has both the advantage of the number of communication ports that it provides and the low power consumption compared to the PDA. Future work includes a study of security threats and the means to deal with them. The correctness level of the data measured by sensors was not taken into account. Currently decisions are made considering accurate data. We intend to use a mechanism for authorizations based on the correctness level of data. Another concern is the disclosure of the authentication information provided by the user, since the attributes sent as part of the digital certificate can be further used or disclosed by the authenticating device. DISCLAIMER IST-Directorate General / Integrating and strengthening the ERA: the project MOSQUITO is supported by the European Community. This document does not represent the opinion of the European Community. It is also the sole responsibility of the author and not the responsibility of the European Community using any data that might appear therein. REFERENCES [1] R. S. Sandhu, E. Coyne, H. Feinstein, and C. Youman, “Rolebased access control models,” IEEE Computer, pp. 38–47, 1996. [2] M. J. Covington, W. Long, S. Srinivasan, A. K. Dev, M. Ahamad, and G. D. Abowd, “Securing context-aware applications using environment roles,” in SACMAT ’01: Proceedings of the sixth ACM symposium on Access control models and technologies. ACM Press, 2001, pp. 10–20. [3] G. Zhang and M. Parashar, “Context-aware dynamic access control for pervasive applications,” in Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2004), 2004. [4] T. Moses, “extensible access control markup language (xacml) version 2.0,” OASIS Standard, Feb. 2005. [5] A. Anderson, “Core and hierarchical role based access control (rbac)profile of xacml v2.0,” OASIS Standard, Feb. 2005. [6] K. Wrona and L. Gomez, “Context information in ubiquitous computing security.” [7] M. Hazas, J. Scott, and J. Krumm, “Location-aware computing comes of age,” Computer, pp. 95–97, Feb. 2004. [8] G. Borriello, M. Chalmers, A. LaMarca, and P. Nixon, “Delivering real world ubiquitous location systems,” Commun. ACM, vol. 48, no. 3, pp. 36–41, 2005. [9] [Online]. Available: www.xbow.com
