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

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

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

Review of DLM Policy { o: r 1, r 2, …, r n } denotes a policy where o is the owner and the r i ’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 { o 1 : r 1,…, r n } ⊔ { o 2 : s 1, …, s n } = {o 1 :r 1,…,r n ; o 2 : s 1, …, s n } { o 1 : r 1,…, r n } ⊔ { o 2 : s 1, …, s n } = {o 1 :r 1,…,r n ; o 2 : s 1, …, s n }

DLM Declassification Suppose a principal A is acting with authority L A. Then A can declassify data with L 2 to label L 1 if the following condition holds: L 1 ⊑ L 2 ⊔ L A

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 Declassification Read Access Read Access If a program type-checks then it contains the proper dynamic checks

Example

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 Private keys are only given to authorized users through an unspecified PKI Ciphertext can safely be made public Ciphertext can safely be made public A user who wishes to share encrypted data can do so by sharing his private key 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

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

Kinds Three classes of Kinds Principals Principals Types Types EKey F (P : P 1, P 2, …, P n ) EKey F (P : P 1, P 2, …, P n ) 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)

Types K is a key name, which has kind EKey F (P : P 1, P 2, …, P n ) K is a key name, which has kind EKey F (P : P 1, P 2, …, P n ) 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

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

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 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 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! 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

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 K 1,...,K n where K i : EKey F (P i : P i1, P i2, …, P in ) we must have n encryption keys where the type of the i th encryption key is [EncKey(K i )] ri wi To encrypt a value with secrecy label K 1,...,K n where K i : EKey F (P i : P i1, P i2, …, P in ) we must have n encryption keys where the type of the i th encryption key is [EncKey(K i )] ri wi

Contd. When we decrypt we must have declassification certificates [K i ’ reclassifies K i ] r’i w’i When we decrypt we must have declassification certificates [K i ’ reclassifies K i ] 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 K i ’ Decrypting the data with this key gives us data that can only be read by those authorized in all of the K i ’

Kinds and Key Distribution Kinds also enforce the semantics of having a private key selectively distributed Suppose a key name K is of Kind EKey F (P : P 1, P 2,…,P n ) 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 P i ’s 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 P i ’s

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

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 This seems to imply that the system is completely static You would need to recompile whenever your labels changed You would need to recompile whenever your labels changed

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