Context Sensitive Access Control
Bob Hulsebosch
Alfons Salden, Mortaza Bargh, Peter Ebben, Jaap Reitsma
SAFE-NL, 18 November, 2005, TNO, Delft
Meet Context my aware colleagues: security?!
Context information is important for security!
Agenda •
Context Sensitive Security – Why, when and what?
•
Key elements - implications
•
Comparison
•
Implemented scenario
•
Conclusions
Why Context Sensitive Security? •
Current security static and intrusive – Something you have (username), you know (password) and you are (fingerprint) – Numerous username / passwords – Identity often not relevant
•
Increasing use of context information – Location (GPS, GSM cell-based, Bluetooth, ….) – Presence (Buddy lists) – Device capabilities (battery power, memory, operating system) – Network type (WLAN, GPRS, UMTS) – Level of authentication
•
Use of context to enhance / replace existing security – Make it more flexible and less intrusive
When Context Aware Security? •
Allow for fine grained access control – E.g. combine identity authentication with context parameters as location, temperature, level of authentication, …. – In case of a medical emergency based upon heartbeat or other physical parameters
•
When true identity is not relevant and PKI is expensive – E.g. for large groups of (anonymous) users • In public places such as shopping malls, museums, sport arenas, public transport, etc.
•
When security overhead is unwanted – E.g. for police, medical, fire brigade personnel
What are the implications? •
Context aware infrastructure is required
•
Context is public information – How to verify if used for security purposes? – Identifier authentication instead of identity authentication
•
Context interpretation
•
Privacy – How to stay anonymous while giving context info?
Context Aware Infrastructure
Context Owner
Context Aware Service Provider
Context Provider
Context Broker
Context Verification Several options: •
Checking the source – is it trusted?
•
Using cryptography – context based digital signatures
•
Using round trip times – only works for location info
•
Based on proximity – only works for location info
•
Using history information – behavioural patterns
•
By comparison to a (trusted) reference – collaborative context
•
Last option most natural – mimics physical world
Context Interpretation - Inference •
If user X is at location Y and moves with velocity V – Is X a train traveller? – Is X a car driver? – Is X a war driver? – Is X an employee? – Compare with trusted unique reference point
•
What is the quality of the context? – Accuracy • GPS location or GSM cell location – Up-to-datedness of the context info • Real time or 60 seconds old – Depends on application and access control policy
Privacy •
Issue: – Anonymous user goes to Service Provider – Service Provider requires context information – How to get it based upon anonymous user ID?
•
Decouple context from identity
•
Use Context Provider to control access
•
Use Context Broker to link and map identities to context
•
Use tickets to allow for this mapping
Comparison with other solutions Subject Identity SID
Token T
AuthN
Mapping
Access Policy P
Basic
Username
Password
Is SID a valid username, given T?
-
(SID , P)
RBAC
Username
Password
Is SID a valid user, given T
SID → RoleID
(RoleID , P)
CSAC
User pseudonym
Context info
Is T a valid context, given the available context info?
SID → Context
(cxt, P)
Mobile & Wireless project •
IEEE 802.11 WLAN / MESH / Hotspot network on train track Hengelo-Enschede
•
Train travellers are offered services (information, entertainment, e-mail, etc.) via WLAN
•
Some of these services have restricted access
•
Authentication of train travellers impossible via PKI or username/password
Goals •
Only allow travellers access to services while in the train
•
Preserve the privacy of the traveller – anonymous access
•
Keep the user in control as to who has access to his context information
•
Use GPS location information and other context info for access control
Hengelo
Velocity (km/hour)
150 120 90 60 30 0 0
90
180
270 Hengelo
Enschede
Time (seconds)
GPS GPS
Railway Railway Enschede
Issues •
•
•
Location alone is not enough to uniquely identify a user as a train traveller – Use Velocity to make sure it is a traveller – Compare to Velocity of train or train guard to verify the location/velocity claim of the traveller – How to link them efficiently? What if there is no trusted reference point – Collaborative context is more reliable: use context of other travellers in that train What if there are special circumstances like the train standing still? – Impossible to distinguish traveller from non-travellers – Policy of the service should specify this
Implemented Scenario •
Traveller with PDA and GPS-receiver
•
Train Guard with PDA and GPS-receiver as trusted reference point
•
Implemented context aware access policies: – Location(train) = Location(traveller) – Velocity(train) = Velocity(traveller) – Simplified verification process by using unique train identifiers
•
Train guard provides almost real-time context information
•
Traveller is polled every few minutes
Hengelo
L(Traveller) = L(Rail) V(Traveller) = V(Train)
Enschede
3052 3053 ProRail Site 4249
3052 3053 4249
Hengelo
ProRail Site Service A Service B Service C
Enschede
Hengelo
ProRail Site Service A Service B Service C
Enschede
Hengelo
ProRail Site Service A Service B Service C
Enschede
3053
ProRail Site Service A Service B Service C
3053
Hengelo
ProRail Site Service A Service B Service C
L(Alice) = L(Rail) V(Alice) = V(Train)
Enschede
Hengelo
ProRail Site Service A Service B Service C
L(Alice) = L(Rail) V(Alice) ‡ V(Train)
Enschede
Hengelo
ProRail Site Service A Service B Service C
L(Alice) ‡ L(Rail) V(Alice) ‡ V(Train)
Enschede
Collaboration Between Parties CO Laptop
Context Ticket
Browser
CASP Portal Service
Access
GPS
Context Provider Client
Owner ID & Location & Velocity
Context Provider
Access Controller Co nt e & xt G Co ra Context nt nti ex ng Ticket tT ick Tick et et
Owner ID & Provider ID & Location & Velocity
Access Policy
Context Ticket & Location & Velocity
Context Broker
Uluru Platform
Conclusions •
Context information can be used for security purposes in a transparent, non-invasive and natural way
•
Multiple levels of access control
•
Preserves privacy
•
Doesn’t require PKI or username/password schemes
•
Requires context aware infrastructure
•
Verification of context important
•
Introduces expensive messaging overhead for the service provider
•
Relatively low level of security
•
Can be upgraded by using other context sources like travel schemes of trains and context history management
•
Quality of context information essential
Questions?
Bob Hulsebosch Telematica Instituut Enschede, the Netherlands
[email protected]
Context Owner
CASP
Context Broker
I want to use this service I don’t have a location ticket
Go fetch a location ticket
Context Provider At some point in time the Context Provider registers itself at the Context Broker
I need a location ticket I don’t have a location granting ticket yet Select a location context provider from this list This is my location context provider Ok, go and register yourself at the location context provider Hi, please register me, you are my location context provider When done redirect user to the Context Broker
This is my location context provider identifier; can I have a location ticket now?
Register new ticket
Ok, here is your location granting ticket and your new location ticket; now go to the application I want to use this service Here is my location ticket Your location is OK, come in and use my service
What location is bound to this ticket? This is the location
Get the location This is the location