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.

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

4. 4
INTRODUCTION

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

7. 7
THE PROBLEM

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

18. 18
FORMAL METHODS

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

28. 28
ANALYSIS TOOLS
DEMOS

29. 29
AVISPA
DEMO

30. GOOGLE SAML SINGLE SIGN ON
VULNERABILITY
30

32. DEMO - PROTOCOL SIMULATION

33. DEMO - ATTACK SIMULATION

34. 34
TAMARIN PROVER
DEMO

35. VANET/V2X REVOCATION PROTOCOL
35

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

42. 42
ADVANCED ATTACKS/ANALYSIS

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