Access Control to Information in Pervasive Computing Environments Thesis Oral Urs Hengartner...

Access Control to Information in Pervasive Computing Environments

Thesis Oral

Urs Hengartner

Committee:Peter Steenkiste (Chair)Adrian PerrigMichael K. ReiterEdward W. Felten, Princeton

Urs Hengartner Access Control to Information inPervasive Computing Environments

2

Pervasive Computing requires Access Control to Information

Pervasive computing: Hundreds of computing devices for everyone Embedded, networked sensors

Gather and make available vast amounts of personal information (location, activity, health,…)

Privacy is a big concern in pervasive computing

Access control for pervasive computing information raises challenges


3

Pervasive Computing Scenario Carol schedules a meeting with Bob in her calendar

Carol grants Alice access to her calendar provided that Carol is not busy Carol is in her office

Carol is meeting

with Bob in

WeH 8220

Carol

Alice


4

Challenge #1 – Diversity in Service Administration

Calendar

PeopleLocator

Camera

ActivityService

AccessPoint

Laptop

GPS CellPhone

PeopleLocator

BodySensor

ActivityService

AccessPoint

PeopleLocator

Carol’s companyCarol

Nextel


5

Traditional Solutions assume Trusted Environment for Services AFS file servers trust each other Database hosts trust each other

Access control needs to be able to deal with services run by different entities, while making it easy for individuals to manage access to their personal information provided by these services


6

Related Work and Diversity in Service Administration Pervasive computing projects with access

control: CoBra, Cerberus, Semantic Wallet,…

Typical approaches: Centralized entity controlling access on

behalf of individual services Individual maintains services providing her

information


7

Challenge #2 – Complex Information

CalendarService

Carol’s calendar entry?

Carol is meeting withBob in WeH 8220

Carol’s location

Carol’s activity

Information leak?

Bob’s location

Bob’s activity

AliceCarol


8

Traditional Solutions for Complex Information do not work here Keep complex information secret

Pervasive computing needs access in order to serve people

Carefully establish access rights Tedious Consistency problems

Access control itself needs to be aware of the contents of complex information and treat this content as a first-class citizen when making an access decision


9

Related Work and Complex Information Other pervasive computing projects have

noticed problem CoBra

Not addressed in deployed architecture


10

Challenge #3 –Confidential Context-Sensitive Constraints

CalendarService

Carol’scalendar?

Meetingwith…

Access if Carol’s location == office

Information leak?

Alice

Carol is in her office!


11

Traditional Solutions Simple constraints

Group/role membership in filesystems/databases

Some context-sensitive constraints Time

Limited availability of confidential context-sensitive information (currently)

Access control needs to support context-sensitive constraints, but without leaking confidential information listed in a constraint


12

Related Work and Context-Sensitive Constraints Many pervasive computing projects support

context-sensitive constraints Location-based services

No systematic study of information leaks caused by confidential context-sensitive constraints


13

Thesis Goal

Is it possible to run access control to information in pervasive computing, where this information can be complex and where access decisions might be constrained based on confidential information, without relying on a centralized entity?


14

Key Components Client-based access-control architecture

Access rights expressed as digital certificates Client submits proof of access to service Extended to deal with challenges Naïve application results in information leaks

Flexible information representation scheme Service- and environment-independent access rights

Semantics of information Captured in formal model to deal with complex

information


15

Research Contributions Distributed access-control architecture for

pervasive computing [HotOS 2003]

Information relationships [PerCom 2005]

Derivation-constrained access control

Confidential context-sensitive constraints

Obscured proof-of-access descriptions [SecureComm 2005]

Alternative: Encryption-based access-control architecture [SecureComm 2005]


16

Outline Thesis Goal

Confidential Context-Sensitive Constraints Approach Related Work Access-Rights Graphs Hidden Constraints Performance Evaluation

Obscured Proof-of-Access Descriptions

Future Work


17

Approach Systematic study of how context-sensitive

constraints can cause information leaks in different access-control approaches Centralized Service-based Client-based Hybrid

Access-rights graphs for constraint resolution

Hidden constraints to avoid information leaks


18

Comparison with Related Work Ubicomp projects with context-sensitive constraints

Cerberus, CoBrA, Semantic Wallet Centralized, no discussion of information leaks

[Minami and Kotz, PerCom 2005] Service-based, limited scenario

Context awareness for RBAC E.g., Environment Roles No discussion of information leaks

New access-control models supporting constraints UCONABC, GAA API No discussion of information leaks


19

Client-Based Access Control with Confidential Constraints

Location Service

Calendar Service

Alice

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

Alice has unconstrained access to Carol’s location information

Carol’s location == her office?

Carol’s calendar?

Yes


20

Threat Model Single attacker or multiple collaborating

attackers learn value of information used in a constraint, where the single attacker or all of the collaborating attackers do not have an access right to this information

Actions of attackers: Issue requests and observe their fate Issue (constrained) access rights Run services providing information


21

Can Information in Constraint leak to (Colluding) Entities?

Alice must ensure that calendar service has access to information in constraint

Collusion not an issue here (but will be later)

Alice can access Carol’s calendar if Carol is in her office

Client-based access control

Entity Alice Alice/*

Calendar Service

Calendar Service/*

Carol Carol/*

Leak No No Yes Yes No Yes


22

Public Access Rights can cause Subtle Information Leaks Alice needs to ensure that calendar service has

access to Carol’s location information Alice resolves constraints in service’s access right

to Carol’s location information Alice retrieves information in these constraints

using her own access rights Upon receiving proof from Alice, calendar service

learns that constraints in Alice’s access rights must have been satisfied

Information leak if service knows access rights

Keep access rights confidential


23

Access Rights to Information in Constraint can be Constrained Access-rights graph for showing a principal’s access

rights and constraints on them When can principal 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 (owner.type)

Constraint on access right


24

Access-Control Algorithm Build access-rights graph

Each 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


25

Constraint Resolution Example

A.x

B.y C.z

D.w

{s} {t}

{u}

*

{r, t}

1. Get current value of D.w

2. D.w = u ?

3. Get current value of B.y

4. B.x = s ?

5. Get current value of C.z

6. C.z = t?

7. Get current value of A.x


26

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 Alice ensures that service can access information Requires additional access-rights graphs


27

Hidden Constraints Principal knowing constraint specification could

infer current value of information in constraint

Idea: Hide specification from principal

From client Client still needs to be able to resolve constraint

From service Service cares only about satisfaction of a constraint

Additional benefit: supports constraints with information to which service does not have access Need to ensure that issuer has access (Collusion)


28

Implementation Built client-based access-control framework based

on Web framework [Howell and Kotz, OSDI 2000] SPKI/SDSI certificates for expressing access rights

Added support for constraints

Incorporated into Project Aura

Constraints can be hidden from service Constraint specification is separate from access right Access right includes only reference

Public key (signature for guaranteeing satisfaction) End of one-way chain (chain value)


29

Varia12%

Access decision by

location service

1%

SSL to location service

11%

Retrieve location

8%

Issue constraint

satisfaction4%

Retrieve calendar

43%

Access decision by

calendar service

1%

SSL to calendar service

20%

Constraint Resolution Responsible for 25% of Cost Carol grants Bob access to her calendar if Bob is in

his office Use hidden, signature-based constraint

Overall response time: 463 ms

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



30

Other Issues (see Thesis) Centralized and service-based access control

Formal model

Access-rights graphs with loops

Enforceability

Certificate discovery

Forwarded access rights

Multiple services offering information in constraint


31

Summary of Confidential Context-Sensitive Constraints Access rights with confidential context-sensitive

constraints can leak information in constraint

Ensure that principals observing request have access to this information

Access-rights graphs to detect conflicting constraints and to simplify constraint resolution

Hidden constraints can avert information leaks


32

Outline Thesis Goal

Confidential Context-Sensitive Constraints

Obscured Proof-of-Access Descriptions Approach Related Work Requirements Solution based on Identity-Based Encryption Performance Evaluation

Future Work


33

Information leak due toProof Description

CalendarService


Prove that you can access• Carol’s location and activity• Bob’s location and activity

Carol is meeting with Bob!

Carol is meeting

with Bob in

WeH 8220

Information leak?

Alice


34

Approach Service obscures description of required proof of

access such that Alice understands it only if she has access to information listed in description Based on cryptography Service generates ciphertext Alice needs to find matching decryption key

Hierarchical cryptographic scheme to support Constraints (e.g., time-based) on access right Granularity-aware access rights


35

Comparison with Related Work Automated trust negotiation

E.g., [Yu and Winslett, S&P 2003] Deadlocks possible

Hidden Credentials [Holt et al., WPES 2003] No constraints and granularity awareness

Secret Handshakes [Balfanz et al., S&P 2003], Brands’ self-blinding certificates, Chaum’s pseudonyms, Oblivious Signature-Based Envelopes [Li et al., PODC 2003] Both parties agree on centralized authority No constraints and granularity awareness


36

Requirements Asymmetry

Service can generate obscured proof description, but not interpret obscured descriptions generated by other services

Personalization Leaking of secret knowledge by a client does not

affect other clients

Granularity–aware and constrained access rights


37

Exploit Hierarchical Identity-based Encryption (HIBE) Asymmetric encryption scheme

Simple key management makes personalization easy

Use hierarchies to support granularity awareness and constraints

My contributions: New application of HIBE Extend HIBE to support multiple hierarchies First implementation of HIBE


38

Alice

Asymmetry – Exploit asymmetric encryption scheme

CalendarService


Bob’s Access Right

Bob

Carol is meeting

with Bob in WeH

8220

Prove that you can access• Carol’s location •

[Bob’s location, ]

Carol’s Access Right



39

Personalization – Exploit Identity-Based Encryption Proposed >20 years ago [Shamir, Crypto 1984]

Practical approaches have appeared only recently (e.g., [Boneh and Franklin, Crypto 2001])

Public key of an individual is her ID (e.g., email) No need to acquire separate public key based on

“traditional” asymmetric cryptosystem (e.g., RSA) Simplifies key management and personalization

Individual receives private key from Private Key Generator (PKG)


40

Distribute private key generation in hierarchy

Root PKG issues private keys to sub PKGs

Sub PKGs issues private keys to individuals in their domains

Granularities – Exploit Hierarchical

Identity-Based Encryption

EDU

CMUPrinceton

Dave Ed Fred

Dave’s public key:“EDU, Princeton, Dave”

Dave’s private key: numerical value associated with his node


41

Setup – Bob gives public keys (i.e., hierarchies) to service Bob defines set of hierarchies resembling

granularity properties of his information and constraints on access rights to his information

Public key = one path per hierarchy

location_fine

medium

location_2005

1

January

coarse

February

…

…

location_always

officehours

spare time

Alice_ Alice_ Alice_

PersonalizationSample public keySample public keyCorresponding private key


42

Setup – Bob gives private key (and access right) to Alice

Bob grants access right to Alice for his location of medium granularity, in January, during office hours

Bob becomes his own PKG, picks matching node in each hierarchy, and computes private key

Alice_location_fine

medium

Alice_location_2005

1

January

coarse

February

…

…

Alice_location_always

officehours

spare time


43

Obscured Proof Description - Service creates ciphertext Service chooses relevant path in each hierarchy Uses this public key to encrypt random string Gives random string and ciphertext to Alice

Alice_location_fine

medium

Alice_location_2005

1

January

coarse

February

…

…


officehours

spare time


44

Obscured Proof Description – Alice tries to decrypt ciphertext

For each private key received from Bob and others: Alice derives current private key (if possible) Decrypts received ciphertext and looks for match

Alice_location_fine

medium

Alice_location_2005

1

January

coarse

February

…

…


officehours

spare time


45

Implementation Implemented HIBE scheme, extended for multiple

hierarchies, in Java [Gentry and Silverberg, Asiacrypt 2002]

Exploits Bilinear Diffie-Hellman problem CCA2 security in the ROM model

Incorporated scheme into Project Aura If no proof, service returns error message with

ciphertext/random string pair

Built calendar service that generates obscured proof descriptions


46

0

20

40

60

80

100

1 2 3

Number of hierarchies

Encr

yptio

n tim

e [m

s]Encryption/Decryption Cost depends on Number of Hierarchies First hierarchy: three levels Other hierarchies: two levels Preliminary results: Decryption is expensive

0

200

400

600

800

1000

1 2 3Number of hierarchies

Decr

yptio

n tim

e [m

s]

(Pentium IV/2.5GHz, Linux 2.4.20, Java 1.4.2, 100 runs)


47

Summary of Obscured Proof Descriptions Service obscures description of required

proof of access in order to avoid information leaks

Hierarchical Identity-Based Encryption for easy key management, constraints, and granularity awareness

Decryption performance is currently slow, but there is potential for improvements


48

Future Work Remote credential retrieval in distributed systems

Credentials can be confidential

Semantic model E.g., based on PCA [Bauer et al., USENIX Security

2002]

Access control and uncertainty Context-sensitive information (e.g., location) can be

uncertain Effect on context-sensitive access control


49

Conclusions Pervasive computing makes distributed access

control to confidential information challenging

Main contributions: Incorporate semantics of information as a first-class

citizen into distributed access control Obscured proof-of-access descriptions Information relationships Derivation of information

Access control with confidential constraints Access-rights graphs and hidden constraints

Thank you!


51

Credits

Peter Steenkiste (Advisor) Nick Hopper Dawn Song

Backup Slides


53

Privacy in Pervasive Computing Pervasive computing gathers and makes available

vast amounts of personal information So privacy is a major concern? Survey of researchers in pervasive computing

[Lahlou et al., CACM 48(3)]:Privacy was either an abstract problem; not a problem yet (they are “only prototypes”); not a problem at all (firewalls and cryptography would take care of it); not their problem (but one for politicians, lawmakers, or, more vaguely, society); or simply not part of the project deliverables.


54

Challenges for Access Control in Pervasive Computing

Pervasive Computing

Traditional Computing

Services Diverse Homogenous

Environments Smoothtransitions

Noticeabletransitions

Complex Information Must be available

Keep it secret

Derivation of Information Limit intruders No limits

Constraints Context-sensitive

Static


55

Challenge #3 - Derivation of Information Services derive specific information from raw information

Attractive targets for attackers

Where is Bob?

LocationService

VideoStream

AliceBob


56

Traditional Solutions Information processing takes place within trusted

environment

Intruder into environment can access any information

No sense to secure just processing

A service's access to information should be limited such that the service can perform derivation, but without giving intruder complete access to information


57

Related Work and Information Derivation Other pervasive computing projects

assume that derivation takes place within trusted environment

Same argument as in traditional solutions


58

Research Contributions – Access Control Architecture Exploits relationships between information. Obscures requirements placed on access to

information. Exploits derivation properties of information.

Limits influence of intruder. Supports context-sensitive access control.

Performs graph-based constraint resolution. Hides confidential constraints from services.

Aside: encryption-based access control. Alternative to authentication-based architecture.


59

Centralized Access Control

Used by several pervasive computing research projects. Advantages:

Flexible access rights. Disadvantages:

Single point of failure. Multiple environments?

Service

Service

Where is Bob? Where is

Bob?


60

Diverse Services call for Distributed Access Control

Multiple services offer same information Different organizations control services

ServiceWhereis Bob?

Service

Service

Alice

Bob


61

Constraints and Information Leaks Access control: Should Alice have access to

requested information?

Without constraints: Grant access if Alice has access right to information

With constraints: Same approach can leak information If request is granted access, constraints must be

fulfilled Similar for denied requests


62

Access Control with Constraints Make sure that Alice has access to

information listed as constraint in her access right before making access decision Grant access: Alice has access to information

in constraint Deny access: Deny access early if Alice

cannot access information in constraint

Assumption: Alice’s access right to information in constraint is not constrained


63

Information Relationships as a Solution to Challenges Diverse services and multiple environments

call for distributed access control architecture.

Complex information calls for access control architecture aware of semantics of information.

Information relationships support both concepts. Formalize certain aspects of semantics. Part of distributed access control architecture.


64

Outline Proof-based Access Control

Information Relationships Approach Related Work Types of Relationships Formal Model Performance Evaluation

Obscured Proof Descriptions Other Challenges Future Work


65

Approach – Exploit Information Relationships Information relationships to capture semantics of

complex information Carol’s calendar is related to her location and activity

Access to information is granted only if there is access right to related information Grant access to Carol’s calendar only if access rights

exist to her location and activity

Identify three key information relationships Important for pervasive computing Supportable by distributed access control


66

Comparison with Related Work Pervasive computing projects with access control

(e.g., Cerberus, CoBrA, Semantic Wallet) Access control based on centralized rule engine Do not exploit semantics of information for access

control

Possible to add rules for semantics Single point of failure Bottleneck

My approach: Fully distributed


67

Type #1 – Bundling-based Relationships Bundle different types of information with identical

access control requirements Define single access right to bundle Reduces danger of information leaks

Location Activity

Alice and Carol can access my

location

Alice and Carol can access my

activity

Personal

Alice and Carol can access my personal

information

Bob


68

Type #2 – Combination-based Relationships Information can be accessed only if a set of

other information can be accessed Avoids information leaks

Calendar

Location Activity Access to my

calendar only if access to my location

and activity

Bob


69

Type #3 –Granularity-based Relationships Information can have different levels of

granularity E.g., location information

“Waterloo Campus” vs. “MC5158”

Access to fine-grained information implies access to coarse-grained information Anyone who can access Bob’s fine-grained

location also has access to his coarse-grained location


70

Sufficient Set of Relationships? For each relationship, there is a major,

corresponding concept in role-based access control.

Based on our deployment experience, yes.

Relationships RBAC

Bundling-based Role assignment

Combination-based Separation of Duty

Granularity-based Hierarchical roles


71

Formal Model for Access Control with Information Relationships Who should be able to establish relationships? How do they interact with other features? Formal model based on speaks-for notation:

A can speak for B on behalf of a set of statements T, or

My contributions: Information representation scheme Information relationships

[Lampson et al., Howell and Kotz]


72

Information Representation Scheme Information has owner:

Issues access rights to information Establishes relationships for information

Idea: Incorporate owner of information into representation

Example: Bob.location_of_Bob (short: Bob.loc) Bob: owner of information location_of_Bob: type of information


73

Information Representation

Principal controlling information

Entity information is about

Type of information

Examples: (Bob, Bob).location (Administrator, Room 509).temperature

Shortcut:


74

Formal Model for Access Control Bob grants Alice access to his location

Alice grants Carol access to Bob’s location

Access control

(Transitivity Axiom)


75

Bob’s location is bundled in his family’s location

Derive individual access rights from bundle

Integration of Bundling-based Relationships

(Bundling Axiom)


76

Establishment of Access Rights Owner B of information B.z can establish

access rights for this information, or

Speaks-for is transitive, or


77

Incorporating Relationships Information relationship:

Validation of access rights with relationships:

for certain conditions on

E1.x1 Location

E2.x2 Activity

D.x Calendar


78

What about ? Cannot resolve

Conditions for Bundling-based Relationships – First Attempt

D.x D’s information

E.y Project-relatedinformation


79

What about ? Example:

Conditions for Bundling-based Relationships – Second Attempt

D.x D’s information

E.y Project-relatedinformation


80

Combination-based Relationships You can access this map if you can access

Alice’s and Bob’s location. Validation (including conditions):

D.x map

E1.x1 Alice’s location

E2.x2 Bob’s location


81

Establishment of Information Relationships Only owner D of information D.x can

establish information relationships for it:


82

Establishment of Bundling-based Relationships Only owner D of information D.x can

establish relationships for it:

D.x location information

E.y personalinformation


83

Carol wants to access Bob.loc

Assumption: Carol has pool of certificates expressing access rights or relationships

SPKI certificates [RFC 2693]

Carol builds proof out of these certificates using Transitivity Axiom and Bundling Axiom

Service validates received proof Signatures of certificates Correct application of axioms

Exploit Formal Model forProof-based Access Control


84

Carol builds Proof of Access

entitiesCarolBob

Bob.loc

Alice


85

Proof Building with Information Relationships

informationrelationships

entitiesCarolBob

Bob.loc

Alice

Family.loc


86

# speaks-for statements: n# information relationships: m

Complexity: Only O(n) without information relationships

However, n is smaller, m tends to be small.

Alice makes her location information part of her private information, but not of Bob’s.

Complexity of Proof-Building Algorithm


87

0

5

10

15

20

0 200 400 600 800Number of access rights (n)

Bui

ldin

g ti

me

[ms]

Bundling-based Relationships can increase Cost of Proof Building Locate 4 access rights in pool of n access rights Establish up to five levels of relationships.

(Pentium IV/2.5GHz, Linux 2.4.20, Java 1.4.2, 100 runs)

One level of relationships

Linear increase Five levels of relationships

Three levels of relationships

No relationships


88

Number of issued Access Rights and Information Relationships

0

100

200

300

400

500

600

700

800

900

1000

1 2 3 4

Number of levels

Num

ber

of is

sued

sta

tem

ents With relationships

W/o relationships -root onlyW/o relationships -leaves onlyW/o relationships -mixed


89

Request Processing and Proof Validation Query for location information.

Service fingers someone’s desktop computer. Proof of access contains single certificate

expressing access right, no relationships. 1024 bit RSA keys.

SSL socket creation 53 ms (6 ms)

Proof validation 3 ms (2 ms)

Gather location information 56 ms (7 ms)

Total 129 ms (13 ms)


90

Influence of Relationships on Client Response Time Access proof includes increasing number of

sequentially connected, bundling-based information relationships.

0

50

100

150

200

1 2 3 4 5 6

Number of relationships

Resp

onse

tim

e [

ms]


91

Project Aura Pervasive computing project at Carnegie Mellon Location service with access control:

Gathering location information: 50-200ms Proof building: <20ms

Deployment shows that Cost of Proof Building is competitive


92

Digital certificates Distributable Modified SPKI certificates Example:

(cert (issuer (public_key:bob))(subject (public_key:alice)) (permission (information

(public_key:bob) location))

(tag (*)))

Implementation of Access Rights/Relationships


93

Summary of Information Relationships Information relationships lead to consistent access

rights and reduce risk of information leaks

Incorporation of commonly used relationships into distributed access control architecture to avoid single point of failure

Deployment shows competitive performance

[Hengartner & Steenkiste, PerCom 2005]


94

Traditional Proof-based Access Control fails here Assumption:

Alice knows about required proof of access, or service can inform Alice of required proof

Assumption breaks down if proof description contains confidential information

My approach:Use cryptography for obscuring proof descriptions


95

Alice

Obscured Proof Descriptions – Strawman

CalendarService



942942[Bob’s location, ]

Bob

Carol is meeting

with Bob in

DC1234

Prove that you can access• Carol’s location • 942

Carol’s Access Right



96

Reduction in Search Space Alice (probably) knows type of information

to which she requires an access right. Calendar information consists of location

information, but not of medical information. Or service can tell her. At most one relevant private key per person

that gave her private key(s).


97

Revisit Requirements Asymmetry

Private key required for understanding challenge. Services have only public key.

Personalization Personalized information and constraint hierarchies.

Granularity awareness Information hierarchy.

Support for constraints Constraint hierarchies.


98

Analysis of Encryption/Decryption Cost # hierarchies: m # levels in hierarchy i: ni Encryption:

Decryption:

Predicted performance of optimized, C-based implementation (MIRACL) Encryption:

Decryption:

m

iin

1

)1(*ms 14ms 25

m

iin

1

*ms 136

m

iin

1

)1(*ms 2ms 8

m

iin

1

*ms 29


99

Why Identity-based Encryption? There are hierarchical variants of

“traditional” asymmetric encryption schemes (e.g., RSA, ElGamal).

Make key management difficult. Require hierarchies of numerical public keys

in addition to hierarchies of information or constraints.

Even if latter hierarchies are shared.


100

Related Work – Specification Languages “P3P++”, REI, XACML

Mainly for environments where access control is administrated by a single entity.

No builtin support for authentication of statements. KeyNote, PolicyMaker, SD3, RTLM

Trust management systems. Similar to SPKI, possible to incorporate information

relationships. SPKI is standardized and there are multiple

implementations.


101

Comparison with Related Work – Automated Trust Negotiation E.g.,[Yu and Winslett, S&P 2003] Client transmits all its access rights

Bandwidth and privacy issues Service iteratively reveals access policy and client

transmits required access rights Deadlock possible

My approach Transmits only required access rights Finishes in two rounds Considers constrained and granularity-aware access rights


102

Related Work – Access Control in a Hierarchy [Akl and Taylor], [Harn and Yin], [Tzeng],

[Sandhu], [Zheng] Symmetric schemes. Arbitrary hierarchies.

[Ray et al.] Asymmetric scheme based on RSA.

[Briscoe] Hierarchy for time-based access.

Access Control to Information in Pervasive Computing Environments Thesis Oral Urs Hengartner...

Documents

Transcript of Access Control to Information in Pervasive Computing Environments Thesis Oral Urs Hengartner...