Distributed Trust Management

1
Distributed Trust Management

• Sandro Etalle
• Jerry den Hartog
• Marnix Dekker
• Jeroen Doumen
• (webpage at www.cs.utwente/etalle/dtm)

2
Organization

• A Local Research Focus. 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
What is TM for ?

• Trust is needed to make decision on interaction
  with other entity
• How much value to put in the information you get
  in this class.
• Give access to a resource
• Decision has to be made with incomplete
  information
• Do not know if all the information you get is
  actually correct and state-of-the-art.
• Do not know how the resource will be used.

4
What is TM how does it help you in your decision

• Two classes of TM systems.
• Rule based systems Trust in the role the entity
  plays
• You trust the information given in this class
  because it is given by a teacher who has been
  assigned by the university and you trust that the
  university selects suitable teachers
• You trust the university because it is a
  certified institution of higher learning.
• You trust the certification body because it is
  appointed by the government
• Reputation Systems
• You trust in the information because you have had
  earlier classes from the teacher that were good
  and/or your friends tell you they had good
  classes from the teacher, or that their friends
  tell them they had good classes, etc.
• More on this later first some basics Access
  Control.

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

6
Access Control

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

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

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

10
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

11
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

12
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

13
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) )
14
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

15
Why trust?

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

16
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).

17
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

18
Reputation Systems

• Reputation systems try to capture the
  psychological notion of trust.
• Experience in past interactions will play big
  role in trust decision. But what if no or little
  interaction yet?
• Reputation systems (e.g. Ebay and similar)
• Participants evaluate an interaction and provide
  feedback.
• Positive feedback increases reputation, negative
  feedback reduces reputation.
• Reputation expresses collective experience of all
  participants.
• Personalizing trust through recommendations
• Use recommendations only of parties you trust
  e.g. you trust your friends so you somewhat trust
  the friends of your friends etc. The more you
  trust someone the more weight their
  recommendations will carry.

19
Common features Rule based TM Reputation Systems

• Combine information from different sources trust
  sources providing information
• Openness anyone can join or leave the system and
  issue credentials/recommendations. Up to the
  other participants to decide trust worthiness of
  such credentials.

20
Differences Rule based TM Reputation Systems

• Role of risk In rule based systems certificates
  state facts. Reputation systems include intrinsic
  risk reputation does not give any guarantees.
  (In het verleden behaalde resultaten geven geen
  garantie voor de toekomst).
• Yes/No verses numerical.
• Reputation changes with actions trust value is
  dynamic.

21
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

22
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

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

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

25
Take-Grant Model example
Transformation rule
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
26
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.
• Decidable in linear time if set of delegation
  rules fixed to Take-grant model Jone76.
• Not decidable in general
• Not possible to create algorithm that, given a
  set of rules and starting configuration decides
  this. (Equivalent to the Turing halting problem.)
• Variations

27
Side step Turing halting problem

• Assume we have program H(p,i) that outputs Y if
  p(i) halts and N if p(i) does not halt.
• Define prog T(i)
• If H(i, i) Y then loop else return false
• What does H(T,T) return?
• if Y then T(T) will loop so H(T,T) should give N
• if N then T(T) will stop so H(T,T) should give Y
• Contradiction H(p,i) cannot exist.

28
Undecidability of Safety problem

• Assume decidable, then there is some algorithm
  that makes this decision.
• Encode halting problem in Safety problem
• For a given TM machine construct a graph with a
  permission which is granted exactly when the TM
  halts (enters the halting state).
• Give this graph to our decision algorithmthe
  answer also gives whether the TM halts, thus we
  have solved the halting problem. CONTRADITIUON.

29
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

30
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