1. Introduction to Trust Logic Jeff Chase Duke University This presentation contains easily recognizable copyrighted material. No offense is intended. Please don’t sue me. Duke University is not responsible for any irresponsible actions on my part.

3. Outline Trust Crypto and CA-PKI Reference monitor Logical guards Trust logic GENI inter-cloud SafeSets DNSSEC Today: just the cartoon version. But it is all very logical.

4. Trust A principal is any entity that may: – Request an action – Respond to a request – Assert or receive a statement – Know a secret Trust is that which a principal must have in order to: – Honor a request – Accept a response – Believe a statement – Reveal a secret trusts Trust is usually limited to a particular function or purpose, which we would like to specify rigorously and constrain according to a policy. A AB

5. Principals in a networked system Alice Bob Mallory attack Principals are users or organizations, or software entities acting on their behalf. How can principals communicate securely? How do they decide whom to trust?

6. Crypto primitives Encrypt/Decrypt Signing Secure hashing Use a shared secret key (symmetric) or use a keypair one public, one private (asymmetric) useful for fingerprinting data

7. Cryptography for Busy People Standard crypto functions parameterized by keys. – Fixed-width “random” value (length matters, e.g., 256-bit) – Symmetric (DES: fast, requires shared key K1 = K2) – Asymmetric (RSA: slow, uses two keys) “Believed to be computationally infeasible” to break ED Encrypt Decrypt K1 K2 M M [Image: Landon Cox]

8. Asymmetric (public key) crypto Each subject/principal possesses a keypair. – Decrypt(K, Encrypt(K -1, M)) = M Keep one key private; the other is public. Either key can be used to encrypt/decrypt. If we know one another’s public keys then we can communicate securely. Anyone can mint a keypair.

9. abstrusegoose.com

10. Cryptographic hashes Also called a secure hash or one-way hash – E.g., SHA1, MD5 Result called a hash, checksum, fingerprint, digest Very efficient SHA1 hash 160 bitsArbitrarily large “Hash digest” #

11. Properties of Secure Hashing Collision-resistant – There exist distinct M 1 and M 2 such that h(M 1 ) == h(M 2 ). – Such collisions are “very hard” to find. One way – Given digest, cannot generate an M with h(M) == digest. – Such collisions are “very hard” to find. Secure – The digest does not help to discover any part of M. SHA1 XX##

12. Example use of one-way hash This is a line from /etc/passwd for user Fred Flintstone. /etc/login uses this record to validate the user’s password. The file is public, but Fred’s password is secret. Or is it? hashed #

13. Digital Signature A hash digest of message M encrypted with principal B’s private key is called a digital signature – Unforgeable. “Proves” that B sent M. – Certified. “Proves” M has not been tampered. – Non-repudiable. B cannot deny sending M. – But not private. Alice, Will you marry me? Signed, Bob

14. http://pst.libre.lu/mssi-luxmbg/p1/04_auth-art.html

15. Finding the right key How does Alice know Bob’s public key? Alice, Will you marry me? Signed, Bob

16. Endorsements: certificates A principal may endorse another’s key. Issue a signed statement containing the key, and some statement about the key. We call it a certificate. But how does anyone know the endorser’s key? Certificate Term of validity Issuer’s name (or key) Signature Bob’s key is 247E6F1A…

17. We can learn about keys from a chain of endorsements rooted in some trust anchor, whose key we “just know”. Example: root certifying authorities (CAs) whose keys are baked into your Web browser.

18. PKI  Trust management An entity A delegates trust to another by endorsing its public key for possession of an attribute or role. The delegation is a fact written as a logic statement and issued in a certificate that is digitally signed by A. In a standard x.509 identity cert (e.g., issued by a PKI CA for web), the attribute is a distinguished name. – e.g., “Alice” or “amazon.com” But it could be more… trusts AB A.trusts  B Certificate Term of validity Issuer’s name (or key) Signature Payload: statement

19. The need for access control Processes run on behalf of users. (“subjects”) Processes create/read/write/delete files. (“objects”) The system mediates these accesses. How should the system determine which subjects can access which objects? This problem is called access control or authorization (“authz”). It also encompasses the question of who is authorized to make a given statement.

20. Principles of Computer System Design Saltzer & Kaashoek 2009 Concept: reference monitor Reference monitor Example: Unix kernel Isolation boundary

21. Reference monitor What is the nature of the isolation boundary? If we’re going to post a guard, there should also be a wall. Otherwise somebody can just walk in past the guard, right? subject requested operation “boundary” protected state/objects program Alic e guard identity

22. Concept: access control matrix Alice Bob obj1obj2 RW R --- We can imagine the set of all allowed accesses for all subjects over all objects as a huge matrix. How is the matrix stored? Are distinguished names (e.g., Alice) sufficient for access control?

23. Concept: ACLs and capabilities Alice Bob obj1obj2 RW R --- How is the matrix stored? Capabilities: each subject holds a list of its rights and presents them as proof of access rights. A capability is an unforgeable token that confers rights to access a specific object. Access control list (ACL): each object stores a list of subjects permitted to access it. capability list ACL

24. Concept: roles or groups Alice Bob wizardstudent yes no A role or group is a named set S of subjects. Or, equivalently, it is a named boolean predicate that is true for s iff s  S. Roles/groups provide a level of indirection that simplifies the access control matrix, and makes it easier to store and manage. roles, groups wizard student obj1obj2 objects RW R ---

25. Attributes and policies More generally, we may view a subject/object identity as a list of named attributes with typed values (e.g., boolean). Generally, an access policy for a requested access is a boolean (logic) function over the subject and object identities. name = “Alice” wizard = true Name = “obj1” access: wizard name = “Bob” student = true Name = “obj2” access: student

26. Access control: general model We use this simple model for identity and authorization. Real-world access control schemes use many variants of and restrictions of the model, with various terminology. – Role-Based Access Control (RBAC) – Attribute-Based Access Control (ABAC) A guard is the code that checks access for an object, or (alternatively) the access policy that the code enforces. There are many extensions. E.g., some roles are nested (a partial order or lattice). The guard must reason about them. – Security clearance level TopSecret  Secret [subset] – Equivalently: TopSecret(s)  Secret(s) [logical implication]

27. Access control logic Alice, Will you marry me? Signed, Bob Guard condition A.marry(X)  A.likes(X), A.mother(Y, A), Y.likes(X), A.mother(Z, X), Y.likes(Z), A.likes(Z), Z.likes(A), G.age(A, v>18), … This is logic programming. p(B) “Predicate p is true of B” A.p(B) “A says p is true of B” A.p(X)  A.trusts(G), G.p(X) “If A trusts the government and the government says p(X) then A believes it.

28. Access control logic Alice, Will you marry me? Signed, Bob Alice may have additional conditions for access, e.g.: A.grad(X, Duke) What does this mean? X is a graduate of Duke? X is a grad student at Duke? The real-world meaning of a predicate is a convention among the principals.

29. Access control logic Alice, Will you marry me? Signed, Bob Z.grad(X), A.top(Z) Can the guard instead require the goal condition: “A believes X is a graduate of any top university, whether or not it is Duke?” This is a linked delegation or attribute-based delegation. A trusts any principal Z to endorse X as a grad, on the condition that Z is a top university. How does A conclude top(Z)? That is another rule. Note: this Z is not mother(X), even though a valid inference must substitute variables consistently within the applied rule.

30. Quick check How does any principal know what another says? Can any principal know what another believes?

31. Quick check How does any principal know what another says? Can any principal know what another believes? Certificate Expires 2014 G: The Government The Government G.born(Alice, 1984) Certificate Expires 2014 G: The Government The Government G.age(X, 18)  G.born(X, 1984) These certificates are credentials: Alice can present them to gain access from another principal’s guard. But how does the guard know that the statement is really about Alice?

32. Federated substrate with end-to-end virtualized “slices” GENI: NSF initiative for network testbed integration It has grown into an architectural blueprint for: Federated IaaS (Infrastructure-as-a-Service) clouds Delivery platform for next-generation network apps Clouds integrated with advanced networks Spiral deployment accelerates in 2013 (e.g., ExoGENI)

33. Slices and federation Backbone #1 Backbone #2 Campus #3 Campus rack Access #1 Commercial Clouds Corporate GENI suites Other-Nation Projects Research Testbed Campus My “slice” runs across the evolving GENI federation. My GENI Slice Slice: an end-to-end virtual execution context with configurable properties, e.g., containment and isolation.

34. GENI control framework for federated orchestration Open Resource Control Architecture “Make my slice.” “Instantiate VMs and VLANs x, y, z.” Network provider “Link sites with circuits.” “Enable external SDN controller for x, y, z.” OpenFlow The Big Picture: Cartoon Version Site ASite B Not shown: dynamic slice adaptation under automated control

36. Sponsored by the National Science Foundation 36 GENI on the back of a napkin Standard issue BBN napkin Chip Elliott, 2008

37. Bidirectional trust based on agreements GENI Operations and Control GENI trust structure: overview (v1.0) CH AM Users and tools Principals are users and organizations, and tools or servers acting on their behalf. Users create global slices and request aggregates to bind local resources to those slices.

38. Deconstructing the clearinghouse GOC GENI “clearinghouse” Introduce a federation trust anchor: GOC. – GENI Operational Control – Think: just a signing key! Decouple the services that comprise the Clearinghouse. – Coordinators for identity, authorization, brokering, resource control…. GOC endorses the coordinators for specific roles. – Delegate powers. – Endorse approved AMs. AM GENI “trusted computing base” GOC trusts AMs to comply with agreements.

39. GENI trust structure: overview (v2.0) AM GOC Each of these entities may: – Speak with its own keypair. – Wield credentials. – Produce/consume credentials. There are limited trust relationships among them. Trust reflects agreements, and is limited by their scope. Credentials capture this trust. Trust may be transitive. Transitive trust is inferred from facts and policy rules. GMOC I&M AMs trust the coordinators, transitively. GENI “clearinghouse” Example coordinators: identity and authorization services for a federation.

40. Declarative trust structure AM GOC This is a trust graph. – Edges represent partial trust by source entity in the target. We can capture trust graphs in a trust logic. o Some out-edges are facts given by an entity’s local operator. o The others are inferred locally by applying locally accepted policy rules to facts. GMOC I&M The trust delegations and policies for inferring trust may be specified declaratively and checked automatically.

41. IdP PA Create project SA Register user Delegate project membership Create slice in x AM Create sliver in in s Verify user identity, obtain attributes, check that user is qualified, execute agreement. Verify that user is authorized to create project and act as project leader. Verify that project x is valid and user is authorized to create slice in project x. Verify that slice s is valid and user is authorized to request resources for s. 12 3 4 5 IdP: Identity Provider PA: Project Authority SA: Slice Authority

42. IdP Issue user credentials Users have roles e.g., student, faculty. Register user user registered Identity Portal/Provider (IdP) IdP.geniUser(T) IdP.student(T) IdP.enrolled(T, CS-510) IdP.geniUser(D) IdP.faculty(D) An IdP asserts facts about users. User attributes may include inCommon attributes harvested through indirect delegation to Shibboleth IdPs. These attributes may have parameters with simple values (strings or numbers). D T

43. IdentityProvider(IdP) Service Provide r Directory 1. I’d like access 2. Please login to your home IdP, which I trust. 3. I’d like to login for SP. Use r 4. Login 5. Here are your session attributes to send to SP. 6. Here are my attributes. 8a. Access granted 8b. Access Denied Policy SSO 101 (e.g., Shibboleth)

44. Create sliver for slice SA.s SA AM Policy: a scenario SA.creator(T, s) IdP.geniUser(T) Anyone can create a sliver for a slice SA.s if s was approved by an SA I trust, and the request conforms to slice policies. Only the creator of a slice s may create a sliver for s.......or a delegate of the creator... Subject to the policies of the project that contains the slice..

45. Policy mobility: a scenario PA Any approved GENI user who is also a faculty member can create/lead a project. The project leader may delegate membership in the project to any GENI user. Any project member may create a slice for the project. SA Anyone can create a slice for a project PA.x if x was approved by a PA I trust, and the request conforms to project policies. Only the creator of a slice s may create a sliver for s, or a delegate of the creator, consistent with project policies.

46. SA Create slice in PA.x SA.creator(T,s) Capability delegation: what does it mean? SA.cap*(X,s)  SA.creator(X,s) SA.cap(X,s)  SA.cap*(X,s) Capability delegation SA.cap*(X,s)  SA.cap*(Y,s), Y.cap*(X,s) Capability confinement SA.cap(X,s)  SA.cap*(Y,s), Y.cap(X,s) Here are declarative policy rules that define the semantics of capability-based access control.

47. Cloud-based credential storage Concept: always-on, highly available credential store. The store is lightly trusted: it cannot forge credentials, but we must trust it not to “forget” them. Server Put issued credentials and policies (certs) in the store. Get certs to “cache or check”. Pass credentials by reference in request. Cert Store See also: Conchord, CERTDIST

48. Cloud-Based Credential Store IdP Issue user credentials PA Create project SA Register user Issue project x credentials Create slice in x Issue slice s credentials Create sliver in s 1 3 5 24 Delegate End-to-end credential flow

49. DNSSEC [http://www.nlnetlabs.nl/publications/dnssec_howto/] [Osterweil; Massey; Zhang] https://www.iana.org/dnssec

50. DNSSEC [http://www.potaroo.net/ispcol/2010-06/dnssec.html]