Type Based Distributed Access Control Tom Chothia È cole Polytechnique Joint work with Dominic Duggan (Stevens) and Jan Vitek (Purdue)

Motivation Our aim is to use types to place conditions on how data may be distributed. Our aim is to use types to place conditions on how data may be distributed.

Motivation Consider a computer with public and private data: Consider a computer with public and private data:

Motivation Our aim is to use types to place conditions on how data may be distributed. Our aim is to use types to place conditions on how data may be distributed. Consider a computer with public and private data: Consider a computer with public and private data:

Motivation Our aim is to use types to place conditions on how data may be distributed. Our aim is to use types to place conditions on how data may be distributed. Consider a computer with public and private data: Consider a computer with public and private data:

Motivation Our aim is to use types to place conditions on how data may be distributed. Our aim is to use types to place conditions on how data may be distributed. Consider a computer with public and private data: Consider a computer with public and private data:

Motivation Our aim is to use types to place conditions on how data may be distributed. Our aim is to use types to place conditions on how data may be distributed. Consider a computer with public and private data: Consider a computer with public and private data:

Talk outline Review: Decentralized Label Model (DLM) Review: Decentralized Label Model (DLM) –Local Access Control Key Based Decentralized Label Model (KDLM) Key Based Decentralized Label Model (KDLM) –Distributed Access Control and Cryptography The Jeddak Language The Jeddak Language Conclusions Conclusions

Local Access Control Local Access Control restricts access to data. Local Access Control restricts access to data.

Local Access Control Local Access Control restricts access to data. Local Access Control restricts access to data. Any read or write attempts are dynamically checked. Any read or write attempts are dynamically checked.

Local Access Control Local Access Control restricts access to data. Local Access Control restricts access to data. Any read or write attempts are dynamically checked. Any read or write attempts are dynamically checked. There are no restrictions on authorized copies of data. There are no restrictions on authorized copies of data.

Types for Information Flow High and Low security types. High and Low security types. high low

Types for Information Flow High and Low security types. High and Low security types. No read up. No write Down. No read up. No write Down. high low

Types for Information Flow High and Low security types. High and Low security types. No read up. No write Down. No read up. No write Down. A Total Order A Total Order high low

Types for Information Flow High and Low security types. High and Low security types. No read up. No write Down. No read up. No write Down. A Total Order. A Total Order. Even a lattice. Even a lattice. high low

Types for Information Flow Secrecy duel to Integrity. Secrecy duel to Integrity. Declassification? Declassification? high low

Types for information Flow x: int high; y: int low; x: int high; y: int low; Can do: Can do: x = x +2 ; x = y + 2; if x > y then x = y; Can’t do: Can’t do: y = x; if x > y then y = 0; if guess = pwd then reject;

J.I.F. and the Decentralized Label Model (DLM) Program variable x Program variable x –Has data type int –Has label with policies  Bob : {bob, jane, mike}  Mary : {bob, jane, mary} –Is accessible by bob and jane –Access control checked by type checking

DLM Types for Information Flow DLM, bottom half of lattice. DLM, bottom half of lattice. No one has an automatic right to read your data. No one has an automatic right to read your data. Alice Bob Eve

Declassification in the DLM Data has type {L1, L2, L3} int Data has type {L1, L2, L3} int

Declassification in the DLM Data has type {L1, L2, L3} int Data has type {L1, L2, L3} int L1 = bob : { bob, jane } L1 = bob : { bob, jane }

Declassification in the DLM Data has type {L1, L2, L3} int Data has type {L1, L2, L3} int L1 = bob : { bob, jane } L1 = bob : { bob, jane } L2 = mary : { bob, jane, mary } L2 = mary : { bob, jane, mary }

Declassification in the DLM Data has type {L1, L2, L3} int Data has type {L1, L2, L3} int L1 = bob : { bob, jane } L1 = bob : { bob, jane } L2 = mary : { bob, jane, mary } L2 = mary : { bob, jane, mary } L3 = jane : { jane, tim} L3 = jane : { jane, tim}

Declassification in the DLM Data has type {L1, L2, L3} int Data has type {L1, L2, L3} int L1 = bob : { bob, jane } L1 = bob : { bob, jane } L2 = mary : { bob, jane, mary } L2 = mary : { bob, jane, mary } L3 = jane : { jane, tim} L3 = jane : { jane, tim} Only Jane can access data Only Jane can access data

Declassification in the DLM Data has type {L1, L2, L3} int Data has type {L1, L2, L3} int L1 = bob : { bob, jane } L1 = bob : { bob, jane } L2 = mary : { bob, jane, mary } L2 = mary : { bob, jane, mary } L3 = jane : { jane, tim} L3 = jane : { jane, tim} Only Jane can access data Only Jane can access data L3  jane : { jane, tim, bob} L3  jane : { jane, tim, bob}

Declassification in the DLM Data has type {L1, L2, L3} int Data has type {L1, L2, L3} int L1 = bob : { bob, jane } L1 = bob : { bob, jane } L2 = mary : { bob, jane, mary } L2 = mary : { bob, jane, mary } L3 = jane : { jane, tim} L3 = jane : { jane, tim} Only Jane can access data Only Jane can access data L3  jane : { jane, tim, bob} L3  jane : { jane, tim, bob} Now Jane and Bob can access the data Now Jane and Bob can access the data

DLM

DLM Data is protected by its type. Data is protected by its type.

DLM Each attempt to copy data is statically checked at compile time. Each attempt to copy data is statically checked at compile time.

DLM Data is protected by its type. Data is protected by its type. Each attempt to copy data is statically checked at compile time. Each attempt to copy data is statically checked at compile time. Copies of data have the same type and hence the same protection. Copies of data have the same type and hence the same protection.

DLM Data is protected by its type. Data is protected by its type. Each attempt to copy data is statically checked at compile time. Each attempt to copy data is statically checked at compile time. Copies of data have the same type and hence the same protection. Copies of data have the same type and hence the same protection. Data sent outside the type checked area is no longer protected. Data sent outside the type checked area is no longer protected.

Talk outline Review: Decentralized Label Model (DLM) Review: Decentralized Label Model (DLM) –Local Access Control Key Based Decentralized Label Model (KDLM) Key Based Decentralized Label Model (KDLM) –Distributed Access Control and Cryptography The Jeddak Language The Jeddak Language Conclusions Conclusions

Protocol Minimize the Trusted Computing Base Network Application DLM

Protocol Communication Security Minimize the Trusted Computing Base Network Application DLM

Protocol Communication Security Minimize the Trusted Computing Base Network Application Communication Network Application Communication Security DLM KDLM

KDLM: Connecting Keys and Access Restrictions Key names have policies (ACLs) Key names have policies (ACLs) –K has policy: Joe : {Jane, Mike, Sam} –Public-private key pair for key name –Private key protected by access restrictions Labels are sets of key names Labels are sets of key names –Access restricted to intersection of policies (ACLs)

Keys, Labels and Certificates Key & Policy: Key & Policy: K : Key[ bob : {mary,sam,bob} ] Label: {,, …,} Label: {K 1, K 2, …,K n } Labeled Type: T {K1,..,Kn}, {K1’,..,Km’} Declassification Cert Types: declassifies Declassification Cert Types: K 1 declassifies K 2 K1  K2

KDLM

KDLM As with the DLM data is protected by its type. As with the DLM data is protected by its type.

KDLM

KDLM But the data can also be protected by encryption. But the data can also be protected by encryption.

KDLM As with the DLM data is protected by its type. As with the DLM data is protected by its type. But the data can also be protected by encryption. But the data can also be protected by encryption. Encryption protects data leaving the trusted area. Encryption protects data leaving the trusted area.

KDLM As with the DLM data is protected by its type. As with the DLM data is protected by its type. But the data can also be protected by encryption. But the data can also be protected by encryption. Encryption protects data leaving the trusted area. Encryption protects data leaving the trusted area. Keys are protected in the same way as data. Keys are protected in the same way as data.

Labeled Keys K : Key ( P:{P 1,…,P k } ) K : Key ( P:{P 1,…,P k } ) a + : [ EncKey ( K ) ] a + : [ EncKey ( K ) ] a - : [ DecKey ( K ) ] L a - : [ DecKey ( K ) ] L Key names exist at the type level. Key names exist at the type level.

KDLM Alice Bob K:A,B K

KDLM Alice Bob K:A,B K

KDLM Alice Bob K:A,B K

KDLM Alice Bob K:A,B K

KDLM Alice Bob K:A,B K K

KDLM Alice Bob Eve K:A,B K

KDLM Alice Bob K:A,B K K

Why Key-Based DLM? Some form of structural equivalence/inclusion on labels is still needed Some form of structural equivalence/inclusion on labels is still needed e 1 has label L 1 e 2 has label L 2 “If e then e 1 else e 2 ” has label L 1  L 2 Who would own result label if it was named? Who would own result label if it was named?

Why Key-Based DLM? Suppose we added reclassification certs to DLM Suppose we added reclassification certs to DLM e 1 has label {Joe:{Mary,Sue}} e 2 has label {Joe:{Mary,Sue}} Joe can declassify e 1 ’s label: Joe can declassify e 1 ’s label: declassify ({Joe:{Mary,Sue,Sam}}, e 1 ) Suppose Joe issues certificate: Suppose Joe issues certificate: Joe:{Mary,Sue,Sam} declassifies Joes:{Mary,Sue} Then e 2 can also be declassified! Then e 2 can also be declassified!

Key Type Rules New names are created by the right principal. New names are created by the right principal. Restrictions on who may use a key are greater or equal to the restrictions implied by the key name. Restrictions on who may use a key are greater or equal to the restrictions implied by the key name. All of the keys named in the label are provided for encryption. All of the keys named in the label are provided for encryption. Decrypted data is assigned the labels from the keys used to decrypt. Decrypted data is assigned the labels from the keys used to decrypt.

Jane {K1, K2, K3} Encrypted(int) Bob Mary

K1 has policy: bob : {bob, jane} Jane {K1, K2, K3} Encrypted(int) K1 Bob Mary K1

K2 has policy: mary : {bob,jane,mary} Jane {K1, K2, K3} Encrypted(int) K1 Bob Mary K1K2

K3 has policy jane : {jane } Jane {K1, K2, K3} Encrypted(int) K1 Bob Mary K1K2 K3

Jane {K1, K2, K3} Encrypted(int) K1 Bob Mary K1K2 K3 K1 K3

Jane {K1, K2, K3} Encrypted(int) K1 Bob Mary K1K2 K3 K1 K3

Types, Principals, Key Names Type int 3 decKey  K  k-k- Prin P Ekey ( P:{P 1 …P k } ) K encKey  K  k+k+ x [T] L,L’ Kinds Types Key Name Prin Values

Types, Principals, Key Names Type int 3 decKey  K  k-k- Prin P Ekey ( P:{P 1 …P k } ) K encKey  K  k+k+ x [T] L,L’ Kinds Types Key Name Prin Values

Kinds, Types, Labels Arities, Kinds A ::= Prin A ::= Key F [P:{P 1 …P k} ] A ::= Type Flags F ::= Virtual F ::= Actual Key names, Principals, Types K,P,T ::= k, p, t K,P,T ::= DecKey  K  K,P,T ::= EncKey  K  K,P,T ::= AuthKey  K  K,P,T ::= SignKey  K  K,P,T ::= K 1 reclassifies K 2 K,P,T ::= E{LT} K,P,T ::= S{LT} K,P,T ::= Chan  LT  K,P,T ::=  t:A  LT L ::= {K 1,…,K m } LT ::= [T] L1,L2

Expressions E ::= newKey  k:A  {e} E ::= newKey  k:A  (a + :LT 1, a - :LT 2 ) {e} (a + :LT 1, a - :LT 2 ) {e} E ::= encrypt K (e 1,….,e k,e) E ::= decrypt K1,K2 (e 1,…,e k,e) E ::= sign K1,K2 (e 1,…,e k,e) E ::= auth K (e 1,…,e k,e) E ::= reclassifyCert K1,K2 () E ::= reclassifyCert K1,K2 (e) E ::= chain K1,K2,K3 (e1,e2) E ::= x, y, z, w E ::= a, b, c, n E ::= new(n:LT){e} E ::= fork{e} E ::= send(e 1,e 2 ) E ::= receive(a) E ::= pack  t:A  LT (K,e) E ::= unpack e 1 to  k:A  (x:LT){e 2 }

KDLM Type Rules for Keys TE |- K : Key ( P: { Ps } ) P in ( L2 PRINS of TE ) ( L1 PRINS of TE ) subset of { Ps } ] L1,L2 TE |- [ DecKey(K) ] L1,L2

KDLM Type Rules for Keys TE |- K : Key ( P: { Ps } ) P in ( L2 PRINS of TE ) ( L1 PRINS of TE ) subset of { Ps } ] L1,L2 TE |- [ EncKey(K) ] L1,L2 TE |- K : Key ( P: { Ps } ) P in ( L2 PRINS of TE ) ] L1,L2 TE |- [ DecKey(K) ] L1,L2

TE;VE |- encrypt ( { Key i }, data ) : [E{T}] {},L’ TE;VE |- { Key i } : { [ EncKey(K i ) ] L1,L1’ } TE;VE |- data : [T] L0,L’ L0 = {K i }

TE;VE |- encrypt ( { Key i }, data ) : [E{T}] {},L’ TE;VE |- { Key i } : { [ EncKey(K i ) ] L1,L1’ } TE;VE |- data : [T] L0,L’ L0 = {K i } TE;VE |- decrypt ( { Key i }, data ) : [T] L,L’ TE;VE |- { Key i } : { [ DecKey(K i ) ] L2,L2’ } TE;VE |- data : [E{T}] {},L’ L = {K i }

Correctness Theorem 1: (Subject reduction) Theorem 1: (Subject reduction) Types are preserved by reduction Types are preserved by reduction therefore no data leaks. therefore no data leaks.

Correctness Theorem 1: (Subject reduction) Theorem 1: (Subject reduction) Types are preserved by reduction Types are preserved by reduction therefore no data leaks. therefore no data leaks. Theorem 2: (Progress) Theorem 2: (Progress) Any expression that isn’t a value can be Any expression that isn’t a value can be reduced or it’s mismatched decryption. reduced or it’s mismatched decryption.

Talk outline Review: Decentralized Label Model (DLM) Review: Decentralized Label Model (DLM) –Local Access Control Key Based Decentralized Label Model (KDLM) Key Based Decentralized Label Model (KDLM) –Distributed Access Control and Cryptography The Jeddak Language The Jeddak Language Conclusions Conclusions

Jeddak Generic Java extended with distributed access control using keys Generic Java extended with distributed access control using keys Jeddak extends Java with Jeddak extends Java with –Principals –Key names –Labels and policies

GJ: Generic Java Type: int, string, Object, Vector,…. Type: int, string, Object, Vector,…. Vector returns type Object s. Vector returns type Object s. Generic type: Vector, MyObject Generic type: Vector, MyObject

The Java Crypto API KeyPair pair = keyGen.generateKeyPair(); PrivateKey priv_key = pair.getPrivate(); PublicKey pub_key = pair.getPublic(); Cipher enCipher = Cipher.getInstance("...") enCipher.init(encrypt_mode,pub_key)enCipher.doFinal(data)

Approximate Jeddak Crypto API KeyPair pair = keyGen.generateKeyPair(); PrivateKey priv_key = pair.getPrivate(); PublicKey pub_key = pair.getPublic(); Cipher enCipher = Cipher.getInstance("...") Cipher.getInstance("...")enCipher.init(encrypt_mode,pub_key_array);enCipher.doFinal(data)

Key Agreement KeyAgreement.init( key ) Key key1 = KeyAgreement.doPhase( key, lastFlag ) SecretKey KeyAgreement.generateSecrate( “…” )

Key Agreement KeyAgreement.init( key ) Key key1 = KeyAgreement.doPhase( key, lastFlag ) SecretKey KeyAgreement.generateSecrate( “…” )

A simple example Key [ ThisPrin:{} ] Kpriv; string {KPriv} mysecret; p public void reader1 ( String arg ) { … } public void reader2 (String {KPriv} arg) {…} reader( mysecret ) ; reader2 (mysecret);

Patient Doctor example Prin Doctor1, Patient, Nurse, Doctor2;

Patient Doctor example Prin Doctor1, Patient, Nurse, Doctor2; KeyNm [ Doctor1 : { Doctor1, Patient } ] DocPolicy; KeyNm [ Patient :{ Doctor1, Patient, Nurse} ] PatRecord;

Patient Doctor example Prin Doctor1, Patient, Nurse, Doctor2; KeyNm [ Doctor1 : { Doctor1, Patient } ] DocPolicy; KeyNm [ Patient :{ Doctor1, Patient, Nurse} ] PatRecord; Med_File { DocRecord, PatRecord } patient_file; Notes { PatRecord } med_diary;

Patient Doctor example Prin Doctor1, Patient, Nurse, Doctor2; KeyNm [ Doctor1 : { Doctor1, Patient } ] DocPolicy; KeyNm [ Patient :{ Doctor1, Patient, Nurse} ] PatRecord; Med_File { DocRecord, PatRecord } patient_file; Notes { PatRecord } med_diary; KeyNm [ Doctor2:{ Doctor1, Doctor2 } ] Priv_Notes; Notes { Priv_Notes } budget;

Patient Doctor example Prin Doctor1, Patient, Nurse, Doctor2; KeyNm [ Doctor1 : { Doctor1, Patient } ] DocPolicy; KeyNm [ Patient :{ Doctor1, Patient, Nurse} ] PatRecord; Med_File { DocRecord, PatRecord } patient_file; Notes { PatRecord } med_diary; KeyNm [ Doctor2:{ Doctor1, Doctor2 } ] Priv_Notes; Notes { Priv_Notes } budget; Patient { Priv_Notes declassifies PatRecord }; Doctor1 { Priv_Notes declassifies DocRecord };

Talk outline Review: Decentralized Label Model (DLM) Review: Decentralized Label Model (DLM) –Local Access Control Key Based Decentralized Label Model (KDLM) Key Based Decentralized Label Model (KDLM) –Distributed Access Control and Cryptography The Jeddak Language The Jeddak Language Conclusions Conclusions

Papers “Typed Based Distributed Access Control”, CSFW 03 “Typed Based Distributed Access Control”, CSFW 03 - KDLM model - KDLM model - Type system and correctness. - Type system and correctness. “Principals, Policies and Keys in a Secure Distributed Programming Language”, FCS 04 “Principals, Policies and Keys in a Secure Distributed Programming Language”, FCS 04 - Types for sending keys. - Types for sending keys. - Language examples - Language examples “The Jeddak Language”, Hopefully when it’s finished. “The Jeddak Language”, Hopefully when it’s finished.

Further Work Finish off Jeddak. Finish off Jeddak. Running code. Running code. Accountability. Accountability.

Related Work Information flow and type systems Information flow and type systems –Denning –Volpano and Smith –Pottier (Flow Caml) –Gordan and Fourient Information flow and access control Information flow and access control –Stoughton –Heintze and Riecke, –Myers, Liskov (DLM) –Myers, Zdancewic (JIF) –Banerjee and Naumann Types and security protocols Types and security protocols –Abadi –Gordon and Jeffreys –Pierce and Li –Duggan (Crypto Types)

Summary KDLM for Distributed Access Control KDLM for Distributed Access Control Benefit of Type-Based Approach: Access Checking at compile-time Benefit of Type-Based Approach: Access Checking at compile-time –Lightweight access control for accountable systems –Extended to “compile-time” crypto

Questions?