Model Checking for Security Anupam Datta CMU Fall 2009 18739A: Foundations of Security and Privacy.

Slides:



Advertisements
Similar presentations
Tintu David Joy. Agenda Motivation Better Verification Through Symmetry-basic idea Structural Symmetry and Multiprocessor Systems Mur ϕ verification system.
Advertisements

University of Twente The Netherlands Centre for Telematics and Information Technology Verification of Security Protocols Sandro Etalle
University of Twente The Netherlands Centre for Telematics and Information Technology Constraint Logic Programming for Verifying Security Protocols Sandro.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
ECE454/CS594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011.
Lecture 3Dr. Verma1 COSC 6397 – Information Assurance Module M2 – Protocol Specification and Verification University of Houston Rakesh Verma Lecture 3.
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
Timed Automata.
CS259: Security Analysis of Network Protocols Overview of Murphi Arnab Roy.
Automated Analysis of Cryptographic Protocols Using Murphi Mingchen Zhao University of Pennsylvania.
CSE331: Introduction to Networks and Security Lecture 22 Fall 2002.
Luu Anh Tuan. Security protocol Intruder Intruder behaviors Overhead and intercept any messages being passed in the system Decrypt messages that are.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Probabilistic Model Checking CS 395T. Overview uCrowds redux uProbabilistic model checking PRISM model checker PCTL logic Analyzing Crowds with PRISM.
 Public key (asymmetric) cryptography o Modular exponentiation for encryption/decryption  Efficient algorithms for this o Attacker needs to factor large.
CS555Spring 2012/Topic 161 Cryptography CS 555 Topic 16: Key Management and The Need for Public Key Cryptography.
Modelling and Analysing of Security Protocol: Lecture 3 Protocol Goals Tom Chothia CWI.
Analysis of Security Protocols (I) John C. Mitchell Stanford University.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
Analysis of Security Protocols (IV) John C. Mitchell Stanford University.
Overview of Cryptography Anupam Datta CMU Fall A: Foundations of Security and Privacy.
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering.
Modelling and Analysing of Security Protocol: Lecture 1 Introductions to Modelling Protocols Tom Chothia CWI.
More on AuthenticationCS-4513 D-term More on Authentication CS-4513 Distributed Computing Systems (Slides include materials from Operating System.
EEC 688/788 Secure and Dependable Computing Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
Slide 1 Vitaly Shmatikov CS 378 Key Establishment Pitfalls.
Protocol Composition Logic Arnab Roy joint work with A. Datta, A. Derek, N. Durgin, J.C. Mitchell, D. Pavlovic CS259: Security Analysis of Network Protocols,
Model Checking for Security Anupam Datta CMU Fall A: Foundations of Security and Privacy.
Progress Report on Java Based Protocol Analysis Presented by Stephen W. Mancini, 1Lt, USAF/AFIT Robert P. Graham, MAJ, USAF/AFIT Presentation date: 09.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
Security Analysis of Network Protocols TECS Week Reference: John Mitchell Stanford 2005.
Inductive Verification of Protocols Anupam Datta CMU Fall A: Foundations of Security and Privacy.
Cryptography and Network Security Chapter 11 Fifth Edition by William Stallings Lecture slides by Lawrie Brown.
Programming Satan’s Computer
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
8-1Network Security Chapter 8 roadmap 8.1 What is network security? 8.2 Principles of cryptography 8.3 Message integrity, authentication.
Executable specification of cryptofraglets with Maude for security verification Fabio Martinelli and Marinella Petrocchi IIT-CNR, Pisa Italy presented.
Formal Analysis of Security Protocols Dr. Changyu Dong
Analysis of a Fair Exchange Protocol Vitaly Shmatikov John Mitchell Stanford University.
Security protocols  Authentication protocols (this lecture)  Electronic voting protocols  Fair exchange protocols  Digital cash protocols.
CS6133 Software Specification and Verification
Design and Analysis of Security Protocols Vitaly Shmatikov CS 395T
Fall 2010/Lecture 321 CS 426 (Fall 2010) Key Distribution & Agreement.
CSCE 813 Internet Security Cryptographic Protocol Analysis.
Correctness Proofs and Counter-model Generation with Authentication-Protocol Logic Koji Hasebe Mitsuhiro Okada Department of Philosophy, Keio University.
Lecture 5.2: Key Distribution: Private Key Setting CS 436/636/736 Spring 2012 Nitesh Saxena.
6 June Lecture 2 1 TU Dresden - Ws on Proof Theory and Computation Formal Methods for Security Protocols Catuscia Palamidessi Penn State University,
CS 395T Game-Based Verification of Contract Signing Protocols.
Security Analysis of Network Protocols Vitaly Shmatikov SRI CS 259 John Mitchell Stanford.
Security Protocols Vitaly Shmatikov CS Security Protocols  Use cryptography to achieve some higher-level security objective Authentication, confidentiality,
Network Protocols Network Systems Security Mort Anvari.
Lecture 5.1: Message Authentication Codes, and Key Distribution
Project: XML Security CS 259 March, 2004 Jun Yoshida (Visiting Scholar from Hitachi Ltd.)
This Week Lecture on relational semantics Exercises on logic and relations Labs on using Isabelle to do proofs.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Lecture 9 Overview. Digital Signature Properties CS 450/650 Lecture 9: Digital Signatures 2 Unforgeable: Only the signer can produce his/her signature.
Lesson Introduction ●Authentication protocols ●Key exchange protocols ●Kerberos Security Protocols.
@Yuan Xue CS 285 Network Security Key Distribution and Management Yuan Xue Fall 2012.
Pertemuan #8 Key Management Kuliah Pengaman Jaringan.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Security Analysis of Network Protocols
Security Analysis of Network Protocols
Security Protocols Analysis
Man in the Middle Attacks
CDK4: Chapter 7 CDK5: Chapter 11 TvS: Chapter 9
Security Analysis of Network Protocols
CDK: Chapter 7 TvS: Chapter 9
‘Crowds’ through a PRISM
Protocol Verification by the Inductive Method
Formal Methods for Security Protocols
Presentation transcript:

Model Checking for Security Anupam Datta CMU Fall A: Foundations of Security and Privacy

This Lecture 1. Building network protocols using cryptographic primitives from last lecture 2. Overview of model checking 3. Model checking security protocols using the Murphi tool

Authenticating over an untrusted network  How can Alice use cryptography to send an authenticated message to Bob over an untrusted network?  What is authentication?  What can go wrong? 3

Protocols from the class 4

A’s reasoning: The only person who could know NonceA is the person who decrypted 1 st message Only B can decrypt message encrypted with Kb Therefore, B is on the other end of the line B is authenticated! Authentication by Encryption AB A’s identityFresh random number generated by A B’s reasoning: The only way to learn NonceB is to decrypt 2 nd message Only A can decrypt 2 nd message Therefore, A is on the other end A is authenticated! Kb { NonceB} Ka { NonceA, NonceB } Kb { A, NonceA } [Needham- Schroeder 1978]

What Does This Protocol Achieve? AB Kb { NonceB} Ka { NonceA, NonceB } Kb { A, NonceA }  Protocol aims to provide both authentication and secrecy  After this exchange, only A and B know NonceA and NonceB

B can’t decrypt this message, but he can replay it Anomaly in Needham-Schroeder AB { A, Na } Kc C { A, Na } Kb { Na, Nc } Ka { Na, Nc } Ka { Nc } Kb Evil agent B tricks honest A into revealing C’s private value Nc C is convinced that he is talking to A! [published by Lowe 1995] Evil B pretends that he is A

Lessons of Needham-Schroeder  Classic man-in-the-middle attack  Exploits participants’ reasoning to fool them  A is correct that B must have decrypted {A,Na} Kb message, but this does not mean that {Na,Nb} Ka message came from B  The attack has nothing to do with cryptography!  It is important to realize limitations of protocols  The attack requires that A willingly talk to adversary  In the original setting, each workstation is assumed to be well- behaved, and the protocol is correct!  Wouldn’t it be great if one could discover attacks like this automatically?

NS Initiator as a State Machine  State machine (S, s 0, ,  ) where  S: set of states  s 0 :initial state   : set of actions   : transition relation  : S x   S 9 I_SLEEP sendmsg1 I_WAIT I_COMMIT receivemsg2

This Lecture 1. Building network protocols using cryptographic primitives 2. Overview of model checking 3. Model checking security protocols using the Murphi tool

Model Checking  Algorithm for checking properties about behaviors of finite state machines  Given a state machine M and a property , does M satisfy   ?  Discovered independently by Clarke & Emerson and Queille & Sifakis in Turing Award to Clarke, Emerson & Sifakis

Models: Doubly Labeled State Machines pp;q a a b c d e M  ( M ) = { a;b;c;d;e;f } AP = { p;q;r } q;r alphabet propositions Typically, models of systems are manually created

Property 1: Safety  p and r are never true at the same time: G (  ( p  r) )  pp;q a a b c d e q;r YES! Safety: “Nothing bad happens” More relevant for security: secrecy, authentication, order of system calls (MOPS) Model checking is a graph search problem

Property 2: Liveness  Whenever p holds, a happens some time in the future: G ( p  F a )  pp;q a a b c d e q;r Liveness: “Something good eventually happens”

Query 2: Liveness  Whenever p holds, a happens some time in the future: G ( p  F a )  pp;q ac d e q;r NO! counterexample Counterexample useful for diagnostics

2007 Turing Award Citation “ This verification technology provides an algorithmic means of determining whether an abstract model--representing, for example, a hardware or software design--satisfies a formal specification expressed as a temporal logic formula. Moreover, if the property does not hold, the method identifies a counterexample execution that shows the source of the problem. … As a result many major hardware and software companies are now using Model Checking in practice. Examples of its use include the verification of VLSI circuits, communication protocols, software device drivers, real-time embedded systems, and security algorithms.” 16

Model Checking: Pros and Cons  Pros:  Fully automated  Fast (relative to similar rigorous methods)  Counterexample useful for diagnostics Cons  No correctness proof  Applies to finite model (though some exceptions)  State space explosion (many techniques to address) : Introduction to Model Checking

This Lecture 1. Building network protocols using cryptographic primitives 2. Overview of model checking 3. Model checking security protocols using the Murphi tool

Big Picture Intruder Model Checker Formal Protocol Informal Protocol Description Find error Specify Property RFC, IETF draft, research paper…

Making the Model Finite  Two sources of infinite behavior  Many instances of participants, multiple runs  Message space or data space may be infinite  Finite approximation  Assume finite number of participants  For example, 2 clients, 2 servers  Mur phi is scalable: can choose system size parameters  Assume finite message space  Represent random numbers by constants r1, r2, r3, …  Do not allow encrypt(encrypt(encrypt(…)))

Applying Murphi to Security Protocols  Formulate the protocol  Define a datatype for each message format  Describe finite-state behavior of each participant  If received message M3, then create message M4, deposit it in the network buffer, and go to state WAIT  Describe security condition as state invariant  Add adversary  Full control over the “network” (shared buffer)  Nondeterministic choice of actions  Intercept a message and split it into parts; remember parts  Generate new messages from observed data and initial knowledge (e.g., public keys) Mur  will try all possible combinations

NS Initiator as a State Machine  State machine (S, s 0, ,  ) where  S: set of states  s 0 :initial state   : set of actions   : transition relation  : S x   S 22 I_SLEEP sendmsg1 I_WAIT I_COMMIT receivemsg2

Big Picture  should hold in all states Wait|Sleep|Sleep Wait|Sleep|OneIntercepted Commit|Commit| Sleep … Sleep|Sleep|Sleep …       Wait|Wait|Sleep  Ini:SendMsg1 Res:ReceiveMsg1 Int:Intercepts Each state of the system is a combination of the state of initiator, responder and intruder

Data structures const NumInitiators: 1; -- number of initiators NumResponders: 1; -- number of responders … type InitiatorId: scalarset (NumInitiators); InitiatorStates: enum{I_SLEEP, I_WAIT, I_COMMIT}; Initiator: record state: InitiatorStates responder: AgentId end; var ini: array [InitiatorId] of Initiator Scalable model

Messages and network MessageType : enum { -- types of messages M_NonceAddress, -- {Na, A}Kb nonce and addr M_NonceNonce, -- {Na,Nb}Ka two nonces M_Nonce -- {Nb}Kb one nonce }; Message : record source: AgentId; -- source of message dest: AgentId; -- intended destination of msg key: AgentId; -- key used for encryption mType: MessageType; -- type of message nonce1: AgentId; -- nonce1 nonce2: AgentId; -- nonce2 OR sender id OR empty end; var net: multiset[NetworkSize] of Message; -- state variable for n/w

States in NS (S, s 0, ,  )  var -- state variables for  net: multiset[NetworkSize] of Message; -- network  ini: array[InitiatorId] of Initiator; -- initiators  res: array[ResponderId] of Responder; -- responders  int: array[IntruderId] of Intruder; -- intruders 26

Initial State in NS (S, s 0, ,  )  startstate  -- initialize initiators  undefine ini;  for i: InitiatorId do  ini[i].state := I_SLEEP;  ini[i].responder := i;  end;  -- initialize responders  -- make all responder states R_SLEEP  -- initialize intruders  -- make all intruder stored nonces empty  -- initialize network  undefine net;  end; 27

Actions in NS (S, s 0, ,  )  Actions in Murphi model of NS update the state variables  multisetadd (outM,net); -- add message to the network  res[i].state := R_WAIT; -- change responder state 28

Transition Relation in NS (S, s 0, ,  )  Transition relation for protocol steps (honest parties)  Transition relation for adversary steps 29

Modeling Protocol Actions ruleset i: InitiatorId do ruleset j: AgentId do rule 20 "initiator starts protocol" ini[i].state = I_SLEEP & !ismember(j,InitiatorId) & multisetcount (l:net, true) var outM: Message; -- outgoing message begin undefine outM; outM.source := i; outM.dest := j; outM.key := j; outM.mType := M_NonceAddress; outM.nonce1 := i; outM.nonce2 := i; multisetadd (outM,net); ini[i].state :=I_WAIT; ini[i].responder := j; end; end;end;

Adversary Model  Formalize “knowledge”  initial data  observed message fields  results of simple computations

Modeling the attacker -- intruder i sends recorded message ruleset i: IntruderId do -- arbitrary choice of choose j: int[i].messages do -- recorded message ruleset k: AgentId do -- destination rule "intruder sends recorded message" !ismember(k, IntruderId) & -- not to intruders multisetcount (l:net, true) < NetworkSize ==> var outM: Message; begin outM := int[i].messages[j]; outM.source := i; outM.dest := k; multisetadd (outM,net); end; end;

Modeling Properties of NS invariant "responder correctly authenticated" forall i: InitiatorId do ini[i].state = I_COMMIT & ismember(ini[i].responder, ResponderId) -> res[ini[i].responder].initiator = i & ( res[ini[i].responder].state = R_WAIT | res[ini[i].responder].state = R_COMMIT ) end;

Murphi [Dill et al.]  Describe finite-state system  State variables with initial values  Transition rules for each protocol participant & attacker  Communication by shared variables  Specify security condition as a state invariant  Predicate over state variables that must be true in every state reachable by the protocol  Automatic exhaustive state enumeration  Can use hash table to avoid repeating states  Research and industrial protocol verification

Limitations  System size with current methods  2-6 participants Kerberos: 2 clients, 2 servers, 1 KDC, 1 TGS  3-6 steps in protocol  Adversary model  Cannot model randomized attack  Do not model adversary running time

Try Playing With Murphi  You’ll need to use Murp hi for your first homework  The input language is easy to understand, but ask us if you are having problems  Simple IF… THEN… guarded commands  Attacker is nondeterministic

Homework #1 (Using Murphi)  Investigate the NS flaw and the fixed Needham Schroeder Lowe protocol  Investigate conditions under which attack succeeds: adversary power, initiator behavior and crypto (malleable encryption)  Investigate version rollback attack on SSL protocol

Announcements  Form groups and send to Arunesh with your group members  Homework 1 out next Tuesday (due in 2 weeks)

Questions?