Scalability in a Secure Distributed Proof System

1. Scalability in a Secure Distributed Proof System Kazuhiro Minami and David Kotz May 9, 2006 Institute for Security Technology Studies Dartmouth College

2. Context-sensitive authorization • Consider a requester’s context (e.g., location) to make an authorization decision • Support unregistered users • Non-intrusive access to resources Context information Granting decision (TRUE or FALSE) Request Authorization system Institute for Security Technology Studies, Dartmouth College

3. Emergency response system Request Access is granted if a requester is located at the scene, and holds the role ``firefighter.’’ Context-sensitive authorization policy First responder Situation monitor server Critical incident Responder assistance Institute for Security Technology Studies, Dartmouth College

4. Logic-based approach ?grant(Bob) Rules TRUE Facts Proof Tree Inference engine Knowledge base Authorization Server Institute for Security Technology Studies, Dartmouth College

5. Secure distributed proof system[Minami and Kotz 2005] Authorization Query • Protect confidential rules and facts in each host • Proof decomposition on multiple hosts • Each host returns an encrypted result (or subproof) Sub-Proof Tree Host A Logical Query Sub-Proof Tree Sub-Proof Tree Host B Host C Institute for Security Technology Studies, Dartmouth College

6. Performance consideration • Handling a query could involve long latency • Cryptographic operations • Transmission of data over a network • Can we build a practical system with reasonable performance? Institute for Security Technology Studies, Dartmouth College

7. Caching and revocation • Speed • Reduce average latency for handling a query • Freshness • Keep cached information fresh • Fault tolerance • Not give unauthorized access based on stale cached information Institute for Security Technology Studies, Dartmouth College

8. Caching mechanism • In many pervasive applications, users access a same resource continuously • Can avoid issuing subsequent queries with caching • Support both positive and negative caching Institute for Security Technology Studies, Dartmouth College

9. Positive and negative caching ?loc(Bob, room12) TRUE • A fact that is proven goes to the positive KB. loc(Bob,room12) Inference engine Positive KB Host B Negative KB Host A Institute for Security Technology Studies, Dartmouth College

10. Positive and negative caching ?loc(Alice, room12) FALSE • A fact that is not provable is stored in the negative KB. loc(Bob,room12) Inference engine Positive KB Host B loc(Alice,room12) Negative KB Host A Institute for Security Technology Studies, Dartmouth College

11. Capability-based revocation • Some facts in a proof are dynamic • Multiple hosts can revoke cached information • A query result contains a capability (random number) • Each host maintains dependencies among local and remote facts Institute for Security Technology Studies, Dartmouth College

12. Capability-based revocation ?owner(bob, pda11) (TRUE, c2) ?loc(bob, hospital) (TRUE, c1) ?loc(pda11, hospital) (TRUE, c3) loc(bob, hospital), c1 owner(bob, pda11), c2 loc(pda11, hospital), c3 Positive KB Positive KB H2 H0 H1 H3 Institute for Security Technology Studies, Dartmouth College

13. Capability-based revocation c1 c3 H2 H0 H1 H3 loc(bob, hospital), c1 owner(bob, pda11), c2 loc(pda11, hospital), c3 Positive KB Positive KB Institute for Security Technology Studies, Dartmouth College

14. Semantics of revocation C1 loc(Bob,room12), C1 Revocation handler Positive KB Host B loc(Alice,room12), C2 Negative KB Host A Institute for Security Technology Studies, Dartmouth College

15. Semantics of revocation C2 Revocation handler Positive KB Host B loc(Alice,room12), C2 Negative KB Host A Institute for Security Technology Studies, Dartmouth College

16. Semantics of revocation We cannot use the same capability c2 Adversary loc(Alice,room12), C2 Revocation handler Positive KB Host B Negative KB Host A Institute for Security Technology Studies, Dartmouth College

17. Semantics of revocation Adversary Revocation handler Positive KB Host B Negative KB Host A Institute for Security Technology Studies, Dartmouth College

18. Additional measures for revocation • Establish a secure channel for sending revocation messages • Generate a new capability for switched cached information Institute for Security Technology Studies, Dartmouth College

19. Evaluation • Is our system scalable to a large number of servers? • Does our revocation mechanism keep cached information fresh? Institute for Security Technology Studies, Dartmouth College

20. Experiment to measure latency for handling a query • Measure latency for handling a query whose proof spans across 27 different hosts in a cluster. Institute for Security Technology Studies, Dartmouth College

21. Comparison of latency for handling a query 3000 No caching with RSA No caching with TDES Cold caching Warm caching Local processing 2500 With RSA public-key encryption 2000 1500 Latency (ms) 1000 500 0 0 5 10 15 20 25 30 35 40 45 50 Number of nodes in a proof tree Institute for Security Technology Studies, Dartmouth College

22. Comparison of latency for handling a query 3000 No caching with RSA No caching with TDES Cold caching Warm caching Local processing 2500 2000 1500 Latency (ms) With TDES encryption 1000 500 0 0 5 10 15 20 25 30 35 40 45 50 Number of nodes in a proof tree Institute for Security Technology Studies, Dartmouth College

23. Comparison of latency for handling a query 3000 No caching with RSA No caching with TDES Cold caching Warm caching Local processing 2500 2000 1500 Latency (ms) Exclude latency for initial queries 1000 500 0 0 5 10 15 20 25 30 35 40 45 50 Number of nodes in a proof tree Institute for Security Technology Studies, Dartmouth College

24. Comparison of latency for handling a query 3000 No caching with RSA No caching with TDES Cold caching Warm caching Local processing 2500 2000 1500 Latency (ms) All the policies and facts in a single host 1000 500 0 0 5 10 15 20 25 30 35 40 45 50 Number of nodes in a proof tree Institute for Security Technology Studies, Dartmouth College

25. Latency for revoking cached information Event query Test driver Revocation messages Notification • Measure round-trip latency of a revocation message Event Generator . . . host0 host1 hostn Cluster Institute for Security Technology Studies, Dartmouth College

26. Latency for revoking cached information Latency (ms) Depth of a proof tree and #hosts Institute for Security Technology Studies, Dartmouth College

27. Summary • Novel caching and revocation mechanisms for a secure distributed proof system • Positive and negative caching that minimize the number of remote queries • Recursive revocation in a distributed environment • The amortized performance of our system scales to dozens of servers Institute for Security Technology Studies, Dartmouth College

28. Thank you! • Fore related papers http://www.cs.dartmouth.edu/~minami • For other projects in our group http://cmc.cs.dartmouth.edu Institute for Security Technology Studies, Dartmouth College

29. Extra slides Institute for Security Technology Studies, Dartmouth College

30. Semantics of negative revocation • A revoked negative fact moves to the positive KB • Cannot reuse the same capability • A revocation message must contain a new capability encrypted with a secret key. Institute for Security Technology Studies, Dartmouth College

31. Implementation • 12,000+ lines of code in Java • based on XProlog (3,800 lines of code) • Java Cryptographic Extension (JCE) • RSA public-key operations • key length: 1024 bits • public exponent: 65537 • MD5 for signing • TDES symmetric-key operations • Outer-CBC in EDE mode • key length: 192 bits (3 keys) Institute for Security Technology Studies, Dartmouth College

32. Crypto. parameters • RSA public-key operations • key length: 1024 bits • public exponent: 65537 • EME-PKCS1-v1_5 padding method • MD5 for signing • TDES operations • key length: 192 bits (3 keys) • Outer-CBC in EDE mode Institute for Security Technology Studies, Dartmouth College

33. Experiment of measuring latency for handling a query #nodes in a proof rules & facts KB KB KB KB KB KB Policy Generator host host • 27-node (2.8GHz Intel XEONs) cluster with Gigabit Ethernet • Java Runtime version1.5.0 on RedHat Linux 9 Institute for Security Technology Studies, Dartmouth College

34. Experiment of measuring latency for handling a query KB KB KB KB KB KB Events query Test driver proof 20 events per second for each fact host Event Generator host 10 sets of 10 different queries Institute for Security Technology Studies, Dartmouth College

35. Measurements for revoking cached information Event query Test driver Revocation messages Notification • Measure round-trip latency of a revocation message Event Generator . . . host0 host1 hostn Cluster Institute for Security Technology Studies, Dartmouth College

36. Related Work • Context-sensitive authorizationsystems [Al-Muhtadi03, Bacon02, Covington01, Hulsebosch05, Kapadia04, Males03] • Centralized architecture • Distributed logic system [Ranganathan03] • No caching • Caching in a distributed logic system [Bauer05,Katsire03] • No revocation mechanism Institute for Security Technology Studies, Dartmouth College