Type-Based Distributed Access Control

1. Type-Based Distributed Access Control Tom Chothia, Dominic Duggan, and Jan Vitek Presented by Morgan Kleene

2. Problem • Enforcing access control in a distributed setting, i.e., in a setting where requests need not go through a central authority • Would like to do as much as possible statically

3. Model • Current paper extends and augments DLM, (Distributed Label Model) the foundation of JIF [Myers and Liskov] • All hosts are trusted (this can be relaxed, as in their later work) • We deal with mistrust between principals only, not a domain that we do not trust

4. Review of DLM • Policy { o: r1, r2, …, rn } denotes a policy where o is the owner and the ri’s are the readers authorized to read the data annotated with this policy (o is not necessarily a reader) • LUB operation on policies is simply the union of two policies • { o1: r1,…, rn } ⊔ { o2: s1, …, sn} = {o1:r1,…,rn; o2: s1, …, sn}

5. DLM Declassification • Suppose a principal A is acting with authority LA. Then A can declassify data with L2 to label L1 if the following condition holds: L1 ⊑ L2 ⊔ LA

6. Dynamic Operations (DLM) • In general, we don’t know what the labels of the data are • Operations involving dynamic labels must be checked dynamically • Declassification • Read Access If a program type-checks then it contains the proper dynamic checks

7. Example

8. Extending the Model (Chothia et. al.) • DLM says nothing about encryption • What properties of cryptography do we care about? • Private keys are only given to authorized users through an unspecified PKI • Ciphertext can safely be made public • A user who wishes to share encrypted data can do so by sharing his private key All three are modeled in the type system introduced

9. Policies • Mean the same thing as in DLM • In DLM, policies are expressed at the type level, now we introduce another level of abstraction and work at the Kind level • Kinds are ‘types’ for Types in the same way that Types classify values

10. Kinds • Three classes of Kinds • Principals • Types • EKeyF (P : P1, P2, …, Pn) The label inside the EKey constructor means exactly what it did before The F tag on the encryption key indicates whether the key is virtual (only used for specifying policy) or actual (has a corresponding cryptographic key)

11. Types • K is a key name, which has kind EKeyF(P : P1, P2, …, Pn) • An encryption key a+ has type [EncKey(K)]RW. This type has kind Type • A decryption key a- has type [DecKey(K)]RW • Principle names P are types having kind Prin • Primitive types (int, etc.) having kind Type

13. How can a user share a key? • Central Question: “Should it be possible to declassify encrypted data, making it available to principals that did not have access to It beforehand without having toe decrypt the data, declassify it, and then re-encrypt under another key?” • If no, then a simple treatment suffices • If yes (paper’s answer) things are more complex

14. Declassification Certificates • Allow a principal to issue a certificate giving another principal access to data encrypted with a particular key • If we do things the wrong way: • Principal P wants access to data it doesn’t have permission to read • The data may be encrypted with the a key that it has a declassification certificate for • It can just declassify the data and gain access! The problem is that when we decrypted we forgot about the constraints on the original data

15. Resolution using Kinds • Since we now have access control information in the Kinds we insist on two conditions • To encrypt a value with secrecy label K1,...,Kn where Ki : EKeyF(Pi : Pi1, Pi2, …, Pin) we must have n encryption keys where the type of the ith encryption key is [EncKey(Ki)]ri wi

16. Contd. • When we decrypt we must have declassification certificates [Ki’ reclassifies Ki]r’i w’i • Decrypting the data with this key gives us data that can only be read by those authorized in all of the Ki’

17. Kinds and Key Distribution • Kinds also enforce the semantics of having a private key selectively distributed • Suppose a key name K is of Kind EKeyF (P : P1, P2,…,Pn) • We forbid constructing a private key where there is a reader not on the access list in the Kind, for example [EncKey(K)]RW where R = EncKey(P: Q) and Q isn’t one of the Pi’s

18. Kinds and Declassification of Ciphertext The Kind of the decryption key already constrains who may see the output, so we can essentially give the ciphertext any read permissions we want

19. What it actually does • A soundness lemma is proved that implies that no dynamic checks are needed • This seems to imply that the system is completely static • You would need to recompile whenever your labels changed

20. Kinds • Lack of dynamic control seems undesirable • Possibly a consequence of the use of Kinds • In DLM principals are at the value level • Thus their types can be checked against those of files and other types not known statically Not clear how to do this here