Application of dependency graph to security protocol analysis

1. Application of dependency graph to security protocol analysis Ilja Tšahhirov (joint work with Peeter Laud) Theory Days at Jõulumäe 5 Oct 2008

2. Last talk on the subject ended like this…

3. The Plan • Dependency Graphs • Improvements made Transformation specification  analysis NAND-analysis Independence Analysis • Conclusion

4. Protocol Fragment – Common Syntax

5. Protocol fragment – Procedural Language Initialization Party A Party B

6. Protocol Fragment – Dependency Graph

7. Protocol Fragment – Dependency Graph (+Control Dependencies)

8. Dependency Graph Execution • Initialize the graph node values with /false, • Repeat{ Adversary sets the Req- and Receive-nodes Graph is evaluated Adversary is made aware of the values of Send-nodes } until Adversary indicates to stop • Adversary’s goal in the game is to produce different output depending on the secret message

9. Dependency Graph Evaluation • Node semantics defined as a step function (has to be monotone): • Graph step function is parallel application of all the nodes step functions: • Is also monotone • Has a fixed point • Special value – T – to indicate that something inconsistent has happened. If any node returns it – graph evaluation is stopped

10. Dependency Graph Transformation • Transformations: • Dead code removal • Boolean logic based • Operations semantics based • Cryptographic-primitives-based • Duplicate computations removal • Changing the computations order

11. Transformations – Specification

12. Applying the transformation • Find the corresponding sub-graph and replace it

13. “Global” analyses • Some transformations can be done locally (by just matching the fragment), while the most “fruitful” ones require the analysis of the whole graph • Global transformations: •  - Analysis • Not-AND-Analysis • Independence analysis

14.  - Analysis • Finding  : when A  B? • If A  B • If A = …  B  … • If B = …  A  … • If A  C and C  B • If B = C1  …  Cn and A  Ci for all i • If A = C1  …  Cn and Ci  B for all i • Using  • Simplifying control dependencies • Finding additional invariants (control dependency implies one of the arguments to be equal to some other value) • Simplifying the multiplexors

15. Representing  • Initial idea – parallel structure: • But – there is a way of expressing these relationships using the semantics of the graph, and regular nodes

16. Nodes Needed for Representing the  • Nodes with semantics depending on order of execution • A node before’ ( A, B ) initially equals false, but: • If, after a fix point computation, A=true and B=false, then the node is replaced with true-node; • If, after a fix point computation, B=true, then the node is replaced with false-node • If any of the before’-nodes was replaced with true, the fix-point computation is repeated • T-node. A node T ( A ) equals: • false, if A=false • T, if A=true • Finally: a  node. • (A,B) T( before’ ( A, B ) )

17. Representing 

18. Extending  For Bit String-Nodes • If A and/or B is bit string node, then  is still useful – to express that A being not equal to /false, implies B not being equal to /false • Expressing that A  B: • A – bit string, B – boolean:  ( OK ( A ), B ) • A – boolean, B – bit string:  ( A, OK ( B ) ) • A – bit string, B – bit string :  ( OK ( A ), OK ( B ) ) • Finding A  B: • B is control dependency of (bit string) node A • B is data dependency of (bit string) node A, with strict operation • B is data dependency of (bit string-to-boolean) node A

19. Not-AND (NAND) -Analysis • A NAND B means that at most one of the nodes can be different from /false. • Expressing NAND-relationship: • NAND( A, B )  T (  ( A, B ) ) • For bit string A,B: NAND ( OK ( A ), OK ( B ) ) • Introducing A NAND B • When A or B is false or error-node • When A is IsEq ( C, D ) and B is IsNeq ( C, D ) • Cases following from the cryptographic primitives semantics • Propagating NAND • If A NAND B and C = …  B  … then A NAND C • If A = C1  …  Cn and CiNAND B for all i then A NAND B • The goal is to derive A NAND A – then A can be replaced with /false

20. Independence Analysis • If ancestors of two nodes being compared do not intersect, and one of them is a function of random coins… • Note that it can only be done if the ancestors of second node does not depend on adversary

21. If the second node depends on adversary input • Comparison can not be replaced with false, but there are certain conditions needed for it to return true: • Control dependency of RS-node is true • Control dependency of Send=node is true • The idea is to add those conditions to the comparison node

22. I-node I ( C, R ) – if C is false, the adversary view is independent of R – i.e. if the graph contains fragment … then the adversary cannot determine which of the two random coins is used as a value of R-node, as long as C is false:

23. Introducing I-node • Introduction: for each RS-node R, add • I ( OK ( R ), R ) • Propagation: if there is I ( X  ( C1 …  Cn  OK ( V ) ), R ), and V1,…, Vk are all direct descendants of V, returning bit string, and V’’1,…, V’’k’’ are all send-nodes, with data input V, and control inputs C’’1,…, C’’k’’ • Then the following node can be added: • I ( X  ( C1 …  Cn  OK ( V1 ) )  … ( C1 …  Cn  OK ( Vk ) )  ( C1 …  Cn  C’’1  OK ( V) )  … ( C1 …  Cn  C’’k’’ OK ( V) ) , R )

24. Using the I-Node If the ancestors of nodes being compared don’t intersect, and one of the nodes depend on adversary, and another node is random Add the corresponding I-node to the comparison

25. In closing… • Currently the framework seems to be complete and suitable for experimenting with real protocols (tried it on several well-known protocols, results comply with public knowledge) • Analyser prototype is sufficient for experiments, but its extensibility and usability need to be improved: • It has to be re-implemented according to the new transformation specifications, , NAND, and independent analysis representations • A GUI has to be added