Access Control to Information in Pervasive Computing Environments Thesis Oral Urs Hengartner Committee: Peter Steenkiste (Chair) Adrian Perrig Michael K. Reiter Edward W. Felten, Princeton

1
Access Control to Information in Pervasive
Computing EnvironmentsThesis Oral Urs
HengartnerCommittee Peter Steenkiste
(Chair) Adrian Perrig Michael K. Reiter Edward
W. Felten, Princeton
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
Carol is meeting with Bob in WeH 8220
4
Challenge 1 Diversity in Service Administration
Nextel
People Locator
GPS Cell Phone
Calendar
Activity Service
People Locator
Activity Service
Body Sensor
People Locator
Camera
Access Point
Access Point
Carols company
Laptop
Carol
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
Carol
Calendar Service
Carols activity
Carols location
Information leak?
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
Calendar Service
Carolscalendar?
Carol is in her office!
Information leak?
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

• Alice has access right to Carols calendar
  constrained to Carols location
• Alice has unconstrained access to Carols
  location information

Location Service
Calendar Service
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 can access Carols 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

• Alice must ensure that calendar service has
  access to information in constraint
• Collusion not an issue here (but will be later)

22
Public Access Rights can cause Subtle Information
Leaks

• Alice needs to ensure that calendar service has
  access to Carols location information
• Alice resolves constraints in services access
  right to Carols location information
• Alice retrieves information in these constraints
  using her own access rights
• Upon receiving proof from Alice, calendar service
  learns that constraints in Alices 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 principals
  access rights and constraints on them
• When can principal access information A.x?

Constraint on access right
Information in access right (owner.type)
A.x
t
s
Required constraint value(s)
B.y
C.z
u
r, t
D.w

24
Access-Control Algorithm

• Build access-rights graph
• Each node needs outgoing edge
• No conflict among nodes 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
7. Get current value of A.x
4. B.x s ?
A.x
6. C.z t?
s
t
3. Get current value of B.y
5. Get current value of C.z
B.y
C.z
u
2. D.w u ?
r, t
D.w
1. Get current value of D.w

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
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

(Pentium IV/2.5GHz, Linux 2.4.20, Java 1.4.2, 100
runs, 1024 bit RSA)
Overall response time 463 ms
Urs Hengartner
Access Control to Information in Pervasive
Computing Environments
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
Calendar Service
Carol is meeting with Bob in WeH 8220

• Carol is meeting with Bob!

Information leak?
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, SP 2003
• Deadlocks possible
• Hidden Credentials Holt et al., WPES 2003
• No constraints and granularity awareness
• Secret Handshakes Balfanz et al., SP 2003,
  Brands self-blinding certificates, Chaums
  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
• Granularityaware 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
Asymmetry Exploit asymmetric encryption scheme
Calendar Service
39
Personalization Exploit Identity-Based
Encryption

• Proposed gt20 years ago Shamir, Crypto
  1984Practical 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
Granularities Exploit Hierarchical
Identity-Based Encryption

• Distribute private key generation in hierarchy
• Root PKG issues private keys to sub PKGs
• Sub PKGs issues private keys to individuals in
  their domains

EDU
CMU
Princeton
Fred
Dave
Ed
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
location_2005
location_always
spare time
office hours
medium
January
February


1
coarse
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
Alice_location_2005
Alice_location_always
spare time
office hours
medium
January
February


1
coarse
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
Alice_location_2005
Alice_location_always
spare time
office hours
medium
January
February


1
coarse
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
Alice_location_2005
Alice_location_always
spare time
office hours
medium
January
February


1
coarse
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
Encryption/Decryption Cost depends on Number of
Hierarchies
(Pentium IV/2.5GHz, Linux 2.4.20, Java 1.4.2, 100
runs)

• First hierarchy three levels
• Other hierarchies two levels
• Preliminary results Decryption is expensive

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

50
Thank you!
51
Credits

• Peter Steenkiste (Advisor)
• Nick Hopper
• Dawn Song

52
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 Smooth transitions Noticeable transitions
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

Bob
Video Stream
Location Service
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
Service
Service

• Used by several pervasive computing research
  projects.
• Advantages
• Flexible access rights.
• Disadvantages
• Single point of failure.
• Multiple environments?

60
Diverse Services call for Distributed Access
Control

• Multiple services offer same information
• Different organizations control services

Service
Service
Service
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 Alices 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
• Carols 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 Carols 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

Bob
Alice and Carol can access my location
Alice and Carol can access my activity
Location
Activity
68
Type 2 Combination-based Relationships

• Information can be accessed only if a set of
  other information can be accessed
• Avoids information leaks

Bob
Calendar
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 Bobs 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

Type of information
Entity information is about

• 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 Bobs location
• Access control

(Transitivity Axiom)
75
Integration of Bundling-based Relationships

• Bobs location is bundled in his familys
  location
• Derive individual access rights from bundle

(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
E1.x1 Location
E2.x2 Activity
D.x Calendar

• Information relationship
• Validation of access rights with relationships
• for certain conditions on

78
Conditions for Bundling-based Relationships
First Attempt

• What about ?
• Cannot resolve

D.x Ds information
E.y Project-related information
79
Conditions for Bundling-based Relationships
Second Attempt
D.x Ds information
E.y Project-related information

• What about ?
• Example

80
Combination-based Relationships

• You can access this map if you can access Alices
  and Bobs location.
• Validation (including conditions)

D.x map
E1.x1 Alices location
E2.x2 Bobs 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 personal information
83
Exploit Formal Model forProof-based Access
Control

• 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

84
Carol builds Proof of Access
Bob.loc
entities
Carol
Bob
85
Proof Building with Information Relationships
information relationships
Bob.loc
entities
Bob
Carol
86
Complexity of Proof-Building Algorithm

• 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 Bobs.

87
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.

Linear increase
Five levels of relationships
Three levels of relationships
One level of relationships
No relationships
(Pentium IV/2.5GHz, Linux 2.4.20, Java 1.4.2,
100 runs)
88
Number of issued Access Rights and Information
Relationships
89
Request Processing and Proof Validation

• Query for location information.
• Service fingers someones 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.

91
Deployment shows that Cost of Proof Building is
competitive

• Project Aura
• Pervasive computing project at Carnegie Mellon
• Location service with access control
• Gathering location information 50-200ms
• Proof building lt20ms

92
Implementation of Access Rights/Relationships

• Digital certificates
• Distributable
• Modified SPKI certificates Example (cert
  (issuer (public_keybob)) (subject
  (public_keyalice)) (permission (information
  (public_keybob) location)) (tag ()))

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
Obscured Proof Descriptions Strawman
Calendar Service
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

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, SP 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.