1. Decentralized Trust Management Sandro Etalle Jerry den Hartog

2. Organization First lecture  Introduction Remaining classes  treat DTM topics based on research papers  Next week: Access Control Models  Then: Rule based Trust Management  Please check website for papers to read

3. Overview Why Trust Management ? Access Control Basics Delegation & Certificates in Access Control  Logic in Access Control  Take-Grant models  Safety problem  Public key crypto, X.509 & PGP Trust and Trust Management  Rule base TM  Reputation based TM

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

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

6. Controlling access to resources Restrict access to `authorized’ users Who decides ?  Authority on the resource  Delegation Who is authorized ?  Policies; who should have access  Who do I trust with the resource Dynamicity  Changes in indented users, policy, trust. Course treats trust management and AC mechanisms

7. Access Control Matrix Captures the rights users have to resources Example: Students may read grade list and read and run submitPaper Teacher may read and write grade list and submitPaper So we are done ? UserGradeListSubmitPaper Jerryrw Jorisrrx Timrrx

8. Access Control Storage & implementation: E.g. split in list, link to resource (Access Control List), check before use Maintenance, Consistency:  Captures intended policy (how to check?)  Rights not constant who may change checks consistency UserGradeListSubmitPaper Jerryrw Jorisrrx Timrrx UserSubmitPaper Jerryrw Jorisrx Timrx

9. Role base access control (1) Role (Similar to `group’)  Teacher  Student Assign access rights to Roles and Roles to users Added Indirection makes for easier maintenance RoleGradeList Teacherrw Studentr RoleUsers TeacherJerry StudentJoris, Tim 1) RBAC treated in more detail next week.

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

11. Decentralized 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.

12. Delegation Define your roles based on roles of other users:  Jerry.StudentsInMyClass = EducationOffice.RegisteredStudents2IF34 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.RegisteredStudents2IF34 = RegistrationOffice.Student and WebServer.subscribed2IF34

13. Towards Rule based TM 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.RegisteredStudents2IF34

14. 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 (see also next slide)  Taking a risk (risk vs benefit analysis when possible). `Good’ behaviour slowly enforces/builds trust `Bad’ behaviour quickly lowers trust

15. Why Trust (Cont.) ? Technical measures:  Create trust in the computation taking place elsewhere, e.g. on someone else’s 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).

16. Trust Management Main TM classes  Rule based TM E.g. when based on Regulations Trusted parties can be positively identified  Reputation based TM E.g. when based on behaviour, recommendations trust ~ subjective probability `correct’ behaviour

17. Rule Based Trust Management Example systems  Role based trust management (RT)  SDKI/SPKI  … Example scenario  “Student at accredited university gets discount” Shop.Discount ← AccBody.Univ.Student AccBody.Univ ← UT UT.student ← Alice

18. Rule Based Trust Management Distributed, Open  Each participant is authority, issues credentials  Participants can join, leave Delegation  entrust credentials of others Binary  User either fully trusted or not trusted Static trust level  No change based on actions of the user

19. Reputation System Example E-bay transaction feedback system

20. Recommendation Systems Example systems  E-bay transaction feedback system  Eigentrust Example scenario  “Users with good recommendations can buy a book”  Joint ordering action to get bulk discount  More participants means more savings  They do have to show up when the book arrives  Allow friends to join and/or recommend others to join Alice joins, Bob does not join but does recommend Charlie.

21. Reputation Based Trust Management Main properties  Distributed, Open Each participant is an authority Issues its own recommendations/feedback.  Delegation Place trust in the recommendations of others.  Multilevel and dynamic trust level level of trust actions influences the level of trust

22. Common features Rule based TM – Reputation Systems Combine info from different sources  trust sources providing information Openness; Anyone can  join or leave the system  issue credentials/recommendations Up to the other participants to decide trustworthiness of such credentials.

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

24. Back to specification of access rights How to express and enforce a policy?  AC matrix captures only a snapshot for single location  Also need to express `rules’ that lead to these rights and how to update permissions. E.g. Logic in access control Delegation, Trust management

25. Logic in Access Control Express access control rules with logical formulas:  Rights expressed by 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) => may-access(p,o,Rd) i.e. write access implies read access  Different ways to generalize this principle

26. 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) => ( may-access(p,o,r) => may-access(q,o,r) )

27. Expressing the intended policy AC matrix model not expressive enough  e.g. no rules Extend and make as strong as possible?  Example: Take-grant model Graph model adds delegation rules

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

29. Take-Grant Model example File R,W AliceBob t File R,W AliceBob t R,W Example of an application of the Take-rule; Bob takes Alices read/write permission

30. Safety problem Can subject obtain a right?  Given delegation rules, initial permissions:  can a given permission can be granted ? Undecidable in general  Not possible to create algorithm Takes as input set of rules and starting configuration Always stops with the correct decision. (Equivalent to the Turing halting problem.)  Decidable in linear time if set of delegation rules fixed to Take-grant model [Jone76].

31. Implications Undecidability of safety shows limits; AC policy language cannot be to expressive  Efficiently decide whether uses have a right  Check safety properties before granting right  Complexity in understanding Difficulty:  find AC specification mechanism simple to understand effectively computable sufficiently expressive

32. 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.RegisteredStudents2IF34 = RegistrationOffice.Student and WebServer.subscribed2IF34 rather than given a different certificate to each student

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

34. 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->C.),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.

35. Conclusions Basics of decentralized trust management  Distributed access control  Delegation control Next week; more detailed discussion of Access control models  Please read the papers, see http://www.win.tue.nl/~setalle/dtm/index.html

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