Distributed Trust Management

1
Distributed Trust Management

• Sandro Etalle
• Jerry den Hartog
• Marnix Dekker
• Jeroen Doumen

2
Organization

• A Local Research Focal. Different speakers will
  treat different aspects
• First lecture
• Introduction
• Safety problem
• Remaining classes treat a DTM topic based on
  research papers, Next weeks topic Role based
  Access Control. (Please check website for papers
  to read.)

3
Overview

• Access Control Basics
• Delegation Certificates in Access Control
• Public key crypto, X.509 PGP
• Logic in Access Control
• Trust and Trust Management
• Role base TM
• Take-Grant models
• Difficult problems in AC TM
• Chain discovery
• Safety (Decidability)

4
Access Control

• Security policies describe allowed access.
  Access Control enforces these policies
• OS AC Access control matrix, Access control
  lists
• Maintenance, Consistency

5
Role base access control(1)

• Role (Similar to group)
• Teacher
• Student
• Assign access rights to Roles and Roles to users
• The added Indirection makes for easier maintenance

1) RBAC treated in more detail next week.
6
Role dependency (Role Hierarchies)

• Roles are not all independent
• University Employee
• University Teacher
• Role Hierarchies
• Define roles in terms of other roles
• Employee Professor Teacher Administrative
  Staff Support Staff
• Employee rights also granted to Professors.

7
Distributed AC

• Different authorities at different locations
• UT administrator does not control access to TU/e
  resources
• Different Hierarchies for different locations
• In NL PhD student is subrole of Employee
• in US PhD student is subrole of Student
• How to achieve access to distributed resources?
• TU/e student list, US student discount.

8
Delegation

• Define your roles based on roles of other users
• Jerry.StudentsInMyClass EducationOffice.Register
  edStudents215020
• Trust Management Issue
• I trust the education office to define the
  registered student role.
• Education office may trust registration office to
  define the student role
• EducationOffice.RegisteredStudents215020
  RegistrationOffice.Student and WebServer.subscribe
  d215020

9
Toward DTM

• Can specify trust rules
• Link roles in different Hierarchies
• Difficulty Naming Conventions ( AIO PhD
  student ).
• More fine grained control
• Different Roles for different users/locations
• Jerry.StudentsInMyClass
• Sandro.StudentsInMyClass
• EducationOffice.RegisteredStudents215020

10
Trust vs. Trust

• Notions of trust
• To get people to use a smartcard for storing cash
  (UT student card) they have to trust the card and
  the system.
• Psychological concept
• To raise the balance on the card the card has to
  trust the terminal requesting this.
• Technical, Computer Science notion

11
Why trust?

• Trust needed for cooperation
• Can not control behaviour of other people/systems
• Base of trust
• Own experience and experience of others
  (reputation based TM)
• Regulations
• Technical measures
• Taking a risk (risk vs benefit analysis when
  possible).
• Good behaviour slowly enforces/builds trust
• Bad behaviour quickly lowers trust

12
Why Trust (Cont.) ?

• Technical measures
• Create trust in the computation taking place
  elsewhere, e.g. on someone elses PC, a piece of
  hardware in hands of another person.
• Trusted computing platform Hardware chip base
  chain of trust chip checks signatures of
  programs to ensure they are not altered, can do
  essential computation steps.
• Smartcards allow protecting information and
  applications from the holder of the device (such
  as Twente student card mentioned above).

13
Distributed Trust Management

• DTM deals mainly with the technical notion of
  trust
• Formal rules describe trust, e.g. I trust
  RegistrationOffice to define the role Student
  (but not the role Friend).
• Grant rights of a user (other system) on the
  system by
• Establishing trust in user/requesting system
• Create a chain of trust from system to user.
• Specification Policies, delegation, naming,
• Implementation Certificates, Chain discovery,
  Logic,
• Applications AC, PGP-PKI, Tribler,
• Distributed Trust Management

14
Logic in Access Control

• Express Access control rules using logical
  predicates
• Classical Access control matrix can be translated
  predicates
• may-access(p,o,r) principle p has access right r
  to object o.
• Basic rules can also be expressed
• may-access(p,o,Wr) gt may-access(p,o,Rd)
• States Wr (write access) is stronger than Rd
  (read access)
• Different ways to generalize this principle

15
Logic in Access Control (2)

• Complications of distributed systems
• Often used construct SAYS
• for stating requests
• for delegation, e.g. p says may-access(q,o,r)

p says may-access(q,o,r) gt ( may-access(p,o,r)
gt may-access(q,o,r) )
16
Implementation Certificates

• Proof that you are a member of a role
• Student card issued by registration office
• More generally Binding of properties to an
  identity (public key) signed by the cerfitication
  authority (i.e. issuer of the role student).
• Proof that a role is defined in a given way
• Education office can issue a single certificate
  stating
• EducationOffice.RegisteredStudents215020
  RegistrationOffice.Student and WebServer.subscribe
  d215020
• rather than given a different certificate to each
  student

17
Using Certificates

• Use a chain of certificates to proof role
  membership
• Student card to proof student, confirmation from
  webserver to show registered, certificate of
  education office to show registration policy.
• (Automatic) Chain discovery can be difficult
• who stores certificates
• where to look for certificates

18
Examples of PKI certificate systems

• Public key crypto
• Certificate links public key to identity.
• May be signed by certificate authority trust
  based on trust in CA (Webbrouwers) or by other
  users trust by numbers (PGP).
• (PKI-gtC.),examples of PKI/certificate based
  systems
• X.509 Certificates bind a public key to a
  name(string)
• SPKI PKI with focus on authorization (rather
  than authentication), binding properties directly
  to public keys.
• Kerberos Single sign on system the user gets a
  ticket for use of a service. Ticket is a form
  of certificate.
• PGP Often used for encryption and signing of
  email. No central CAs for distribution of public
  keys.

19
Take-Grant model

• Use a directed graph to represent the Access
  control matrix.
• Edge between Role and Object labeled with right
  (e.g. read/write)
• Edge between Roles relationship between roles
  can takes rights of /may grants rights to.
• Rules for adding and edges and nodes to the graph.

20
Take-Grant Model example
Alice
Bob
t
Alice
Bob
t
R,W
R,W
R,W
File
File
Example of an application of the Take-rule Bob
takes Alices read/write permission
21
Safety problem

• Can subject obtain a right?
• Given a set of delegation rules and a set of
  initial permissions, decide whether a given
  permission can be granted.
• Undecidable in general
• Not possible to create algorithm that, given a
  set of rules and starting configuration decides
  this. (Equivalent to the Turing halting problem.)
• Decidable in linear time if set of delegation
  rules fixed to Take-grant model Jone76.

22
Conclusions

• Basics of distributed trust management
• Distributed access control
• Delegation control
• Next week more detailed discussion of Role based
  access control
• Please read the papers

23
Recommended Reading

• Decentralized Trust Management, M. Blaze et al.
• the PolicyMaker trust management system.
• comparison with X.509 and PGP.
• Formal Models for Computer Security, C. Landwehr
• Overview of classical data security notions and
  systems