Trustworthy Services from Untrustworthy Components: Overview

1
Trustworthy Servicesfrom Untrustworthy
ComponentsOverview

• Fred B. Schneider
• Department of Computer Science
• Cornell University
• Ithaca, New York 14853
• U.S.A.

Joint work with Lidong Zhou, Microsoft Research
2
Fault-tolerance by Replication

• The basic recipe
• Servers are deterministic state machines. Clients
  make requests.
• Server replicas run on distinct hosts.
• Replica coordination protocol exists.

3
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.

4
Revisiting the Fine Print

• Replica failures are independent.
• But attacks are not independent.

5
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.

6
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 servers state.
• But secrets cannot be avoided for authentication
• Replicating a secret erodes confidentiality.

7
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.

8
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
9
Nature of the Adversary

• Denial of Service attacks can lengthen a window
  of vulnerability.
• Possible restriction on adversary power
• Adversarys ability to compromise depends on time
  available.
• - versus -
• Adversarys ability to compromise depends on
  intrinsic aspects of servers.

10
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

11
CorrelationEschewing Shared Design / Code

• Solution Diversity!
• Expensive or impossible to obtain
• Development costs
• Interoperability risks
• Still, what diversity does exist should be
  leveraged.

12
CorrelationAvoiding Code Vulnerabilities

• Idea Proactively re-obfuscate server code
• Rearrange code blocks and variables.
• Different replicas have different
  vulnerabilities.
• Replicas change their vulnerabilities over time.
• Challenges
• State recovery
• Protect Obfuscator
• Mask outages

System
Random key 0110101100
Obfuscator
server replica
13
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.

14
Caveat about Secrets Keys

• Client expects equivalent responses from t1
  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.

15
TransparencyService Key versus Server Keys

• t1 servers speak for the service.
• Desire
• Any set of t1 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.

16
TransparencyImplementing 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

17
TransparencyDefense Against Mobile Adversary

• Mobile adversary Attack, compromise, and
  control one replica for a limited time.
• Adversary accumulates shares of secret key.
• Defense Reshare services 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.

18
Proactive RecoverySecret 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.

19
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.

20
Distributed TrustSummary 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

21
Research Programme Trajectory

• Cornell On-line Certification Authority (COCA)
• Asynchronous Proactive Secret Sharing (APSS)
• Codex Secret Store
• Distributed Blinding Protocol