Downloaded 57 times
Uploaded byCloudflare
Running Secure Server Software on Insecure Hardware Without Parachute
Nicholas Sullivan discusses the security challenges of running server software on globally distributed edge servers with insecure physical access. He argues for a new approach that distinguishes between long-term and short-term secrets, with the goal of refreshing secrets before attackers can compromise them. Short-term secrets use techniques from digital rights management like white-box cryptography and code obfuscation to impose computational costs on extracting secrets from memory. Long-term secrets are not stored on edge servers and are accessed through short-term secrets.
More Related Content
Similar to Running Secure Server Software on Insecure Hardware Without Parachute
Running Secure Server Software on Insecure Hardware Without Parachute
- 1. Nicholas Sullivan Systems Engineer CloudFlare @grittygrease RunningSecure Server Software on Insecure Hardware without a Parachute
- 2. What this talkis about u The web is changing — consolidation at the edge u Fundamental assumptions about server security are wrong u How do we design server software with the worst case in mind? u Distinguish between long and short term secrets u Devise approaches for protecting each 2
- 3. Let’s Talk AboutWeb Infrastructure
- 4.
- 5.
- 6. Global Website Trafficwith CDN 6
- 7.
- 8.
- 9.
- 10.
- 11. Traditional server threatmodel u Assume server is secure u Add layers of protection to keep attackers out u Network layer protection u Operating System Level: principle of least privilege u Protection against maliciously installed code u More advanced barriers 11
- 12. Globally distributed servers uLess jurisdictional control = less physical security u Physical access trumps static defense layers ! u Traditional defenses helpful, but not ideal u Cannot rely on security of keys u Single break-in results in immediate compromise 12
- 13.
- 14. Approach system securitythe ‘DRM way’ u Assume attacker has bypassed all static defenses u Goal is to refresh secrets before they are compromised u Split system into long-term secrets and short-term secrets u Focus on renewability of secrets 14
- 15. Secrets must besplit into two tiers u Long-term Secrets u Useful for attacker for long period of time u Do not store at the edge ! u Short-term Secrets u Expire after a short period of time u Cannot be re-used 15
- 16. Example: Traditional TLStermination u TLS handshake with nginx and Apache u SSL keys on disk u Read from disk, use in memory ! u Cryptographic elements at risk if server is compromised u Private key u Session key 16
- 17. TLS revisited foruntrusted hardware u Long term secrets u Private key ! u Short term secrets u Session key u Session IDs and Session ticket keys u Credentials to access private keys 17
- 18. How to Protect Short-term Secrets
- 19. Short-term secrets —threat model u Must live on machines in unsafe locations u Memory u Control Flow u By the time a secret is broken, it should be expired u Don’t keep secrets in a useable state u Impose computational cost to retrieve the original secret u Expire secrets quickly ! 19
- 20. Techniques from DRMare applicable u White-box cryptography u Code obfuscation 20
- 21. Standard Cryptography ThreatModel 21 Alice Bob Eve
- 22. White-box Cryptography ThreatModel 22 Alice Bob Eve
- 23. White-box Cryptography ThreatModel 23 Aleve Bob
- 24. White-box cryptography u Hidethe cryptographic key from everyone u Protect against key extraction in the strongest threat model ! u Takes time to extract key — lots of math u Choose difficulty based on secret lifetime 24
- 25. White-box cryptography implementations 25 uCommercial products u Irdeto, Arxan, SafeNet, etc. u Open source u OpenWhiteBox
- 26.
- 27. Code obfuscation u Makingreverse engineering difficult u Compile-time control-flow modification u Data transformation in memory u Anti-debugging 27
- 28.
- 29.
- 30. Code obfuscation implementations uCommercial products u Arxan, Irdeto, etc. u Open source u Obfuscator-LLVM 30
- 31.
- 32. Keyless SSL u SSLwithout keys? Surely you’re joking. u SSL without keys at the edge. That’s better. 32
- 33. How Keyless SSLWorks u Split the TLS state machine geographically u Perform private key operation at site owner’s facility (in HSM, etc) u Perform rest of handshake at edge u Communicate with signing server over mutually authenticated TLS 33
- 34.
- 35.
- 36.
- 37. Conclusion u Untrusted hardwarerequires a new approach u Split secrets into long-term and short-term u Design for rapid renewal — replace secrets faster than they can be broken u Leverage short-term secrets to access long-term secrets 37