Date post: | 03-Jan-2016 |
Category: |
Documents |
Upload: | cecilia-woods |
View: | 214 times |
Download: | 0 times |
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
Institute for Security Technology Studies, Dartmouth College 3
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
Institute for Security Technology Studies, Dartmouth College 4
Logic-based approach
Inferenceengine
Authorization Server
?grant(Bob)
TRUE
Knowledgebase
Proof Tree
Rules
Facts
Institute for Security Technology Studies, Dartmouth College 5
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)
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
• 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
Institute for Security Technology Studies, Dartmouth College 10
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)
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
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
Institute for Security Technology Studies, Dartmouth College 13
Capability-based revocation
H0
H3
H2
H1
c3
Positive KB
owner(bob, pda11), c2
loc(pda11, hospital), c3
Positive KB
loc(bob, hospital), c1
c1
Institute for Security Technology Studies, Dartmouth College 14
Semantics of revocation
Positive KB
Negative KB
Revocationhandler
loc(Bob,room12), C1
Host A
Host B
loc(Alice,room12), C2
C1
Institute for Security Technology Studies, Dartmouth College 15
Semantics of revocation
Positive KB
Negative KB
Revocationhandler
Host A
Host B
loc(Alice,room12), C2
C2
Institute for Security Technology Studies, Dartmouth College 16
Semantics of revocation
Positive KB
Negative KB
Revocationhandler
Host A
Host B
loc(Alice,room12), C2
We cannot use thesame capability
c2
Adversary
Institute for Security Technology Studies, Dartmouth College 17
Semantics of revocation
Positive KB
Negative KB
Revocationhandler
Host A
Host B
Adversary
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 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
Institute for Security Technology Studies, Dartmouth College 22
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 processing
With TDESencryption
Institute for Security Technology Studies, Dartmouth College 23
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 processing
Exclude latency for initial queries
Institute for Security Technology Studies, Dartmouth College 24
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 processing
All the policies and factsin a single host
Institute for Security Technology Studies, Dartmouth College 25
Latency for revoking cached information
Cluster
Testdriver
queryhost0 host1 hostn
. . . EventGenerator
Event
Revocation messages
Notification
• Measure round-trip latency of a revocation message
Institute for Security Technology Studies, Dartmouth College 26
Latency for revoking cached information
Depth of a proof tree and #hosts
Late
ncy
(ms)
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
• 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
Institute for Security Technology Studies, Dartmouth College 34
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
Institute for Security Technology Studies, Dartmouth College 35
Measurements for revoking cached information
Cluster
Testdriver
queryhost0 host1 hostn
. . . EventGenerator
Event
Revocation messages
Notification
• Measure round-trip latency of a revocation message
Institute for Security Technology Studies, Dartmouth College 36
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