Trustworthy Services
from Untrustworthy Components:
Overview
Fred B. Schneider
Department of Computer Science
Cornell University
Ithaca, New York 14853
U.S.A.
Joint work with Lidong Zhou, Microsoft Research
Fault-tolerance by Replication
Servers
The basic recipe …
Client



Servers are deterministic state
machines. Clients make requests.
Server replicas run on distinct hosts.
Replica coordination protocol exists.
1
Trustworthy Services
A trustworthy service…
– tolerates component failures
– tolerates attacks
– might involve confidential data
N.b. Cryptographic keys must be kept confidential
and are useful for authentication, even when data
is not secret.
2
Revisiting the “Fine Print”

Replica failures are independent.
– But attacks are not independent.
3
Revisiting the “Fine Print”

Replica failures are independent.
– But attacks are not independent.

Replica Coordination protocol exists.
– But such protocols involve assumptions, and
assumptions are vulnerabilities.
 Timing assumptions versus Denial of Service
 Non-assumption: Asynchronous System Model.
4
Revisiting the “Fine Print”

Replica failures are independent.
– But attacks are not independent.

Replica Coordination protocol exists.
– But such protocols involve assumptions, and
assumptions are vulnerabilities.
 Timing assumptions versus Denial of Service
 Non-assumption: Asynchronous System Model.

No secrets stored in server’s state.
– But secrets cannot be avoided for authentication
 Replicating a secret erodes confidentiality.
5
Compromised Components
Correct component satisfies specification.
Compromised component does not.
– Caused by failure or attack.
– Adversary might control a compromised
component.
 Adversary learns secrets stored at compromised
component. These might allow other componets to
be compromised.
E.g. Cryptographic keys to support secure channels.
6
Proactive Recovery
recovery protocol: transforms component
compromised  correct
– Defends against undetected failures/attacks.
 tolerates t compromises over lifetime
- versus -
 tolerates t compromises in window of vulnerability
X
X
X
X X X
X
X
7
Nature of the Adversary
Denial of Service attacks can lengthen a
window of vulnerability.
Possible restriction on adversary power:
– Adversary’s ability to compromise depends on
time available.
- versus – Adversary’s ability to compromise depends on
intrinsic aspects of servers.
8
Independence Caveat
C is correlated with C’ in proportion to the
extent that single failures or attacks cause
both C and C’ to be compromised.
Source of correlation:
– Vulnerabilities in design or code
– Assumptions about the environment
9
Correlation:
Eschewing Shared Design / Code
Solution: Diversity!
 Expensive or impossible to obtain:
• Development costs
• Interoperability risks
Still, what diversity does exist should be
leveraged.
10
Correlation:
Avoiding Code Vulnerabilities

Random key:
0110101100…
– Rearrange code blocks and
variables.
– Different replicas have
different vulnerabilities.
– Replicas change their
vulnerabilities over time.
System
Obfuscator

server replica
Idea: Proactively reobfuscate server code
Challenges:
– State recovery
– Protect Obfuscator
– Mask outages
11
Replica Coordination Caveat
Asynchronous system model is weaker, so requires
making “sacrifices” [FLP] for implementing
replica coordination:
– Sacrifice determinacy:
 Use “randomized protocols” (requires randomness)
– Sacrifice liveness but preserve safety.
– Sacrifice state machine replication
 Use quorums or other weaker mechanisms.
 Some service semantics cannot be implemented.
12
Caveat about Secrets: Keys
Client expects equivalent responses from t+1
servers to each request.
– Authentication of server responses needed.
 Digital signatures or other crypto secrets required.
– Authentication secrets changed by proactive recovery.
– Infeasible to notify clients of changes.
Servers
Client
13
Transparency:
Service Key versus Server Keys
t+1 servers speak for the service.
Desire
– Any set of t+1 servers can cooperate to sign
a response.
– No set of t or fewer servers can contrive to
sign a response.
Client accepts response “signed by service”.
14
Transparency:
Implementing Service Key

(n,t) secret sharing
[Shamir, Blakley]:
– Secret s is divided into n shares.
– Any t or more shares suffice for reconstructing s.
– Fewer shares convey no information about s.

Threshold cryptography:
– Perform cryptographic operations piecewise using
shares of private key; result is as if private key was
used.
Example: Threshold digital signatures
15
Transparency:
Defense Against Mobile Adversary
Mobile adversary: Attack, compromise, and
control one replica for a limited time.
– Adversary accumulates shares of secret key.
– Defense: Reshare service’s private key as
part of proactive recovery.
 Create new, independent sharing of service key.
 Replace old shares with new shares.
 Protocol must not materialize service key.
16
Proactive Recovery:
Secret Refresh


Refresh secret shares: PSS and APSS
Refresh symmetric keys:
 Revisit KDC.
 Force new password choices.

Refresh public / private key pairs:
 Invent new server private key
 Must disseminate new server public key.
17
Caveat about Secrets: Data
Secret service data must be stored
cryptographically. Store data using:
– Encryption: Few calculations can be
performed on encrypted data.
– Secret sharing: Expensive to compute and
store shares. Limited repertory of multi-party
computations possible.
18
Distributed Trust:
Summary of Architecture

Asynchronous Model:
– Replica Coordination more difficult.
+Resist denial of service attacks.

Proactive Recovery:
+Limit: Lifetime  Window of vulnerability
 Cryptographic secrets
– Secret service data
19
Research Programme Trajectory




Cornell On-line Certification Authority (COCA)
Asynchronous Proactive Secret Sharing (APSS)
Codex Secret Store
Distributed Blinding Protocol
20