CoDEx: A Robust and Secure
Secret Distribution System
Michael Marsh and Fred Schneider
Summary by GMHoward
Agenda
n Introduction
n System details
¡ Assumptions about the Environment
¡ CODEX Client Interface
¡ CODEX as a Distributed Service
n
n
n
n
Performance Measurements
Related Work
Conclusions
Key Features of CODEX
n Marsh, M. & Schneider, F. (2004). CODEX: A Robust
and Secure Secret Distribution System. IEEE
Transactions on Dependable and Secure Computing,
1(1), 34-47.
1
Lessons to be Learned
(from the Oriental Principles of Gunjan & Foo :)
n An approach to implement a service for
storing and disseminating secrets
n A recipe for building services that are both
fault-tolerant and attack tolerant
¡asynchronous model + proactive secret sharing
+ threshold crypto + byzantine quorum system
n Minimum emphasis will be given to crypto
details
Intro: What is CODEX?
n CODEX: COrnell Data EXchange
n Distributed service for storage and
dissemination of secrets
n Based on COCA (Cornell Online
Certification Authority)
n Originally for archival purposes
(publish/subscribe)
n Implemented in C++
¡No credentials mechanism in place
2
Intro: What is CODEX?
delegate
client
CODEX server farm
client
delegate
delegate
n C-I-A of secret keys is crucial
n Provide support for storing secret keys (encrypt
published objects and authenticate subscribers)
n Server failures must be tolerated and attacks must be
thwarted
Assumptions
about the Environment
n Insecure Links
¡Messages might be disclosed, deleted, altered,
or injected… but there is a link
n Asynchrony
¡Message delivery and server computation times
are unbounded
n Compromised Hosts (Byzantine Failures)
¡Fewer than 1/3 of hosts (running CODEX) fall
under control of adversary at any time
¡Diversity rule: servers are not identical in design
or implementation
3
Assumptions Trade-offs
n CODEX cannot offer real-time guarantees
to clients
¡Availability is eventual
n Tension created between employing
replication and protecting confidentiality
¡Fault-tolerance vs attack-tolerance
¡Many secrets (for clients and servers) are
stored
Key Features of CODEX
n Byzantine Quorum Replication for Fault
Tolerance
¡ Consistency and communication is less than Lamport’s
approach
n Threshold Cryptography
¡ System secret keys are split into shares
n Proactive Recovery (and Proactive Secret
Sharing)
¡ Return servers and secrets to known-safe state
n At-Most-Once Semantics
¡ Keynames and respective owners are uniquely bound
4
CODEX Client Interface (1)
n Three idempotent operations
¡Create – introduces a name
¡Write – associates it to a secret value
¡Read – returns value associated to name
¡Delete does not exist
¡All messages are self validating
Create
Write
l
Confidentiality
l
Integrity
Availability
Read
l
l
l
CODEX Client Interface (2)
n Create – introduces a name
n Fig. 1. Invocation and confirmation messages for a
create operation on behalf of client p, defining a new
name N to have write policy PW (N) and read policy PR(N)
5
CODEX Client Interface (3)
n Write – associates it to a secret value
n Fig. 2. Invocation and confirmation messages for a write
operation by client p intending to associate value s with
name N.
CODEX Client Interface (4)
n Proof that p knows plaintext s (not only E(s))
n Eliminates possible “internal” attack, where:
¡ Message M W(N) is intercepted
¡ Copy E(s) into a write message for new name Nq
¡ Perform read naming Nq (PR (Nq) includes q)
6
CODEX Client Interface (5)
n Read – returns value associated to name
n Fig. 3. Confirmation message for a read must convey the
value val(N) that CODEX binds to a name N, by using a
blinding signature
Agenda
n Introduction
n System details
¡Assumptions about the Environment
¡CODEX Client Interface
¡CODEX as a Distributed Service
n Performance Measurements
n Related Work
n Conclusions
7
CODEX Distributed Service
n Types of protocols implemented
¡Coordinating server replication
¡Securing links
¡Servers and service authentication
Coordinating Server Replicas
n Server replication is employed to ensure
availability
¡Byzantine quorum system stores service state
¡Each operation is implemented as a sequence
of service steps
¡A step involves some quorum of servers
n Service steps and existence of quorums
are hidden from clients
¡Allows periodical change of server crypto keys
¡Use of delegate to hide CODEX internals
8
Coordinating Server Replicas
n Delegate receives invocation messages,
orchestrates execution of operation
(steps), and constructs confirmation
message
¡Clients contact t + 1 delegates
n Optimization to reduce performance
impact
¡Servers cache copies of responses computed
¡Delegates delay before starting, might receive
evidence of confirmation message from another
delegate
Coordinating Server Replicas
delegate
client
CODEX server farm
client
delegate
n Distributed service for storage
delegate
and dissemination of secrets
n 3t + 1 servers
n Quorums of 2t + 1 servers for each service step
n Clients send invocation message to t + 1 delegates
n 1 delegate forward message to 3t + 1 servers
n t servers can be compromised, including a delegate
9
Securing Links
¡Repeated message retransmission is used to
overcome (possible) message loss
lEnded once sender is notified of successful receipt
lCould be directly (from receiver) or indirectly
¡Some protocol steps require that a message be
conveyed to any set comprising AckNo out of 3t
+ 1 servers
¡Confidentiality of message contents =
encryption + (blinding) signature
Authentication (1)
n Each server has a public/private key pair
¡ Shared among all servers (delegates)
n Clients do not know server public keys
¡ Allows for private keys to be changed periodically
without having to inform clients
n There is a common CODEX key pair
¡ Public key is used to stored secrets
¡ Private key is shared by n CODEX servers using an (n, t
+ 1) secret sharing scheme
n Additional shared session key established by
TLS protocol
10
Authentication (2)
n Threshold crypto is used for
¡Generate signatures on confirmation messages
¡Decrypt content previously encrypted under
CODEX public key
n Attacker must know at least t + 1 shares to
construct CODEX private key
¡To defend against mobile virus attacks, APSS
proactive secret sharing protocol is employed
Authentication (3)
delegate
C1
S2
S4
client
CODEX
(n, t+1)
client
S1
delegate
C2
delegate
S3
n Each server has a pair of keys, not shared with clients
n There is also a CODEX key pair, whose private key is share using an (n, t +
1) sharing scheme
n Additional shared session key established by TLS
11
Performance Measurements (1)
n Made for LAN and Internet deployments
n 4 servers
¡1 delegate
¡CODEX Private keys are split to 5 shares
lEach server receives 3 random shares and the
“public” constraint share
¡Encryption: ElGamal
¡Digital Signatures: RSA
¡Public moduli: 1024 bits (both cases)
¡Server communication: TLS v1
Performance Measurements (2)
n Computational (crypto)
costs are normalized to
Tsig
¡ Tsig = cost of performing
one exponientiation with
exponent on the order of
size of public modulus
Message
signing
Partial
Signatures
Partial
Decryption
(s, p)
Verification
Tsig
DLProof
Generation
DLProof
Verification
8Tsig
8Tsig
4Tsig
2.3 Tsig (del)
1.2 Tsig (svr )
11.5Tsig (read)
12
Performance Measurements (3)
delegate
Create
server
9Tsig
Write
12.3Tsig
11.2Tsig
Read
53.3Tsig
33.8Tsig
13
14
Attack-Tolerance Benchmark
n Attacks that increase message latencies between
servers
¡Simulated by modifying binaries to delay message
deliveries
n Attacks that decrease CPU cycles available on
servers
¡Simulated by running additional CPU-intensive
processes
n Clients are never attacked
n Performance measured for create and write
operations
¡Two links were being attacked
¡Read only requires t + 1 servers
Attack that Increases Message
Latencies between Servers
n Threshold signatures in
create and write are
unaffected
n Create is affected
¡ Requires one round of
comm with 2t + 1 servers
n Write is affected, twice
as create
¡ Requires two rounds of
comm with 2t + 1 servers
15
Attack that Decreases CPU
Cycles Available on Servers
n Impact estimation:
¡ Slope for create should
be under 20% of the
baseline time
¡ Slope for write should be
under 40%
n Slopes are somewhat
smaller
¡ Expensive operations
(partial signatures) are
not affected
¡ Process scheduling might
favor server process
Internet Deployment
n Using the PlanetLab overlay network testbed
n Implementation of 1 client and 4 servers
n Measurements are relative to nonidle time, reducing
sensitivity to latencies and scheduling
16
Internet Deployment
n Time to produce a response is longer for
Internet deployment than for LAN
¡Slower connections
¡Processing times also increased, despite
faster processors. Attributed to 50% of
executable code in swap space
Related Work
n E-Vault: structurally similar, but not
intended to distribute secrets
n Fraga and Powel, first intrusion-tolerant
data storage service
n Multicast Key Distribution
n Fault-tolerant KDCs, for credential-issuing
services
n Key Escrow, to store client secrets for
access by third parties
17
Concluding Remarks
n Service key implemented as shared secret
that is proactively refreshed worked well
n Choosing an appropriate service interface
to avoid problems within service
n Surprising that some invocations must
include proofs of plaintext knowledge
n Attack-tolerance approach does not
address vulnerabilities in service
operations, their interfaces, or semantics
Key Features of CODEX
n Byzantine Quorum Replication for Fault
Tolerance
¡ Consistency and communication is less than Lamport’s
approach
n Threshold Cryptography
¡ System secret keys are shared
n Proactive Recovery (and Proactive Secret
Sharing)
¡ Return servers and secrets to known-safe state
n At-Most-Once Semantics
¡ Keynames and respective owners are uniquely bound
18
Questions?
Key Scheme
delegate
C1
S2
S4
client
CODEX
(n, t+1)
client
S1
delegate
C2
delegate
S3
n Each server has a pair of keys, public keys only shared among
servers (not clients)
n There is also a CODEX key pair, whose private key is shared using
an (n, t + 1) sharing scheme
n Additional shared session key established by TLS
19
Example: Create Operation
S2
S1
C1
server
Client p
Delegate D
server
S4
1. Client p send invocation message to
t + 1 delegates
delegate
S3
Example: Create Operation
S2
S1
C1
server
Client p
Delegate D
server
S4
2. Each delegate D determines validity
of MC(N), checks:
A. p is authorized to create name N
B. Signature on message
Delegate D
S3
20
Example: Create Operation
S2
S1
C1
server
Client p
Delegate D
server
S4
3. If preliminary registration exists for
N at D, also checks consistency of
message
A. If doesn’t exist, D stores MC(N) to
Delegate D
S3
create preliminary registration
Example: Create Operation
S2
S1
C1
server
Client p
Delegate D
server
S4
3. If preliminary registration exists for N at
D, also checks consistency of
message
B. If it does exist, D sends cache
corresponding confirmation message
MW(N) and terminates protocol
Delegate D
S3
21
Example: Create Operation
S2
S1
C1
server
Client p
Delegate D
server
S4
4. D forwards MC(N) with nonce n to 3t + 1
servers, awaits acknowledgement
from 2t + 1
Delegate D
S3
Example: Create Operation
S2
S1
C1
server
Client p
Delegate D
server
S4
5. A server determines validity of
message “n, MC(N)” by using validity
tests in steps 2 and 3
A. If message is valid, servers sends an
ACCEPT message, signing MC(N)
Delegate D
S3
22
Example: Create Operation
S2
C1
S1
server
Client p
Delegate D
server
S4
6. If D receives t + 1 REJECT messages,
terminates protocol
7. If D receives 2t + 1 ACCEPT messages,
creates a verified registration for N and
confirmation message (invokes threshold
signature with all servers)
Delegate D
S3
23