security and privacy challenges in context-sensitive services · built client-based access-control...

Security and Privacy Challenges in Context-Sensitive Services

METIS Security Seminar, UOITNov 17, 2006

Urs Hengartner Cryptography, Security, and Privacy (CrySP) Research GroupDavid R. Cheriton School of Computer ScienceUniversity of Waterloo

Urs Hengartner 2Security and Privacy Challenges in Context-Sensitive Services

Context-Sensitive Services

Grant access to a resource based on a person’s context

Location, time, activity,…

Emerging location-based services are primary example

User of buddy service lets nearby friends know of her locationGrant access to networked projector if person in same room


Context-Sensitive Services can violate Privacy

CalendarService

Carol’scalendar?

10am: Meetingwith Bob

Carol: Grant access if I am in my office

Privacy violation?

Alice

Carol is in her office!


Context-Sensitive Services can violate Privacy

CalendarService

Carol’scalendar?

Carol: Grant access if Alice is in her office

Privacy violation?

Alice

LocationService

Where is Alice?

At home


Context-Sensitive Services must support Uncertainty

CalendarService

Carol’scalendar?


Should Alice have access?

Alice

LocationService

Where is Alice?

In her office with 30% uncertainty


Context-Sensitive Services must support Uncertainty

CalendarService

Carol’scalendar?


Should Alice have access?

Alice

CellphoneLocationService

In her office with 30%

uncertainty

BadgeLocationService

Where is Alice?Carol trusts

cellphone-based location more than badge-based

At home with 10%

uncertainty


Contributions

Systematic investigation of privacy violations caused by context-sensitive services

Set of algorithms to avoid these violationsAccess-rights graphsHidden constraints

Model for distributed, uncertainty-aware access control


OutlineMotivation

Privacy Violations System/Threat ModelTypes of Privacy ViolationsAccess-Rights GraphsHidden ConstraintsImplementation

Uncertainty

Future Work


Client-Based Access Control

Client stores access rightsAs digital certificates for integrity reasons

Client assembles proof of access upon requestService validates proof

Service

RequestAlice

Response


Client-Based Access Control with Constraints

Location Service

Calendar Service

Alice

Alice has access right to Carol’s calendar constrained to Carol’s locationAlice has unconstrained access to Carol’s location

Carol’s location == her office?

Carol’s calendar?

Yes


Threat Model

Services run access control

Goal of attacker: Learn information for which he/she has no access right

Actions of attackers:Issue requests and observe their fateIssue (constrained) access rightsCollude with service providing information and observe requests reaching service


OutlineMotivation


Uncertainty

Future Work


Definition of a Privacy Violation

Single entity (or multiple colluding entities) is familiar with constraint specification in an access right can observe outcome of a request exploiting this access right

Infers knowledge about current value of information in constraint specificationPrivacy violation if no access right to this knowledge


Investigation of Privacy Violations

Incremental approach

1. Access right to information in a constraint is not constrained

2. Access right to information in a constraint is also constrained

one level of recursionmultiple levels of recursion


Access Right to Information in a Constraint is Not Constrained

Alice has access right to Carol’s calendar constrained to Bob’s locationAlice has unconstrained access to Bob’s location

Can information about Bob’s location leak to Alice?

No

Calendar service?Yes; Alice must avoid itNot for location service

Carol (issuer)?Only if colluding with one of the above


Access Right to Information in a Constraint is Constrained

Alice has access right to Carol’s calendar constrained to Bob’s locationCalendar service has access right to Bob’s location constrained to his activity and unconstrained access right to his activity

Alice needs to avoid Bob’s information from leaking to calendar:

Can calendar access Bob’s

activity

Can calendar access Bob’s

location?

Activityconstrainsatisfied?

YesYes


Attack:Issuer of Alice’s access right and calendar colludeWhen receiving Alice’s request, infer that constraints in Alice’s access right must have been satisfiedAlice must ensure that issuer of access right has access to information in its constraints

Privacy Violation in case of Collusion

1. Alice retrieves Bob’s activity using one of her access rights

2. Alice validates constraint

3. Alice sends request to calendar

Activityconstraintsatisfied?

Yes


Further IssuesIf contents of access rights were public, calendar would not have to collude with issuer

Keep access rights confidential

How does Alice learn about access rights granted by Bob to calendar?

Keep constraints restrictedInvolve issuer or entity being granted access

What if access right to information in a constraint is also constrained and multiple levels of recursion?

Access-rights graphs


OutlineMotivation


Uncertainty

Future Work


Access-Rights GraphsAccess-rights graph for showing an entity’s access rights and constraints on themWhen can entity access information A.x?

A.x

B.y C.z

D.w

{s} {t}

{u}

*

{r, t}

Required constraint value(s)

Information in access right (e.g., Alice.location)

Constraint on access right


Access-Control Algorithm

Build access-rights graphEach node needs outgoing edge No conflict among node’s incoming edges

Start constraint resolution at nodes with no outgoing edges to other nodes

Work toward root node

For each node, verify that current value is in all incoming edges


Constraint-Resolution Example

A.x

B.y C.z

D.w

{s} {t}

{u}

*

{r, t}

4. B.x = s ? 6. C.z = t?

7. Get current value of A.x

1. Get current value of D.w

2. D.w = u ?

3. Get current value of B.y 5. Get current

value of C.z


Client-Based Access Control with Access-Rights Graphs

Alice builds access-rights graphs for requested information based on her access rights

During constraint resolution, Alice assembles proof of access for each node

Proof contains access right and confirmation showing satisfaction of its constraints

Information in constraint can leak to service receiving proof and issuer of access right

Alice ensures that they can access informationRequires additional access-rights graphs


OutlineMotivation


Uncertainty

Future Work


Hidden ConstraintsAlice can submit constrained access right to calendar service only if service has access to information used in a constraint

Requires additional access rightsElse Alice won’t be able to access Carol’s calendar

Observation: Privacy violation happens because calendar service sees constraint specification

Idea: Hide constraint specification from serviceAccess right includes only reference to specificationService cares only about satisfaction of a constraintAllows more flexible access control


ImplementationBuilt client-based access-control framework based on Web framework [Howell and Kotz, OSDI 2000]

SPKI/SDSI certificates for expressing access rights

Added support for constraintsAccess-rights graphsHidden constraints

Based on RSA public/private key pairs

Incorporated into Project AuraPervasive-computing project at Carnegie Mellon


Varia12%

Access decision by

location service

1%

SSL to location service

11%

Retrieve location

8%Issue

constraint satisfaction

4%

Retrieve calendar

43%

Access decision by

calendar service

1%

SSL to calendar service

20%

Carol grants Alice access to her calendar if Alice is in her officeUse hidden constraint

Overall response time: 463 ms

Pentium IV/2.5GHz, Linux 2.4.20, Java 1.4.2, 100 runs, 1024 bit RSA

Access Control responsible for 6% of Cost


Related Work

Ubicomp projects with context-sensitive services

E.g., Cerberus, CoBrA, Semantic Walletno discussion of privacy violations

[Minami and Kotz, PerCom 2005]limited scenario

More flexible access-control modelsUCONABC, GAA API, context-aware RBACNo discussion of privacy violations


Outline

Motivation

Privacy Violations

UncertaintyChallengesFormal Model

Future Work


Challenges

Closed vs. open environments

Time and uncertainty

Monotonicity

Sybil attacks


Closed vs. Open EnvironmentsClosed environments (e.g., company) require environment-wide settings

Which service(s) to use for locating/authenticating peopleAmount of uncertainty in terms of trusting a service

Open environments (e.g., home, mall, university) call for personalized settings

Access-control model should support both cases


Time and Uncertainty

CalendarService

Carol’scalendar?


Alice

LocationService

Where is Alice?

In office with 10% uncertainty

10am: Meetingwith Bob


Time and UncertaintyUncertainty changes over timeSynchronizing services is difficult

Not really necessary for location-based servicesIndividuals move at finite speed

Instead:Make statements short-livedPredict changes in uncertainty“At 8pm, Alice is in her office with 10% uncertainty. Uncertainty increases by 10% every minute. This statement expires at 8:10pm.”


MonotonicityIf a user is granted access based on a set of statements, she should not be denied access based on a superset of them

Important for client-based access controlAlso useful for centralized access control

Monotonicity and uncertaintyCombining statements can only decrease uncertaintyProvides incentive not to leave statements away


Sybil Attacks

Monotonicity ensures that combining statements decreases uncertainty

Attack: Service issues statements under fake identities till summary uncertainty is small enough for positive access-control decision

Only “approved” identities must be able to issue statements


Outline

Motivation

Privacy Violations

UncertaintyChallengesModel for Uncertainty-Aware Access Control

Future Work


Formal Model for Uncertainty-Aware Access-Control

Based on existing access-control model[Bauer et al., USENIX Security 2002]Supports open environmentsSimilar to Lampson et al.’s speaks-for model

New statements for context-sensitive access control with uncertainty

Digital certificates for approving identities

Subjective Logic for expressing uncertainty

Validated in Prolog


Subjective Logic [Josang, ESORICS 1998]

[belief, disbelief, ignorance] tuplesBelief + disbelief + ignorance = 1

Several operations on tuples, e.g.,RecommendationConsensusOrdering

Provides monotonicity

More robust to malicious nodes than simple probability


Related Work

Need for uncertainty has been recognized [Ganger, Ranganathan et al., Covington et al.]

Closed environments onlyNo formal treatment of time and uncertainty

Combination of location statements [Indulska et al.]

Not monotonic


Future Work

Deployment on a wider scale

What kind of access rights and constraints on them do people define?

How should uncertainty be determined?


Conclusions

Context-sensitive access control can lead to privacy violations and needs to deal with uncertainty

Ensure that entities observing request have access to information used in a context-sensitive constraint

Uncertainty changes over time; access-control model should provide monotonicity and resist Sybil attacks


Acknowledgments

Peter Steenkiste, Carnegie Mellon

Ge Zhong, University of Waterloo

security and privacy challenges in context-sensitive services · built client-based access-control...

Documents