CS 395T Game-Based Verification of Contract Signing Protocols.

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Secure Multiparty Computations on Bitcoin
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
UIUC CS 497: Section EA Lecture #2 Reasoning in Artificial Intelligence Professor: Eyal Amir Spring Semester 2004.
CS6133 Software Specification and Verification
UPPAAL Introduction Chien-Liang Chen.
Analysis of optimistic multi-party contract signing Rohit Chadha 1,2, Steve Kremer 3,4, Andre Scedrov 1 1 University of Pennsylvania 2 University of Sussex.
Model Checking Inputs: A design (in some HDL) and a property (in some temporal logic) Outputs: Decision about whether or not the property always holds.
1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for.
Chapter 10 Algorithmic Thinking. Copyright © 2013 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Learning Objectives List the five essential.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Probabilistic Contract Signing CS 259 Vitaly Shmatikov.
Probabilistic Model Checking CS 395T. Overview uCrowds redux uProbabilistic model checking PRISM model checker PCTL logic Analyzing Crowds with PRISM.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Safety and Liveness. Defining Programs Variables with respective domain –State space of the program Program actions –Guarded commands Program computation.
Lecture 2: Reasoning with Distributed Programs Anish Arora CSE 6333.
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
Lecture 4&5: Model Checking: A quick introduction Professor Aditya Ghose Director, Decision Systems Lab School of IT and Computer Science University of.
Modeling Software Systems Lecture 2 Book: Chapter 4.
Temporal Logic and Model Checking. Reactive Systems We often classify systems into two types: Transformational: functions from inputs available at the.
Temporal Logic of Actions (TLA) Leslie Lamport
Technische Universität München Institut für Informatik D München, Germany Realizability of System Interface Specifications Manfred Broy.
CS294, YelickConsensus, p1 CS Consensus
Review of the automata-theoretic approach to model-checking.
C ontract signing Rohit Chadha, John Mitchell, Andre Scedrov, Vitaly Shmatikov.
Analysis of optimistic multi-party contract signing Rohit Chadha 1,2, Steve Kremer 3, Andre Scedrov 1 1 University of Pennsylvania 2 University of Sussex.
Real-Time System Requirements & Design Specs Shaw - Chapters 3 & 4 Homework #2: 3.3.1, 3.4.1, Add Error states to Fig 4.1 Lecture 4/17.
CHAPTER 10 Recursion. 2 Recursive Thinking Recursion is a programming technique in which a method can call itself to solve a problem A recursive definition.
Model Checking LTL over (discrete time) Controllable Linear System is Decidable P. Tabuada and G. J. Pappas Michael, Roozbeh Ph.D. Course November 2005.
Time, Clocks, and the Ordering of Events in a Distributed System Leslie Lamport (1978) Presented by: Yoav Kantor.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Correctness requirements. Basic Types of Claims Basic assertions End-state labels Progress-state labels Accept-state labels Never claims Trace assertions.
Analysis of a Fair Exchange Protocol Vitaly Shmatikov John Mitchell Stanford University.
Information Security Conference (ISC 2015) On the Efficiency of Multi-Party Contract Signing Protocols Gerard Draper-Gil, Josep-Lluis Ferrer Gomila, M.
Rational Exchange Levente Buttyán and Jean-Pierre Hubaux Swiss Federal Institute of Technology – Lausanne Laboratory for Computer Communications and Applications.
Game-Based Verification of Fair Exchange Protocols CS 259 Vitaly Shmatikov.
CS6133 Software Specification and Verification
Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications 1.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Defining Programs, Specifications, fault-tolerance, etc.
Probabilistic Model Checking for Security Protocols CS 259 Vitaly Shmatikov.
Recognizing safety and liveness Presented by Qian Huang.
Network Protocols Network Systems Security Mort Anvari.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Validation - Formal verification -
A theory of DbC for multiparty distributed interactions Emilio Tuosto University of Leicester Nobuko Yoshida Imperial College London Kohei Honda Queen.
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
Predicate Abstraction. Abstract state space exploration Method: (1) start in the abstract initial state (2) use to compute reachable states (invariants)
Alternating Temporal Logic and Game-Based Properties CS 259 John Mitchell with slides from Vitaly Shmatikov.
VIS Technology Transfer Course Session 7 Fairness Constraints and Monitors Serdar Tasiran.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Presented by: Belgi Amir Seminar in Distributed Algorithms Designing correct concurrent algorithms Spring 2013.
About Alternating Automata Daniel Choi Provable Software Laboratory KAIST.
Strategic Reasoning with Game Description Language Ji Ruan, Prof. W. van der Hoek, Prof. M. Wooldridge Department of Computer Science From Specific Game.
Introduction to distributed systems description relation to practice variables and communication primitives instructions states, actions and programs synchrony.
Probabilistic Contract Signing CS 395T. Probabilistic Fair Exchange uTwo parties exchange items of value Signed commitments (contract signing) Signed.
Knowledge Repn. & Reasoning Lecture #9: Propositional Logic UIUC CS 498: Section EA Professor: Eyal Amir Fall Semester 2005.
1 Maximality Properties Dr. Mikhail Nesterenko Presented By Ibrahim Motiwala.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CSCI1600: Embedded and Real Time Software
SS 2018 Software Verification Strategic Reasoning
IS 2935: Developing Secure Systems
Alternating tree Automata and Parity games
Non-Deterministic Finite Automata
Programming Languages and Compilers (CS 421)
CSCI1600: Embedded and Real Time Software
‘Crowds’ through a PRISM
Presentation transcript:

CS 395T Game-Based Verification of Contract Signing Protocols

Alternating Transition Systems uGame variant of Kripke structures R. Alur, T. Henzinger, O. Kupferman. “Alternating- time temporal logic”. FOCS uStart by defining state space of the protocol  is a set of propositions  is a set of players Q is a set of states Q 0  Q is a set of initial states  : Q  2  maps each state to the set of propositions that are true in the state uSo far, this is very similar to Mur 

Transition Function u  : Q   2 2 Q maps a state and a player to a nonempty set of choices, where each choice is a set of possible next states When the system is in state q, each player chooses a set Q a  (q,a) The next state is the intersection of choices made by all players  a   (q,a) The transition function must be defined in such a way that the intersection contains a unique state uInformally, a player chooses a set of possible next states, then his opponents choose one of them

Example: Two-Player ATS  = {Alice, Bob}  p   q  p  q p   q p  q A’s choices B’s choices

Example: Computing Next State  = {Alice, Bob}  p   q  p  q p   q p  q If A chooses this set… … B can choose either state Next state Next state

Alternating-Time Temporal Logic uPropositions p   u  or  1  2 where ,  1,  2 are ATL formulas u  A   ,  A   ,  A  1 U  2 where A  is a set of players, ,  1,  2 are ATL formulas These formulas express the ability of coalition A to achieve a certain outcome , , U are standard temporal operators (similar to what we saw in PCTL) uDefine  A    as  A  true U 

Strategies in ATL uA strategy for a player a  is a mapping f a :Q +  2 Q such that for all prefixes  Q* and all states q  Q, f a (  q)  (q,a) For each player, strategy maps any sequence of states to a set of possible next states uInformally, the strategy tells the player in each state what to do next Note that the player cannot choose the next state. He can only choose a set of possible next states, and opponents will choose one of them as the next state.

Temporal ATL Formulas (I) u  A    iff there exists a set F a of strategies, one for each player in A, such that for all future executions  out(q,F a )  holds in first state [1] Here out(q,F a ) is the set of all future executions assuming the players follow the strategies prescribed by F a, i.e., =q 0 q 1 q 2 …  out(q,F a ) if q 0 =q and  i q i+1   a  A f a ( [0,i]) uInformally,  A    holds if coalition A has a strategy such that  always holds in the next state

Temporal ATL Formulas (II) u  A    iff there exists a set F a of strategies, one for each player in A, such that for all future executions  out(q,F a )  holds in all states Informally,  A    holds if coalition A has a strategy such that  holds in every execution state u  A    iff there exists a set F a of strategies, one for each player in A, such that for all future executions  out(q,F a )  eventually holds in some state Informally,  A    holds if coalition A has a strategy such that  is true at some point in every execution

Protocol Description Language uGuarded command language Very similar to PRISM input language (proposed by the same people) uEach action described as [] guard  command guard is a boolean predicate over state variables command is an update predicate, same as in PRISM Simple example: []SigM1B   SendM2   StopB -> SendMrB1’:=true;

Fairness in ATL  B,Com   (contract A  A h   contract B ) Bob in collaboration with communication channels does not have a strategy to reach a state in which Bob has Alice’s signature but honest Alice does not have a strategy to reach a state in which Alice has Bob’s signature

Timeliness + Fairness in ATL  A h   (stop A  (  contract B  B,Com   contract A )) in which she can stop the protocol and Honest Alice always has a strategy to reach a state if she does not have Bob’s signature then Bob does not have a strategy to obtain Alice’s signature even if he controls communication channels

Abuse-Freeness in ATL  A   (proveToC   A   contract B   A   (aborted   B h   contract A )) she has a strategy to obtain Bob’s signature AND Alice doesn’t have a strategy to reach state in which she can prove to Charlie that a strategy to abort the protocol, i.e., reach a state where Alice has received abort token and Bob doesn’t have a strategy to obtain Alice’s signature

Modeling TTP and Communication uTrusted third party is impartial This is modeled by defining a unique TTP strategy TTP has no choice: in every state, the next action is uniquely determined by its sole strategy uCan model protocol under different assumptions about communication channels Unreliable: infinite delay possible, order not guaranteed –Add “idle” action to the channel state machine Resilient: finite delays, order not guaranteed –Add “idle” action + special constraints to ensure that every message is eventually delivered (rule out infinite delay) Operational: immediate transmission

MOCHA Model Checker uModel checker specifically designed for verifying alternating transition systems System behavior specified as guarded commands –Essentially the same as PRISM input, except that transitions are nondeterministic (as in in Mur  ), not probabilistic Property specified as ATL formula uSlang scripting language Makes writing protocol specifications easier uTry online implementation!