Trustworthy Services from Untrustworthy Components: Overview

1. Trustworthy Servicesfrom 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

2. Servers Client 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 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 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. Servers Client 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.

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