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

Scalability in a Secure Distributed Proof System

Kazuhiro Minami and David Kotz

May 9, 2006

Institute for Security Technology StudiesDartmouth College

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

Authorizationsystem

RequestGranting decision (TRUE or FALSE)

Context information


Emergency response system

Firstresponder

Situationmonitor server

Request

Responder assistance

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Critical incident

Access is granted if a requester is located at the scene, and holds the

role ``fire fighter.’’

Context-sensitiveauthorization policy


Logic-based approach

Inferenceengine

Authorization Server

?grant(Bob)

TRUE

Knowledgebase

Proof Tree

Rules

Facts


Secure distributed proof system [Minami and Kotz 2005]

Host A

Host BHost C

Sub-ProofTree

Sub-ProofTree Sub-Proof

Tree

AuthorizationQuery

LogicalQuery

• Protect confidential rules and facts in each host

• Proof decomposition on multiple hosts

• Each host returns an encrypted result (or subproof)


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?


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


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


Positive and negative caching

• A fact that is proven goes to the positive KB.

Positive KB

Negative KB

Inferenceengine

?loc(Bob, room12)

TRUE

loc(Bob,room12)

Host A

Host B


Positive and negative caching

• A fact that is not provable is stored in the negative KB.

Positive KB

Negative KB

Inferenceengine

?loc(Alice, room12)

FALSE

loc(Bob,room12)

Host A

Host B

loc(Alice,room12)


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



H0

H3

H2

H1

?loc(bob, hospital)

(TRUE, c2)

(TRUE, c3)

?owner(bob, pda11)

?loc(pda11, hospital)

(TRUE, c1)

Positive KB

owner(bob, pda11), c2

loc(pda11, hospital), c3

Positive KB

loc(bob, hospital), c1



H0

H3

H2

H1

c3

Positive KB

owner(bob, pda11), c2

loc(pda11, hospital), c3

Positive KB

loc(bob, hospital), c1

c1


Semantics of revocation

Positive KB

Negative KB

Revocationhandler

loc(Bob,room12), C1

Host A

Host B

loc(Alice,room12), C2

C1



Positive KB

Negative KB

Revocationhandler

Host A

Host B


C2



Positive KB

Negative KB

Revocationhandler

Host A

Host B


We cannot use thesame capability

c2

Adversary



Positive KB

Negative KB

Revocationhandler

Host A

Host B

Adversary


Additional measures for revocation

• Establish a secure channel for sending revocation messages

• Generate a new capability for switched cached information


Evaluation

• Is our system scalable to a large number of servers?

• Does our revocation mechanism keep cached information fresh?


Experiment to measure latency for handling a query

• Measure latency for handling a query whose proof spans across 27 different hosts in a cluster.


Comparison of latency for handling a queryL

ate

nc

y (m

s)

Number of nodes in a proof tree

0 5 10 15 20 25 30 35 40 45 50

3000

2500

2000

1500

1000

500

0

No caching with RSANo caching with TDES

Cold cachingWarm caching

Local processingWith RSApublic-keyencryption



ate

nc

y (m

s)


0 5 10 15 20 25 30 35 40 45 50

3000

2500

2000

1500

1000

500

0



Local processing

With TDESencryption



ate

nc

y (m

s)


0 5 10 15 20 25 30 35 40 45 50

3000

2500

2000

1500

1000

500

0



Local processing

Exclude latency for initial queries



ate

nc

y (m

s)


0 5 10 15 20 25 30 35 40 45 50

3000

2500

2000

1500

1000

500

0



Local processing

All the policies and factsin a single host


Latency for revoking cached information

Cluster

Testdriver

queryhost0 host1 hostn

. . . EventGenerator

Event

Revocation messages

Notification

• Measure round-trip latency of a revocation message


Latency for revoking cached information

Depth of a proof tree and #hosts

Late

ncy

(ms)


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


Thank you!

• Fore related papers http://www.cs.dartmouth.edu/~minami

• For other projects in our group http://cmc.cs.dartmouth.edu


Extra slides


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.


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)


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


Experiment of measuring latency for handling a query

• 27-node (2.8GHz Intel XEONs) cluster with Gigabit Ethernet• Java Runtime version1.5.0 on RedHat Linux 9

host

host

PolicyGenerator

KB

KB

KB

KB

KB

KB

#nodesin a proof

rules&

facts


Experiment of measuring latency for handling a query

Testdriver

query

host

host

EventGenerator

KB

KB

KB

KB

KB

KBproof

Events

20 events per secondfor each fact

10 sets of10 different queries


Measurements for revoking cached information

Cluster

Testdriver

queryhost0 host1 hostn

. . . EventGenerator

Event

Revocation messages

Notification

• Measure round-trip latency of a revocation message


Related Work

• Context-sensitive authorization systems [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

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

Documents

room12host ahost blocalice

c1host ahost blocalice

proof tree05

proof spans

room12host ahost bpositive

cached informationevaluationis

comparison of latency

querymeasure latency