Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
A BSP algorithm for the state space construction of security protocols Frédéric Gava, Michael Guedj, Franck Pommereau Laboratory of Algorithms, Complexity and Logic (LACL) University of Paris-East
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
1 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Security protocols
apparent simplicity but notoriously error-prone need for formal proofs multiple sessions in presence of an attacker discover attacks (man-in-the-middle, replay, . . . )
explicit model-checking automated exhaustive analysis on finite scenarios quick state explosion
need for faster computation, with more memory
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
2 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Protocol example: Otway-Rees
Goal: distribute a fresh shared symmetric key Kab between agents A and B through trusted server S 1
A→B
M, A, B, {Na , M, A, B}Kas
2
B→S
M, A, B, {Na , M, A, B}Kas , {Nb , M, A, B}Kbs
3
S→B
M, {Na , Kab }Kas , {Nb , Kab }Kbs
4
B→A
M, {Na , Kab }Kas
Security requirement: secrecy of Kab
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
3 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Dolev-Yao attacker
1 2
agents send messages to the network spy captures messages learns by recursive decomposition/decryption forges new messages from learnt information using only allowed operations (perfect cryptography)
3
spy delivers messages (including the original one)
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
4 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Otway-Rees: known replay attack
Exploits a typing error: A accepts {M, A, B} as fresh key Kab 1
A → I(B)
M, A, B, {Na , M, A, B}Kas
2
B→S
M, A, B, {Na , M, A, B}Kas , {Nb , M, A, B}Kbs
3
S→B
M, {Na , Kab }Kas , {Nb , Kab }Kbs
4
I(B) → A
M, {Na , M, A, B}Kas
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
5 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Tools: SNAKES and BSP-Python coloured Petri nets for protocol and scenarios models SNAKES (LACL) coloured Petri nets library colour domain = Python language ABCD algebra for protocols send/receive sequences in parallel BSP-Python (CNRS Physic Orleans) BSP library for Python used for global exchanges
LACL cluster ⇒ 40 CPU BSP machine short cycles: algorithm 7→ implementation 7→ benchmarks not efficient but accurate for algorithms comparison
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
6 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
High Level Petri Nets
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
7 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Algebra of High Level Petri Nets (1)
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
8 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Algebra of High Level Petri Nets (2)
communication inter-agent using a buffer (the network) each agent is a sequential process using its own buffers and the network
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
9 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Model of Attacker
Learn is a Python code for dolev-Yao inductives rules ! F. Gava, M. Guedj, F. Pommereau — Lamha 2010
10 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Python ? Are you serious ?
Advantages of Python: untyped and interpreted many efficient data-structures SNAKE In Python
Drawbacks of Python: untyped and interpreted non-deternism on list/set iterations hashing a value is partially machine dependant
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
11 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Labelled transitions systems
initial state s0 successors given by succ(s) transition s → s′ whenever s′ ∈ succ(s) inductive computation of the state space as a graph (explicit LTS) as a set of reachable states
we present sets for simplicity
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
12 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Sequential algorithm
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
todo ← {s0 } known ← ∅ while todo 6= ∅ do pick s from todo known ← known ∪ {s} for s′ ∈ succ(s) do if s′ ∈ / known ∪ todo then todo ← todo ∪ {s′ } end if end for end while
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
13 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Sequential algorithm (2)
1: 2: 3: 4: 5: 6: 7:
todo ← {s0 } known ← ∅ while todo 6= ∅ do pick s from todo known ← known ∪ {s} todo ← (todo ∪ succ(s)) \ known end while
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
14 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Do you truth me ? Is there a bug ?
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
15 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
The Why tools JML-Annotated Java program
Annotated C program
Frama-C
Why program
Krakatoa
Why
Interactive provers (Coq, PVS, Isabelle/HOL, etc.)
Verification Conditions
Automatic provers (Z3, Simplify, Yices, Alt-Ergo, CVC3, etc.)
Annoted programs (small algorithmic/logic language) generated proof obligations for theorem provers need axiomatisation for set/list etc. F. Gava, M. Guedj, F. Pommereau — Lamha 2010
16 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
BSP model
p0 p1 p2 p3 local computations
.. .
.. .
.. .
.. .
communication synchronisation barrier next super-step
Figure: A BSP super-step
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
17 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Building a BSP algorithm
Four steps: 1
start from a naive algorithm
2
improve the locality of computation
3
improve the memory consumption
4
balance computation
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
18 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Naive BSP algorithm
partition function cpu to place states onto processors hash the state (modulo number of processors) most used approach
each processor i computes succ(s) iff cpu(s) = i other states are sent to their owners stop when no processor has computed new states
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
19 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Main loop
1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
todo ← ∅ total ← 1 known ← ∅ if cpu(s0 ) = mypid then todo ← todo ∪ {s0 } end if while total > 0 do tosend ← Successor (known, todo) todo, total ← BSP_Exchange(known, tosend) end while
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
20 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Successor (known, todo) 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
tosend ← ∅ while todo 6= ∅ do pick s from todo known ← known ∪ {s} for s′ ∈ succ(s) do if s′ ∈ / known ∪ todo then if cpu(s′ ) = mypid then todo ← todo ∪ {s′ } else tosend ← tosend ∪ {(cpu(s′ ), s′ )} end if end if end for end while return tosend F. Gava, M. Guedj, F. Pommereau — Lamha 2010
21 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Trying to prove its correctness BSP-WHY, an extension of WHY for BSP algorithms: JML-Annotated BSP Java program
Annotated BSP C program
BSP-Why program
Frama-C+lib
BSP-Why
Krakatoa+lib
Why program
Why
Interactive provers (Coq, PVS, Isabelle/HOL, etc.)
Verification Conditions
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
Automatic provers (Z3, Simplify, Yices, Alt-Ergo, CVC3, etc.)
22 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Problems with naive algorithm
a new state is very likely to be sent no locality of the computations too much communication
protocols yield structured models we can exploit their properties for more efficient algorithms
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
23 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Assumptions about protocol models
1
finite and fixed number of agents
2
states are functions L → D (locations → data)
3
LR ⊆ L defines reception locations
4
succ = succ R ⊎ succ L such that succ L is the identity on LR cpu R such that s1 |LR = s2 |LR ⇒ cpu R (s1 ) = cpu R (s2 )
5
use a hash on LR
⇒ cross-transitions correspond to receptions in the protocol General assumptions, easy to implement
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
24 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Improve local computation while todo 6= ∅ do
pick s from todo Successor (known, todo) : known ← known ∪ {s} for s′ ∈ succ(s) do 1: tosend ← ∅ if s′ ∈ / known ∪ todo then if cpu(s′ ) = mypid then 2: while todo 6= ∅ do todo ← todo ∪ {s′ } else 3: pick s from todo tosend ← tosend ∪ {(cpu(s′ ), s′ )} end if 4: known ← known ∪ {s} end if end for 5: for s′ ∈ succ L (s) \ known do end while 6: todo ← todo ∪ {s′ } 7: end for 8: for s′ ∈ succ R (s) \ known do 9: tosend ← tosend ∪ {(cpu R (s′ ), s′ )} 10: end for 11: end while 12: return tosend
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
25 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Improve memory consumption super-steps match protocols progression (receptions) known states cannot be reached in a future super-step at each super-step, we can dump memory 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
todo ← ∅ total ← 1 known ← ∅ if cpu(s0 ) = mypid then todo ← todo ∪ {s0 } end if while total > 0 do tosend ← Successor (known, todo) dump(known) todo, total ← BSP_Exchange(======= known, tosend) end while F. Gava, M. Guedj, F. Pommereau — Lamha 2010
26 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Balancing the computation 1
efficient parallel computation ⇐⇒ good workload balance
2
number of computed states cannot be anticipated
3
but, related to the number of received states
4
introduce a rebalancing step
while total > 0 do tosend ← Successor (known, todo) 9: dump(known) 10: todo, total ← BSP_Exchange(Balance(tosend)) 11: end while 7: 8:
define cpu B as cpu R for infinitely many processors exchange local histograms of cpu B ⇒ global histogram H balance tosend wrt H (approximate bin packing) F. Gava, M. Guedj, F. Pommereau — Lamha 2010
27 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Methodology
run two scenarios (small and large) for: 1 2 3 4
Needham-Schroeder mutual authentication Yahalom key sharing and mutual authentication with TTP Otway-Rees key sharing with TTP Kao-Chow key sharing and mutual authentication
measure on each processor 1 2 3
local computation time (yellow) synchronisation time, i.e., waiting time (red) communication time (blue)
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
28 / 35
Introduction
State space computation
Needham-Schroeder 90
60
(top)
Benckmarks
Conclusion
and Yahalom (bottom) 9000
sweep-line
80 70
BSP algorithms
8000 7000
naive
6000
50
5000
40
balance
30
4000 3000
20
2000
10
1000
0
0 Algorithm 2
Algorithm 4
Algorithm 5
900
Algorithm 2
Algorithm 4
Algorithm 5
30000
800
computation
25000
700
synchronisation
20000
600 500
communication
15000
400
10000
300 200
5000
100 0
0 Algorithm 2
Algorithm 4
Algorithm 5
Algorithm 2 Algorithm 4 Algorithm 5
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
29 / 35
Introduction
State space computation
Otway-Rees
(top)
BSP algorithms
Benckmarks
Conclusion
and Kao-Chow (bottom)
4000
35000
3500
30000
3000
25000
2500
20000
2000 15000
1500 1000
10000
500
5000
0
0 Algorithm 2
Algorithm 4
Algorithm 5
500 450 400 350 300 250 200 150 100 50 0
Algorithm 2 Algorithm 4 Algorithm 5 8000 7000 6000 5000 4000 3000 2000 1000 0
Algorithm 2
Algorithm 4
Algorithm 5
Algorithm 2
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
Algorithm 4
Algorithm 5 30 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
NS and Yahalom
Scenario NS_1-2 NS_1-3 NS_2-2
Scenario Y_1-3-1 Y_1-3-1_2 Y_1-3-1_3 Y_2-2-1 Y_3-2-1 Y_2-2-2
Naive 0m50.222s 115m46.867s 112m10.206s
Naive 12m44.915s 30m56.180s 481m41.811s 2m34.602s COMM 2m1.774s
Balance 0m42.095s 61m49.369s 60m30.954s
Balance 7m30.977s 14m41.756s 25m54.742s 2m25.777s 62m56.410s 1m47.305s
Nb_states 7807 530713 456135
Nb_states 399758 628670 931598 99276 382695 67937
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
31 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Otway-Rees and Woo and Lam Pi
Scenario OR_1-1-2 OR_1-1-2_2 OR_1-1-2_3 OR_1-2-1
Scenario WLP_1-1-1 WLP_1-1-1_2 WLP_1-1-1_3 WLP_1-2-1 WLP_1-2-1_2
Naive 38m32.556s 196m31.329s 411m49.876s 21m43.700s
Naive 0m12.422s 1m15.913s COMM 2m38.285s SWAP
Balance 24m46.386s 119m52.000s 264m54.832s 9m37.641s
Balance 0m9.220s 1m1.850s 24m7.302s 1m48.463s 55m1.360s
Nb_states 12785 17957 22218 1479
Nb_states 4063 84654 785446 95287 946983
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
32 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Memory consumption for NS, WLP and Y Naive-BSP
Balance 20
50 40
15
30 10 20 5
10 0
0 0
1000
2000
3000
4000
5000
6000
7000
0
1000
Naive-BSP
2000
3000
4000
Balance
100
60
80
50 40
60
30 40
20
20
10
0
0 0
20000
40000
60000
80000
100000
0
500
Naive-BSP
1000
1500
2000
2500
3000
Balance
40
25 20
30
15 20 10 10
5
0
0 0
500
1000
1500
2000
0
200
400
600
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
800
1000
33 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Conclusion BSP algorithms for state space generation exploit structural properties of security protocols to reduce communications anticipate the number of super-steps decrease local storage balance the workload
properties easily computable on Petri net models our algorithm is efficient scalable simple provable
benchmarks on realistic and non-trivial examples
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
34 / 35
Introduction
State space computation
BSP algorithms
Benckmarks
Conclusion
Perspectives
ongoing work new benchmarks of other protocols and scenarios correctness proofs using BSP Hoare logic (BSP-WHY)
future work more complex protocol from SPREAD project LTL/CTL* model checking, exploiting state space locality certified implementation ?
F. Gava, M. Guedj, F. Pommereau — Lamha 2010
35 / 35
