1. Distributed Trust Management security1.win.tue.nl/~zannon e/teaching/dtm10-11.html

2. Course Organization Introduction AC, DTM topics based on research papers  Next week: Discretionary Access Control Website:  List of Topics  Papers to read security1.win.tue.nl/~zannone/teaching/dtm10-11.html

3. The need for Data Protection Confidential data  Databases with essential business information Private data  EHR, RFID, OVchip, `Slimme meter’ Risks & Threats. News headlines:  Bank looses unencrypted laptop with client db  Job seekers victim identity theft  Hacker publishes 14 million stolen passwords  Justice demands pictures ov-chipcard travelers ...

4. The need for Trust Decision on interaction with other entity:  Value to give to information in this lecture.  Give access to a resource. Incomplete information  Is the information correct, state-of-the-art?  How will the resource be used?

5. Trust Management Establishing trust in the digital world TrusterTrustee Gives Trust Subjective, perceived probability Claims/Shows Trustworthiness Trust me I’m a doctor

6. Controlling access to resources Who is trusted to do what with a resource  Subject, Action, Object I’m Bob Bob May Park

7. Access Control Matrix Policy: 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. Controlling access to resources Enforcement, Implementation Maintenance, Consistency  Captures intended policy (how to check?)  Dynamicity; Rights not constant Specification, Policies  Authority on the resource; Who decides? Decentralized systems, Delegation.  Conditions, Obligation, Purpose Privacy  Anonymity, attribute based AC CENSORED

9. Access Control Lists Enforcement & Maintenance UserGradeListSubmitPaper Jerryrw Jorisrrx Timrrx UserSubmitPaper Jerryrw Jorisrx Timrx

10. 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 in a later lecture.

11. Role dependency (Role Hierarchies) Staff Prof Lecturer ScientificFinancial... Legal... Staff may Enter Building  Staff rights also granted to Professors

12. Decentralized AC Different authorities at different locations  UT admin does not control TU/e resources Different Hierarchies for different locations  In NL PhD student is subrole of Employee  in US PhD student is subrole of Student Access control for distributed resources?  TU/e student list, US student discount.

13. Delegation Define your roles based on roles of other users:  Jerry.StudentsInMyClass = EducationOffice.RegisteredStudents2IS25 Trust Management Issue:  I trust education office to define registered student role  In turn education office may trust registration office EducationOffice.RegisteredStudents2IS25 = RegistrationOffice.Student and WebServer.subscribed2IS25

14. Towards Rule based TM Can specify `trust rules’  Link roles in different Hierarchies  Difficulty: Naming Conventions e.g. AIO – PhD student More fine grained control Different Roles for different users/locations  Jerry.StudentsInMyClass  Sandro.StudentsInMyClass  EducationOffice.RegisteredStudents2IF34

15. Why trust? Trust needed for cooperation  Cannot control behaviour of other people/systems Base of trust  Own experience and experience of others  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

16. Why Trust (Cont.) ? Trusting remote computation  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 protect information, applications from device holder

17. Trust Management Main TM classes  Rule based TM E.g. based on Regulations Trusted parties can be exactly determined trust ~ formal relationship  Reputation based TM E.g. when based on behaviour, recommendations trust ~ subjective probability `correct’ behaviour Trust me I’m a doctor

18. 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 ← TUe TUe.Student ← Alice

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

20. Reputation System Example E-bay transaction feedback system Eigentrust: More advanced combination

21. Reputation Systems Scenario Joint ordering to get bulk discount More participants = more savings Do have to show up when the book arrives Allow friends to join & recommend others  Alice joins  Bob does not join but recommends Charlie  Charlie does not join but recommends Dave...

22. Reputation Based TM 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

23. Common features TM classes Combine info from different sources  trust sources providing information Openness; Anyone can  join or leave the system  issue credentials/recommendations Other participants decide on their value

24. Differences TM classes 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; level of trust is dynamic.

25. Back to specification of access rights AC matrix snapshot for single location TM meant to link locations Policies to capture `rules’  Rules underlie the permissions in AC matrix  Derive, Update, Maintain permissions  E.g. Logic in access control

26. Logic in Access Control Express AC 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) write access implies read access  Different ways to generalize this principle

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

28. Expressing the intended policy AC matrix not expressive enough  e.g. no rules Just add anything you can think of ? Limit on expressiveness  Illustrate with Take-grant model

29. Take-Grant model Directed graph represents AC matrix.  Edge Role -- Object labeled with right (e.g. read/write) Delegation rights added  Edge between Roles: can take/may grant rights Changes in response to delegation actions  Rules for changing graph

30. 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 Alice’s read/write permission

31. Safety problem Can subject obtain a right? Given delegation rules, initial permissions: can a given permission be granted ? Decidable in linear time if delegation rules fixed to Take-Grant model [Jone76]. Undecidable in general (details next week)  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.)

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

33. Implementation: Certificates Proof that you are a member of a role  Student card issued by registration office More generally: Binding of properties (attributes) to an identity (public key) signed by the cerfitication authority (issuer of role student). Proof that a role is defined in a given way  Education office can issue a single certificate stating EduOffice.RegStudents2IS25 = RegOffice.Student and WebServer.subscribed2IS25 rather than giving a different certificate to each student

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

35. PKI & certificate systems PKI  Public key cryptosystem, e.g. RSA  Certificate links public key to identity.  Trust based on authority that signs Trusted roots predefined in web browser trust by numbers (PGP) 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.

36. Conclusions Basics of decentralized trust management  Distributed access control  Delegation control Remaining Lectures treat  Access Control  Privacy Policies  Rule based Trust Management  Reputation Systems  Applications of TM Systems Please check papers & info at: security1.win.tue.nl/~zannone/teaching/dtm10-11.html

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

38. The End