Modeling LEAP+ and µ TESLA in MCMAS and AVISPA

1. Modeling LEAP+ and µTESLA in MCMAS and AVISPA Ryan Tanner Dr. Rakesh Verma Model Checking and Formal Verification MCMAS and AVISPA Our Results • Model checking is used to verify the properties of communications protocols. However, it can only prove a flaw exists, it cannot prove a protocol correct. • Formal verification provides for an exhaustive exploration of all possible behaviors of agents in a system. • A protocol design is first converted into a formalism and then a specification which must state the properties the system must satisfy. This specification is then verified through an exhaustive search of all possible states of a system: A → B : A.Na B → A : B.MAC(Kb,B.Na) • This is the protocol for pairwise key establishment in LEAP+, a key management protocol for sensor networks. It uses different keying mechanisms for different types of communications. • µTESLA is an authentication protocol for broadcast streams, allowing receivers to verify senders. • Model checking was first brought to the forefront by Gavin Lowe when he found a subtle replaying attack in the Needham-Schroeder Public Key protocol, which went unnoticed for almost twenty years. • • MCMAS and AVISPA are two tools used for the formal verification of security protocols. • • MCMAS is a symbolic model checker that verifies specifications including requirements on time, knowledge and correct behavior. • • MCMAS represents systems as a set of ordered binary decision diagrams, which it compares to find violations of security properties. • • AVISPA has been used to find vulnerabilities in a large number of protocols and is well suited to the traditional Alice-Bob notation used in describing protocols. The previous example in AVISPA for agent A: • 0. State = 0 /\ RCV(start) =|> • State':= 2 /\ Na' := new() • /\ SND(A.Na’) /\ witness(A,B,alice_bob_a,A) • /\ witness(A,B,alice_bob_ni,Na’) • /\ witness(A,B,alice_bob_ni,Ni) • State = 2 /\ RCV(B.{A.B'}_H(Ni.Ki)) =|> • State':= 4 /\ wrequest(A,B,bob_alice_a,A) • /\ wrequest(A,B,bob_alice_b,B’) • /\ Kab' := F(Ki,B) • /\ Kca' := new() /\ SND({Kca'}_Kab’) • /\ witness(A,B,alice_bob_kca,Kca') • • AVISPA lacks functionality to model temporal properties, which required us to abstract many details of these protocols. MCMAS has these capabilities but we have not yet created a successful model. • The LEAP+ protocol for adding a node to the network dictates that the new node send its identity and a nonce to a neighbor. ATTACK TRACE i -> (a,3): start (a,3) -> i: a.dummy_nonce i -> (b,7): i.x263 (b,7) -> i: b.{mac(x263.b)}_(h(km.b)) i -> (a,3): b.{mac(x263.b)}_(h(km.b)) • In this attack, the intruder replays messages from A and B, but does not gain knowledge of any confidential keys or messages. • Most of the attacks we found are of this nature and as such not serious. • We recommend that HELLO messages be authenticated to prevent this. • While we cannot prove that LEAP+ is secure with this method, we have not found any serious flaws as of yet. • Using MCMAS we attempted to model these protocols as well but have so far been unsuccessful. • As these tools mature we believe we can better model LEAP+ and µTESLA We would like to thank the NSF for supporting this research via grant number 0755500