How to hack cryptographic protocols with Formal Methods
1 like293 views
The document discusses using formal methods and model checking to analyze the security of cryptographic protocols. It presents a mutual authentication protocol as an example. Model checking involves defining a system as a finite-state machine model and then exhaustively checking all possible behaviors against security properties to identify vulnerabilities. The document demonstrates analyzing the example protocol using the AVISPA and Tamarin Prover tools, finding an attack on the original protocol but not on an updated version. It also discusses more advanced techniques like model learning and comparing learned models to specifications.
How to hack cryptographic protocols with Formal Methods
- 1. HOW TO HACK CRYPTOGRAPHIC PROTOCOLS WITH FORMAL METHODS Ofer Rivlin 1
- 2. 2 Step Alice-Bob Notation Description 1 A -> B: {Na.A}_Kb A sends a message to B with a Nonce Na + its identity. The message is encrypted using Kb which is B’s public key 2 A <- B: {Na.Nb}_Ka B returns a message to A with Na and with Nb - a new nonce by B. The message is encrypted using Ka which is A’s public key 3 A -> B: {Nb}_Kb A proves its identity by returning Nb to B. The message is encrypted using Kb which is B’s public key A mutual authentication protocol The nonce data are secrets that are shared between A & B How do we know if this protocol is safe?
- 3. • Intro • My background, scope, goals & subject of this presentation • The problem • The suggested solution • A few words on Formal Methods & Model Checker • Analysis tools demos • Avispa & Tamarin Prover • Advanced attacks/analysis • Summary AGENDA 3
- 5. • Lead the product security at CyberArk • 10 years of cybersecurity experience • 10 years of experience as a software developer and architect • 3 years of Formal Methods experience in development tools for Provable Software • Passionate about cutting edge technology and cybersecurity! MY BACKGROUND 5 • Ofer Rivlin • ofer.rivlin@cyberark.com • https://www.linkedin.com/in/ofer-rivlin/ • Twitter: @0xriv3r
- 6. • FSM (Finite State Machine) models for understanding the behavior of systems such as security protocols • Model Checking - for analyzing the finite-state models • (not to be confused with Model Learning) • Stay at high level • level of familiarity with the subject • recognize the benefits of using formal methods when designing/hacking cryptographic protocols PRESENTATION SCOPE 6
- 8. 8 Step Alice-Bob Notation Description 1 A -> B: {Na.A}_Kb A sends a message to B with a Nonce Na + its identity. The message is encrypted using Kb which is B’s public key 2 A <- B: {Na.Nb}_Ka B returns a message to A with Na and with Nb - a new nonce by B. The message is encrypted using Ka which is A’s public key 3 A -> B: {Nb}_Kb A proves its identity by returning Nb to B. The message is encrypted using Kb which is B’s public key A mutual authentication protocol The nonce data are secrets that are shared between A & B IS THIS PROTOCOL SAFE?
- 9. • the Needham-Schroeder (Roger Needham & Michael Schroeder) Public Key protocol (1978) • Mutual authentication with public keys (using a trusted key server) • The MITM attack was published by Gavin Lowe, by using a model checker in 1996 (Link), 18 years later! THE NEEDHAM SCHROEDER PUBLIC KEY PROTOCOL 9
- 10. 10
- 11. 11 Step Alice-Bob Notation Description 1 A -> B: {Na.A}_Kb 2 A <- B: {Na.Nb.B}_Ka Instead of: A <- B: {Na.Nb}_Ka in the first version The intruder cannot successfully replay the message (step 4 in the attack) because A is expecting a message containing the identity of i whereas the message will have identity of B 3 A -> B: {Nb}_Kb THE FIX
- 12. 12 Roger Needham: Cryptography protocols are three line programs that people still manage to get wrong
- 13. 13 3 LINE PROGRAMS? TLS 1.3 COMPONENTS – IS THIS SAFE?
- 14. 14 3 LINE PROGRAMS? TLS 1.3 (DOWNGRADE PROTECTION) – IS THIS SAFE?
- 15. 15 THE SOLUTION
- 16. Detect design vulnerabilities that can lead to logical attacks GOAL – TO PREVENT LOGICAL ATTACKS 16
- 17. 17 THE PROCESS Define the system’s specs using a modeling language (Formal- mathematical syntax) Define a set of theorems about the behavior of a system
- 19. • This is a complex techiqe that requires a steep learning curve • Used in complex, Safety Critical Systems • Where exponential growth in possible state space in complex systems that need to be evaluated WHY FORMAL VERIFICATION THROUGH MODEL CHECKING? 19
- 20. WHAT IS A MODEL CHECKER? 20
- 21. 21
- 22. 22 Dr. Strange: I went forward in time to view alternate futures. To see all the possible outcomes of the coming conflict. Peter Quill: How many did you see? Dr. Strange: Fourteen million six hundred and five. Tony Stark: How many did we win? Dr. Strange: ...One.
- 23. 23 Model Checker: I tried all alternate paths. To see all the possible outcomes of this model. Hacker: How many did you see? Model Checker: Fourteen million six hundred and five. Hacker: How many can we exploit? Model Checker: ...One.
- 24. 24 Model Checker: I tried all alternate paths. To see all the possible outcomes of this model. Protocol Designer (Thanos): How many did you see? Model Checker: Fourteen million six hundred and five. Protocol Designer (Thanos): How many are exploitable? Model Checker: ...One.
- 25. • Coverage: exhaustive exploration of all possible behaviors • Verify each behavior against the required theorems through mathematical proofs • Can verify systems that are not finite space, using abstraction • Provide a counter example, i.e. a Fault Trace MODEL CHECKER GOALS 25
- 26. • Assumption: The intruder is an Insider! • Intruder has full control over the network • Intruder can play role(s) of (honest/normal) principals • Knows all the public data of the network • Possible actions: • Start any number of parallel protocol sessions • Intercept any message • Generate new messages, using observed data and initial knowledge (e.g. public keys) DOLEV-YAO INTRUDER MODEL 26
- 27. • Assumption: the cryptography is secure! • Intruder cannot break cryptography • Intruder cannot encrypt/decrypt messages if s/he doesn't have the key • Intruder cannot guess a secret key or a nonce * we check only the protocol’s logic ** we assume the cryptography, random, etc. are secure DOLEV-YAO INTRUDER MODEL 27
- 29. 29 AVISPA DEMO
- 30. GOOGLE SAML SINGLE SIGN ON VULNERABILITY 30
- 32. DEMO - PROTOCOL SIMULATION
- 33. DEMO - ATTACK SIMULATION
- 37. COOPERATIVE INTELLIGENT TRANSPORTATION SYSTEMS (CITS) detect insider attacks based on attacker behavior V2X Revocation Protocol
- 38. ANALYSIS WITH RESPECT TO SECURITY PROPERTIES •Example: •For every execution, if action a2 occurs then action a1 must previously have occurred •Authentication property, for instance: •if agent A receive a message, and agent B send that message, then the authentication property is that A’s receipt of the message guarantees that B sent it • i.e., it was not spoofed by the adversary • every execution satisfies this property
- 39. ORDER FOR SELF REVOCATION REQUEST & RESPONSE - R-TOKEN
- 40. R-TOKEN SCHEME
- 41. 41 DEMO - ATTACK SIMULATION
- 43. • Model Learning: • (‘active automata learning’ or ‘protocol state fuzzing’) • building finite-state models from observed input–output data on implementations • An example • Java Secure Socket Extension: • a model was learned for Java version 1.8.0.25. • Found out that the model contained two parallel paths of application data transistions: • a TLS protocol run + another unexpected run • Possible attack: • the client and server would think they are talking on a secure connection, where in reality they are talking on an open connection • (A fix was released as part of a critical security update) MODEL LEARNING 43
- 44. POSSIBLE CONNECTIONS BETWEEN MODEL LEARNING & MODEL CHECKING 44
- 45. 45 SECURITY ANALYSIS OF LEARNED MODEL Model Learning
- 46. 46 COMPARE LEARNED MODEL TO SPECS MODEL conformance testing tool (CT) conformance testing (Provable Software - mbt)
- 47. • Learned FSM for Win8 TCP Client-Server • Computed by a model checker • Red transition = nonconformance to the RFC • In a {Close + RCV call pending} state, can generate a RST instead of a Fin even in cases where there is no data to be received • Models composition enable analysis between different components (i.e. Win client with Linux Server, etc.) EXAMPLE: TCP ON WIN8 47
- 48. 48 TCP RFC
- 49. 49 SUMMARY
- 50. Analysis of cryptographic protocols using formal methods and model checkers is very complex, and requires a steep learning curve. But Security protocols are excellent candidates for rigorous analysis techniques because they are: • Critical components of any distributed security architecture • Very difficult to evaluate by hand • Deceptively simple looking • the literature is full of protocols that appear to be secure but have subsequently been found to fall prey to some subtle attack, sometimes years later. SUMMARY 50
- 51. THANK YOU! Ofer Rivlin ofer.rivlin@cyberark.com https://www.linkedin.com/in/ofer-rivlin/ Twitter: @0xriv3r 51
- 52. • Fiterău-Broştean, Janssen, Vaandrager: Combining model learning and model checking to analyze TCP implementations (2016). Springer • {J.Whitefield, Liqun.Chen, S.Schneider, H.Treharne, S.Wesemeyer}@surrey.ac.uk: "Formal Analysis of V2X Revocation Protocols" • https://pdfs.semanticscholar.org/6658/591533a5a41d88af1bbb112591645c0f61e0.pdf • https://tools.ietf.org/html/rfc793 • https://www.kb.cert.org/vuls/id/612636 • http://people.irisa.fr/Thomas.Genet/span/ • https://tamarin-prover.github.io REFERENCES 52