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

2. 1 Fault-tolerance by Replication The basic recipe … l Servers are deterministic state machines. Clients make requests. l Server replicas run on distinct hosts. l Replica coordination protocol exists. Servers Client

3. 2 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. 3 Revisiting the “Fine Print” l Replica failures are independent. –But attacks are not independent.

5. 4 Revisiting the “Fine Print” l Replica failures are independent. –But attacks are not independent. l 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. 5 Revisiting the “Fine Print” l Replica failures are independent. –But attacks are not independent. l Replica Coordination protocol exists. –But such protocols involve assumptions, and assumptions are vulnerabilities.  Timing assumptions versus Denial of Service  Non-assumption: Asynchronous System Model. l No secrets stored in server’s state. –But secrets cannot be avoided for authentication  Replicating a secret erodes confidentiality.

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

9. 8 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. 9 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. 10 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. 11 Correlation: Avoiding Code Vulnerabilities l Idea: Proactively re- obfuscate server code –Rearrange code blocks and variables. –Different replicas have different vulnerabilities. –Replicas change their vulnerabilities over time. l Challenges: –State recovery –Protect Obfuscator –Mask outages Obfuscator Random key: 0110101100… System server replica

13. 12 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. 13 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. 14 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. 15 Transparency: Implementing Service Key l (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. l Threshold cryptography: –Perform cryptographic operations piecewise using shares of private key; result is as if private key was used. Example: Threshold digital signatures

17. 16 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. 17 Proactive Recovery: Secret Refresh l Refresh secret shares: PSS and APSS l Refresh symmetric keys:  Revisit KDC.  Force new password choices. l Refresh public / private key pairs:  Invent new server private key  Must disseminate new server public key.

19. 18 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. 19 Distributed Trust: Summary of Architecture l Asynchronous Model: –Replica Coordination more difficult. +Resist denial of service attacks. l Proactive Recovery: +Limit: Lifetime  Window of vulnerability  Cryptographic secrets –Secret service data

21. 20 Research Programme Trajectory l Cornell On-line Certification Authority (COCA) l Asynchronous Proactive Secret Sharing (APSS) l Codex Secret Store l Distributed Blinding Protocol