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

Last talk on the subject ended like this…

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

Protocol Fragment – Common Syntax

Protocol fragment – Procedural Language Initialization Party AParty B

Protocol Fragment – Dependency Graph

Protocol Fragment – Dependency Graph (+ Control Dependencies)

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

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

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

Transformations – Specification

Find the corresponding sub-graph and replace it Applying the transformation

“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

 - Analysis Finding  : when A  B? – If A  B – If A = …  B  … – If B = …  A  … – If A  C and C  B – If B = C 1  …  C n and A  C i for all i – If A = C 1  …  C n and C i  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

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

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 ) )

Representing 

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

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 = C 1  …  C n and C i NAND B for all i then A NAND B The goal is to derive A NAND A – then A can be replaced with  /false

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

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

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:

Introducing I-node Introduction: for each RS-node R, add – I ( OK ( R ), R ) Propagation: if there is I ( X  ( C 1  …  C n  OK ( V ) ), R ), and V 1,…, V k 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  ( C 1  …  C n  OK ( V 1 ) )  … ( C 1  …  C n  OK ( V k ) )  ( C 1  …  C n  C’’ 1  OK ( V ) )  … ( C 1  …  C n  C’’ k’’  OK ( V ) ), R )

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 Using the I-Node

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