Context sensitive access control

June 22, 2017 | Autor: Alfons Salden | Categoria: Information Management, Access Control, Service Provider, Context Information
Share Embed


Descrição do Produto

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

Lihat lebih banyak...

Comentários

Copyright © 2017 DADOSPDF Inc.