Trustworthy Servicesfrom Untrustworthy Components:

Overview

Fred B. SchneiderDepartment of Computer Science

Cornell UniversityIthaca, 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.

Servers

Client

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 server’s 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:– Adversary’s ability to compromise

depends on time available.- versus -– Adversary’s 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

Correlation:

Eschewing Shared Design / Code

Solution: Diversity! Expensive or impossible to obtain:

• Development costs• Interoperability risks

Still, what diversity does exist should be leveraged.

12

Correlation:

Avoiding 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

Obfuscator

Random key:0110101100… System

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

15

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

16

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

17

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.

18

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.

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

21

Research Programme Trajectory

Cornell On-line Certification Authority (COCA)

Asynchronous Proactive Secret Sharing (APSS)

Codex Secret Store Distributed Blinding Protocol