1. Decentralized Access Control: Overview Deepak Garg Foundations of Security and Privacy Fall 2009

2. What is Access Control? “Access control” refers to enforcement mechanisms that control users' access to resources in computer systems

3. Example: Access Control Via Locks The door controls access to the contents of the house Alic e

4. Example: Access Control Via Passwords Username: alice Password:*********** * The website controls access to Alice's account information Alic e

5. Access Control: General Picture Principal Request to perform operation Reference Monitor (Guard) ResourcePrincipal Policy Enter house Check bank balance Username: alice Password:*********** *

6. Other Examples ● File System: – Reference Monitor: Kernel – Policy: rwxrwxrwx ● Gmail: – Reference Monitor: Gmail's web server – Policy: Allow access only with password ● ACM Digital Library: – Reference Monitor: ACM's web server – Policy: Allow access to CMU's members

7. The Two Problems for the Guard Principal Request to perform operation Reference Monitor (Guard) ResourcePrincipal Policy ● Authentication: Identify the “Principal” making a request ● Authorization: Using policy decide whether or not to allow access

8. Authentication and Authorization Request to perform operatio n Resource Principa l Policy Authentication Who is requesting access? Authorization Should Alice be allowed access? Yes Reference Monitor

9. Centralized vs Decentralized ● Centralized – Think local files, operating system – Requesting principal and reference monitor on one machine – Policy is on the same machine ● Decentralized – Think AFS, internet – Principal and reference monitor may be separate (gmail, online bank accounts) – Policy may be distributed (e.g., ACM Digital Library)

10. Plan for the Lecture (and Next) ● Methods for authentication ● Representation of policy – In line with code – Access control matrices – Access control lists – Rule-based policies ● Policy distribution through certificates ● Public Key Infrastructures (PKIs)

11. Authentication

12. ● Identify which principal makes a request ● Issue 1: How do we name principals? – Operating system: uid (users), pid (processes) – Gmail: usernames – Bank's website: account number – Public keys ● Issue 2: Identify the principal in each request – Usually based on some secret

13. Authentication via Secrets ● Username and password based: – Principal provides username and password – Reference monitor (or authenticator) compares with an internal table – Match => authenticate as username ● Challenge-response – Reference monitor provides nonce to principal – Principal signs nonce with private key – Authenticate as owner of the verification key

14. Authentication via Secrets ● Authentication with long-term secrets – Principal and reference monitor exchange a shared secret ahead of time – Every request signed/accompanied by secret is implicitly authenticated, e.g., cookie based logins (gmail) Authentication is a well-studied problem that is relatively easy to solve using secret keys or passwords

15. Representation of Policies

16. Centralized Policies ● Represent in Code if (getuid() == 0) allow_access = true; else if (getuid() > 1000) allow_access = false; else... ● Mixes policy and its use ● Difficult to change or update policy – Change millions of lines of code to change the uid of root from 0 to 1

17. Centralized Policies ● Represent in Code if (getuid() == 0) allow_access = true; else if (getuid() > 1000) allow_access = false; else... ● Mixes policy and its use ● Difficult to change or update policy – Change millions of lines of code to change the uid of root from 0 to 1

18. Centralized Policies ● Access control lists – Store relevant policy with object /afs/user/Alice/bin Alice: rldwika Bob: rl All users: l ● Access control matrices [Lampson'71 ] – Function: Principals x Resources -> Permissions

19. Decentralized, Rule-Based Policies ● In web-based applications, and in ERM, parts of policies are often rule-based and decentralized ● E.g., Acess to the ACM Digital library – ACM's statement: If university U has a subscription, and M is a member of U, then M has free access – ACM's statement: CMU has a subscription – CMU's statement: Alice is a CMU student – Result: Alice has free access to ACM Digital Library Rule Decentralized

20. Decentralized Policies Principal Request to perform operation Reference Monitor (Guard) ResourcePrincipal Server2 Policy2 Server1 Policy1 Server3 Policy3 ● There is a delegation of trust (e.g., ACM -> CMU)

21. Comparison of Policy Representation In line with code Access control matrices/lists Rule-based, decentralized Difficulty of programming Difficulty of training Formal Rigor Flexibilit y

22. Policy Distribution Through Certificates

23. Decentralized Policy Distribution ● Individual administrators (e.g., CMU and ACM) represent policies in certificates ● Certificate = statement + digital signature ● Certificates are also called credentials For all U, M. ((U has a subscription) and (M is a member of U)) imply (M has free access) CMU has a subscription Alice is a member of CMU

24. Example of Distributed Access ACM CMU Download paper.pdf Prove that you are a member of CMU paper.pdf Inference: Certificate missing! Check certificate. Inference: Allow access

25. Certificate Verification and Inference ACM CMU Download paper.pdf Prove that you are a member of CMU paper.pdf Inference: Certificate missing! Check certificate. Inference: Allow access Certificate verification and inference are very important Certificate verification Policy rules and facts are authentic Inference Deduce permissions from rules and facts

26. Issue 1: Policy Languages ● What language is used to write policy statements and infer permissions from them? For all U, M. ((U has a subscription) and (M is a member of U)) imply (M has free access) ● Principled approaches: – Declarative Languages ● E.g., RT, SecPAL, Cassandra, Binder – Logics ● E.g., ABLP, GP, BL Next lecture

27. Issue 2: Search for Credentials ● How are relevant credentials collected at the reference monitor (e.g., ACM)? – Collect based on request and known policy; often called credential or certificate chain discovery – [Clarke et al, Li et al] – Requester (e.g., Alice) collects and provides to reference monitor ● Choice depends on application We'll make this assumption (Details in next lecture)

28. Issue 3: From Keys to Identities ● How are credentials checked? ● Reference monitor must verify signatures on them (to eliminate fake credentials), and make sure they are signed by expected individuals' keys. ● How is the mapping from keys to individuals' identities determined? – Public key infrastructures

29. Summary of Decentralized Policies ● Policy statements (rules, facts) are created by different individuals ● Statements are placed in certificates, which are signed ● At the time of access, relevant certificates must exist at the reference monitor; they are verified ● Inference is performed over the statements in the relevant certificates, to allow or deny access

30. Public Key Infrastructures

31. Public Key Infrastructure: Overview ● Public Key Infrastructure (PKI) is a framework (methods, protocols, formats, programs) for: – Generating private, public key pairs (optional) – Distributing public keys (essential) – Creating certificates, signing them, and verifying them (optional) ● Standards: X.509, PGP, SDSI/SPKI ● Implementations: Verisign, GnuPG, OpenSSL

32. The Three Components of a PKI ● Programs for (private, public) key-pair generation ● Distribution of public keys: – Establish trustworthy mappings from public keys to principals (individuals) ● Formats to represent text, binary certificates; programs to sign and verify them Implementation level details Standard cryptography Rest of the lecture

33. Problem: Map Keys to Principals ● The problem with naïve distribution: – Alice generates a (private, public) key-pair – Distributes public key it on the internet – Mallory (the bad one!) takes public key; gives to ACM as her key – ACM believes that every signature made by Alice is made by Mallory When should ACM trust a (key, principal) mapping given to it?

34. PKI with Certifying Authority ● A central, certifying authority (CA) trusted by everyone certifies keys ● CA's public key is known to everyone, say 0xa ● CA signs associations (public key, principal) with its private key only after it verifies that this is the case ● CA's certificate manifests trust in the mapping ● E.g., X.509 (standard); VeriSign (commercial)

35. Example: Certifying Authority ACM CA Public key (0xa); Well-known Key map: (0xb, Alice) Check certificate with 0xa. Okay, 0xb -> Alice Certify 0xb

36. PKI with Web of Trust ● No CA; trusted peers certify keys (web of trust) ● Example – ACM knows CMU's public key – CMU certifies (0xb, Alice) – If ACM trusts CMU, then CMU's certificate will imply that ACM trusts the map 0xb -> Alice – Alice may now certify Bob's key, etc. ● E.g., PGP (standard); GNUPG (implementation)

37. Example: Web of Trust ACM CMU Public key (0xa) Key map: (0xb, Alice) Check certificate with 0xa. Okay, 0xb -> Alice Certify 0xb Trusts

38. PKI with Local Names ● In a Web of Trust, peers (e.g., CMU) are trusted to name others ● What if namespaces are distinct? ACM and CMU may not call the same person Alice ● If CMU (0xa) certifies (0xb, Alice), then ACM should not believe 0xb -> Alice ● Instead, ACM believes 0xb -> CMU.Alice ● CMU.Alice is a name that represents the principal whom CMU calls Alice ● E.g., SPKI

39. Example: Local Names ACM CMU Public key (0xa) Key map: (0xb, Alice) Check certificate with 0xa. Known: 0xa -> CMU So, 0xb -> CMU.Alice Certify 0xb Partial trust

40. Summary of PKI ● PKI with certifying authority – Trusted authority certifies (key, principal) maps – Most common model ● PKI with web of trust – Trusted peers certify (key, principal) maps ● PKI with local names – Allow disjoint namespaces; learn associations up to relative names

41. Take-Home Points ● A reference monitor decides whether to allow access – Authentication: Who is requesting access? – Authorization: Does the policy imply access? ● Decentralized policies are often rule-based; represented with certificates ● For each request, the reference monitor must: – Collect and verify relevant certificates – Infer permissions from the certificates ● Reference monitor must know mapping from public keys to individuals' identities – use a PKI