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 and Robbert van Renesse.

2. Servers Client Fault-tolerance by Replication The “fine print” … • Replica failures are independent. • Replica coordination protocol exists. • No secrets stored in server’s state.

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. • Replica Coordination protocol exists. • No secrets stored in server’s state.

5. Revisiting the “Fine Print” • Replica failures are independent. • But attacks are not independent. • Replica Coordination protocol exists. • No secrets stored in server’s state.

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 • No secrets stored in server’s state.

7. 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 • No secrets stored in server’s state. • But secrets cannot be avoided for authentication • Replicating a secret erodes confidentiality.

8. Compromised Components Correct component satisfies specification. Compromised component does not. • Adversary might control a compromised component. • Component is compromised if adversary knows secrets being stored there. A recovery protocol transforms component: compromised  correct

9. Component Correlation Components are correlated to the extent that one attack suffices to compromise all. Correlation arises from: • Dependence on the environment • Vulnerabilities in shared design / code • Shared secrets Goal: Eliminate sources of correlation.

10. Correlation:Environment Vulnerabilities Vulnerabilities = Assumptions • Weaker assumptions are better. • “Synchronous system” assumption: • Bounded message delivery delay • Bounds on process execution speed • violated by denial of service attacks • needed for “agreement protocols” in deterministic systems [FLP]

11. Correlation > Towards Weaker Assumptions:Eschewing Synchronous Systems Asynchronous system model is weaker but requires making “sacrifices”: • 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. Component Correlation Correlation arises from: • Dependence on environment • Vulnerabilities in shared design / code • Shared secrets

13. Correlation:Eschewing Shared Design / Code Solution: Diversity! • Expensive or impossible to obtain: • Development costs • Interoperability risks Still, what diversity does exist should be leveraged.

14. Correlation > Leveraging Extant Diversity:Adversary Structures t-resilience: Service is not compromised unless more than t components are. • Known as a threshold structure. FS-resilience: If FS = {F1, F2, … Fr} then service not compromised provided the set C of compromised components satisfies C  Fi for some i. • Select FS according to dimensions of diversity. • Known as an adversary structure.

15. Component Correlation Correlation arises from: • Dependence on environment • Vulnerabilities in shared design / code • Shared secrets

16. Correlation:Eliminating Shared Secrets • (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. • Can be adapted for arbitrary adversary structures. • Threshold cryptography: • Perform cryptographic operations piecewise using shares of private key; result is as if private key was used. Example: Threshold digital signatures

17. Proactive Recovery When is recovery protocol run? • After an attack is detected. • Not sufficient to reboot from good system image. • Must get system state (or have stateless service). • Must also “refresh” secrets. • Periodically, even if an attack is not detected. • Not all attacks are detected, proactive recovery defends against undetected attacks. • Adversary strategy: Increase the window of vulnerability, interval between proactive recovery executions.

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. Proactive Recovery > Secret Refresh:Refresh Private / Public Keys I Approach: Tamper proof hardware. • Key material stored in tamper-resistant hw. • Key cannot be read or modified. • Attacker can still instigate crypto operations with key. Protocols must accommodate such possible rogue behavior.

20. Proactive Recovery > Secret Refresh:Refresh Private / Public Keys II Approach: Use off-line private keys. • New public keys are propagated through a secure out-of-band channel. • Use off-line private keys to sign the new public keys. • Components storing off-line keys can be connected to network using a one-way channel (e.g. “pump”).

21. Proactive Recovery:Transparency and Change I Scalability concerns dictate that clients be shielded from changes due to proactive recovery. • Service public / private key: • Proactive secret sharing changes private key shares without changing private key (or public key). • Server identities: • A single contacted server operates as a delegate. • Service key signs responses to client. • Self-verifying messages impede rogue delegates from spoofing as clients.

22. Proactive Recovery:Transparency and Change II • Server public keys. If client must know… • Local certificate: • <Server name, New server public key, Epoch number> • Signed by server using server’s off-line key • Global certificate: • Local certificate signed by service private key • Service signs only if local signature on certificate is valid • Use t+1 threshold crypto for service signature • Stored at 2t+1 servers. (Out of 3t+1) • Client obtains current public key for server i: • Retrieve global certificate for all servers from 2t+1 servers • epoch numbers in t+1 sets will be the same---that is current

23. Research Programme Trajectory • Cornell On-line Certification Authority (COCA) • Asynchronous Proactive Secret Sharing (APSS) • Distributed Blinding Protocol • Codex Secret Store Key ideas: • Weak computational models (asynchronous) • Thresholdization [sic] / “multi-party computation” • Proactive protocols (vs Transparency)