Lightweight Consistency Enforcement Schemes for Distributed Proofs with Hidden Subtrees Adam J. Lee, Kazuhiro Minami, and Marianne Winslett University of Illinois at Urbana-Champaign June 21,

1 Knowledge base Knowledge base Knowledge base Knowledge base P0P0 P1P1 P2P2 P3P3 Distributed proof system  Construct a proof in a peer-to-peer way  Each peer maintains local security policies

2 P0P0 P1P1 P2P2 P3P3 Distributed proof system  Construct a proof in a peer-to-peer way  Each peer maintains local security policies

3 Security policies Security policies Security policies Security policies P0P0 P1P1 P2P2 P3P3 Distributed proof system  Construct a proof in a peer-to-peer way  Each peer maintains local security policies domain Adomain B domain d domain C

4 P0P0 P1P1 ?grant(alice, database) true √ Querier P2P2 P3P3 ?location(alice, hospital) ?role(alice,doctor) true Location server Role server Distributed proof system  Construct a proof in a peer-to-peer way  Each peer maintains local security policies

5 Policy Directed Proof Construction Integrity trust Confidentiality trust

6 Policy Directed Proof Construction Confidentiality trust

7 Projector Room 2124 Temporal Consistency Issue in Distributed Proving Show medical records if only Alice is in the room and the door is locked. Access control policy

8 Consistency Issue in Distributed Proving P0P0 P1P1 P2P2 ?occupancy_one(2124, alice) P3P3 Location server Door sensor ?grant(alice, projector) Alice Bob Door (open) Time: T 1 true Room 2124 Alice

9 Consistency Issue in Distributed Proving P0P0 P1P1 P2P2 ?occupancy_one(2124, alice) P3P3 Location server Door sensor ?grant(alice, projector) AliceBob Door (locked) Time: T 2 true Room 2124

10 Consistency Issue in Distributed Proving P0P0 P1P1 P2P2 ?occupancy_one(2124, alice) P3P3 ?locked(2124) Location server Door sensor ?grant(alice, projector) Bob Time: T 3 true Alice Door (locked) √ Medical records

11 Incremental evaluation of fact validity may not be enough Only Aice in room 2124 Door locked √ T1T1 T2T2 √ T3T3

12 View Consistency Problem  How to enforce temporal consistency based on the local view of a querier?  Challenges: The validity of a statement fluctuates dynamically No clock synchronization across different hosts Possible hidden subproof from a querier

13  View V is a set of fact states  Fact state s is a tuple that contains fact id time interval Interval type: {Concrete, Fuzzy} Concrete: fact f is valid all the times t in the interval Fuzzy: fact f is valid at some (possibly unknown) time in the interval View and fact state

14 Three Levels of View Consistency Incremental consistency Query consistency Interval consistency View V Restrictiveness

15  Each fact provider returns a pair (f, d) where d is the duration of fact’s validity Enforcement Algorithm for Query Consistency QuerierFact provider

16  Each fact provider returns a pair (f, d) where d is the duration of fact’s validity Enforcement Algorithm for Query Consistency QuerierFact provider

17  The algorithm of query consistency could miss lots of valid proofs if proof construction takes long  May want to keep track of authorization continuously Motivation towards Interval Consistency Enforcement

18  The algorithm of query consistency could miss lots of valid proofs if proof construction takes long  May want to keep track of authorization continuously Motivation towards Interval Consistency Enforcement first responder

19 Approach for Interval Consistency QuerierFact provider Query True Verify True Fuzzy interval Fuzzy interval Concrete interval  Recheck the validity of a constructed proof

20 Goals for Interval Consistency Enforcement  Recheck the validity of a proof efficiently  Preserve security policies of each peers Querier Proof 1. construct2. verify Querier Sub-proof Leaf node entities

21 Leaf Node Exposure Strategy  Recheck fact validity directly with leaf node entities √

22 Leaf Indirection Strategy  To preserve the privacy of leaf node entities, recheck fact validity by way of a trusted indirection entity

23 Evaluation  Measure overhead latency for enforcing interval consistency  System consists of 12,500 lines of Java code Java Cryptographic Extension framework to implement RSA and TDES operations  25 node cluster with 100Mbit Ethernet

24 Latency for Handling Queries Number of nodes in a proof tree Latency (ms) Leaf indirection Leaf exposure Proof construction % overhead

25 Latency for Handling Queries Number of nodes in a proof tree Latency (ms) Leaf indirection Leaf exposure Proof construction % overhead

26 Related Work  View consistency in automatic trust negotiation [Lee06]  Antigone Context Framework [McDaniel03]  Transaction management in distributed systems  Consistent snapshots [Chandy85]

27 Summary  Formal definitions of view consistency in distributed proving  Safe and efficient enforcement algorithm  Modest overhead of our enforcement scheme for interval consistency

28 Technical report: Questions?

29 Backup

30 Peer-to-Peer Proof Construction Query Subproof Peer Query Subproof  Each peer consists of an inference engine and a knowledge base  Each peer constructs a part of a whole proof

31 Distributed Proof Construction Algorithm by Minami and Kotz  Use Datalog as a logical language  Express trust among principals in terms of integrity and confidentiality Querier Handler Correctness of an answer (integrity) Secrecy of facts (confidentiality)

32 Remote Query between Two principals Host A Host B grant(P, projector)  location(P, room112) ?location (Bob, room112) Integrity Policies trust(location(P,L)) = {Host_B} TRUE request User Bob Confidentiality Policies acl(location(P,L)) = {Host_A} F 1  owner(bob, pda15) F 2  deviceAt(pda15, room112) R  location(P,L)  owner(P,D)  deviceAt(D,L) R F1F1 F2F2 Proof tree

33 Enforcement of Confidentiality Policies

34 Hidden Leaf Nodes Transparent from Hidden leaf nodes  Leaf nodes transparent from the original querier  Example:

35 Requery Strategy  Construct the same proof twice  Need caching at intermediate nodes  Involves high communication overhead Cache

36  Each fact provider returns a pair (f, d) where d is the duration of fact’s validity Enforcement Algorithm for Query Consistency QuerierFact provider Query Proof where  is the maximum clock drift f’s validity duration