Application of dependency graph to security protocol analysis

Ilja Tšahhirov(joint work with Peeter Laud)

Theory Days at Jõulumäe5 Oct 2008

Last talk on the subject ended like this…

The Plan

• Dependency Graphs• Improvements made

Transformation specification analysisNAND-analysisIndependence Analysis

• Conclusion

Protocol Fragment – Common Syntax

Protocol fragment – Procedural Language

Initialization

Party A Party 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-nodesGraph is evaluatedAdversary 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 = 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

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 = C1 … Cn and Ci 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-nodeI ( 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 ( 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 )

If the ancestors of nodes being compared don’t intersect, andone of the nodes depend on adversary, andanother 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