Modeling and Analysis of Complex Computational Systems

1
Modeling and Analysis of Complex Computational
Systems

• Nancy Lynch, MIT
• MIT MURI Meeting
• January 24, 2003
• Participating researchers
• Nancy Lynch, Dilsun Kirli, MIT
• John Mitchell, Stanford
  
• Mahesh Viswanathan, U. Illinois

2
Research Areas
Control Information Theory
Computing Verification
Robotic Vehicles
Communications
3
1. Project Description

• Develop methods and tools for modeling and
  analyzing complex systems, emphasizing
• Systems for automated transportation (ground,
  air, space).
• Systems for secure data management and
  communication.
• Methods and tools can be used for
• System documentation/specification
• Design validation
• Simulation
• Stating correctness and performance claims
• Proving that the systems satisfy the
  claims---automatically, manually, or
  interactively.
• Automatic code generation

4
Varieties of models
Timed
Probabilistic
Basic Asynchronous
Hybrid
Features
Styles
State-transition models
Program-based models
Logic-based models
5
Styles of Models

• State-transition models
• Finite-state machines
• Turing machines
• I/O automata
• Probabilistic, polynomial-time TMs
• Program-based models
• Process calculi
• Logic-based models Represent computation by
  properties
• Floyd-Hoare logic
• Before/after conditions for program statements
• Temporal logic
• First-order state predicates ? ? ? ? ? ?
• Modal operators Always ?, Eventually ?

6
Model Features (Expressive Power)

• Basic asynchronous behavior
• Asynchronous distributed algorithms, distributed
  systems
• Safety and liveness properties
• Timing behavior
• For timeout-based algorithms
• Local clocks, clock synchronization
• Timing/performance properties
• Hybrid (continuous/discrete) behavior
• Systems with real world computer components
• Vehicle control ground, air, space
• Embedded systems
• Probabilistic behavior
• Randomized distributed algorithms
• Security protocols
• Safety-critical systems

7
Formal Verification

• Are all possible behaviors of the implementation
  compatible with the specification?
• Verification methods automatic, manual,
  interactive

8
Automatic verification
OK
Finite-state model
or
Model Checker
(F W)
Temporal logic formula
9
Model checking

• Advantages
• Automatic
• Practical algorithms and tools
• Disadvantages
• Finite model must be fairly small
• Requires manual work to construct small
  abstractions for large, complex systems
• Finite state approximation usually conservative
• Error found ? System has error
• Error not found ? ???

10
Manual verification

• Decompose system models using
• Parallel composition
• Levels of abstraction.
• Formulate key properties
• Invariants
• Abstraction (simulation) relationships
• Prove invariants and simulations manually, using
  induction on length of execution.
• Manual methods can accommodate timing, continuous
  behavior.

11
Interactive verification

• Inductive proofs of invariants and simulation
  relations can be carried out using interactive
  theorem-provers
• Isabelle/HOL, PVS, Larch
• Yields very useful results.
• But time-consuming, painstaking work

12
Talk Outline

1. Introduction Formal modeling and analysis ?
2. I/O Automaton models and their use in modeling
   and analyzing distributed systems
3. Security protocols
4. Software analysis
5. Conclusions

13
2. I/O Automaton Models, and Their Use in
Modeling and Analyzing Distributed Systems

• Participants
  Nancy Lynch, Dilsun
  Kirli, Roberto Segala, Frits
  Vaandrager, Sayan Mitra

14
I/O Automata

• Infinite-state, nondeterministic automaton
  models.
• Describe states, transitions.
• Describe system modularity
• Parallel composition of interacting components.
• Levels of abstraction.
• Example Generic distributed system
• IOA models describe interfaces and behavior.
• Abstract models for system components.
• Channel Implemented by TCP, modeled as FIFO
  queue.
• Node Implemented by C program, modeled as
  algorithm automaton.

15
Reliable FIFO Channel Model

• Signature
• Inputs
• send(m), m in M
• Outputs
• receive(m), m in M
• States
• queue, a finite sequence of elements of M,
  initially empty
• Transitions
• send(m)
• Effect Add m to end of queue
• receive(m)
• Precondition m is first on queue
• Effect remove first element of queue

send(m)
receive(m)
Channel(M)
16
Levels of Abstraction

• Used in system development by successive
  refinement.
• Top level automaton Specification for allowed
  behaviors.
• Refine through many levels, to code-like,
  detailed description.
• Example Group communication system
• Automata for TO reliable broadcast service, GC
  service, algorithm.
• Composition of algorithm and GCS automata
  implements TO-Bcast.
• Continue, implementing GCS in terms of
  lower-level network.

17
I/O Automata (IOA)

• Static description
• Actions input, output, internal
• States, start states
• Transitions (q, a, q'), input-enabled
• Dynamic description
• Execution q0 a1 q1 a2 q2
• Trace Project on external actions externally
  visible behavior.
• A implements B traces(A) ? traces(B).
• Operations for building automata
• Parallel composition, identifying inputs and
  outputs.
• Action hiding.
• Reasoning methods
• Invariant assertions Property holds in all
  reachable states.
• Simulation relations Imply one automaton
  implements another.
• Compositional methods

18
Example Applications

• Basic distributed algorithms
• Resource allocation, consensus, atomic objects,
  concurrency control, group communication,
• Distributed systems
• Orca distributed shared memory system
  
• Transis group communication system
  
• Ensemble group communication system
• Algorithms for dynamic networks
• Reconfigurable atomic memory Lynch, Shvartsman
  02 Gilbert, Lynch,
  Shvartsman 03 Musial, Shvartsman 03
• Dynamic atomic broadcast Bar-Joseph, Keidar,
  Lynch 02

19
IOA Language ToolsetGarland, Lynch

• Formally-defined programming/modeling language
  for describing and analyzing systems modeled as
  I/O automata.
• Current tools
• Simulator, including levels of abstraction
• Connection with Daikon invariant detector
• Connection to Larch theorem-prover
• Connection to Isabelle/HOL theorem-prover.
• In progress
• Automatic distributed code generator.

20
Additions to I/O Automaton Models

• Timing behavior TIOA
• For describing timeout-based algorithms.
• Local clocks, clock synchronization.
• Timing/performance analysis.
• Hybrid (continuous/discrete) behavior HIOA
• Systems with real world computer components
• Vehicle control ground, air, space
• Embedded systems
• Probabilistic behavior PIOA, PTIOA, PHIOA
• Randomized distributed algorithms
• Security protocols
• Safety-critical systems

21
All the IOA models
PHIOA
HIOA
PTIOA
TIOA
PIOA
IOA
22
Timed I/O Automata (TIOA)

• Add time-passage actions, pass(t)
• Example FIFO channel that delivers messages
  within time d.
• send(m)
• Effect Add (m, now d) to end of queue
• receive(m)
• Precondition (m,u) is first on queue (for some
  u)
• Effect remove first element of queue
• pass(t)
• Precondition for all (m,u) in queue, now t
  ? u
• Effect now now t
• Can use standard automaton-based reasoning
  methods
• Invariant
• If (m,u) in queue, then now ? u ?
  now d.
• Inductive proofs.

23
Example Applications

• Distributed algorithms
• Resource allocation, consensus,
• Timeout-based communication protocols
• TCP, reliable multicast,
• Performance (latency) analysis
• Group communication systems
• Using GCS to build TO-Bcast
• Scalable GCS
• RAMBO reconfigurable atomic memory
• Toy hybrid (continuous/discrete) systems
• RR crossing
• Steam boiler controller

24
Hybrid Systems

• Continuous, real-world components
  discrete, computer
  components
• Examples
• Automated transportation systems
• Robots
• Embedded systems
• Mobile systems
• Complex
• Strong safety, performance requirements

25
HIOA Model Lynch, Segala, Vaandrager 02, 03

• Model plants, controllers, sensors, actuators,
  computer software, communication services, human
  operators.
• Support for decomposing hybrid system
  descriptions
• External behavior Models discrete and
  continuous interactions of component with its
  environment.
• Composition Synchronize external events,
  external trajectories.
• Levels of abstraction Implementation notion,
  respects external behavior.
• Incorporate methods from
• Control theory Invariant sets, stability
  analysis using Lyapunov functions, robust control
  methods
• Computer science Invariants, simulation
  relations, compositional methods

26
Describing Hybrid Behavior

• Variable v
• Static type, type(v)
• Dynamic type, dtype(v) Allowed trajectories
  for v
• Functions from time intervals to type(v).
• Valuation for V Assigns value in type(v) to
  each v in V.
• Trajectory
• Models evolution of variables over a time
  interval.
• I-trajectory for V Maps I to valuations for V
  restriction
  to each v is in dtype(v).
• Hybrid sequence
• Models a series of discrete and continuous
  changes.
• ?0 a1 ?1 a2 ?2 , alternating sequence of
  trajectories and actions.

27
Hybrid I/O Automaton

• U, Y, X Input, output, and internal (state)
  variables
• Q States, a set of valuations of X
• ? Start states
• I, O, H Input, output, and internal actions
• D ? Q ? (I ? O ? H) ? Q Discrete transitions
• T Trajectories for (U ?Y ? X) in which the
  valuations of X are in Q.

I
O
X
U
Y
H
28
Input-Enabling Axioms

• Input action enabling
• For every state q and every input action a, there
  is some discrete transition (q,a,q).
  
  
• Input trajectory enabling
• For every state q and every input trajectory,
  there is some trajectory that starts with q, and
  either
• Spans the whole input trajectory, or
• Spans a prefix of the input trajectory, after
  which some locally-controlled action is enabled.

29
Executions and Traces

• Execution fragment
• Hybrid sequence ?0 a1 ?1 a2 ?2 , where
• Each ?i is a trajectory of the automaton and
• Each ( ?i.lstate, ai , ?i1.fstate) is a discrete
  step.
• Execution
• Execution fragment beginning in a start state.
• Trace
• Restrict to external actions and external
  variables.
• A implements B if they have the same external
  interface and traces(A) ? traces(B).

30
Notation for specifying trajectories

• Differential and algebraic equations and
  inclusions.
• Trajectory ? satisfies algebraic equation
• v e
• if the constraints on the variables
  expressed by this equation hold in every state of
  ?.
• Trajectory ? satisfies differential equation
• d(v) e
• if for every t in the domain of ?,
• v(t) v(0) ?0t e(t) dt
• Algebraic/differential inclusions are handled
  similarly.

31
Example Vehicle HIOA

• Follows suggested acceleration to within ?.
  
• Outputs actual velocity.
• U acc-in Y vel-out X acc, vel
• Q all valuations of X
• ? acc vel 0
• I, O, H, D empty
• Trajectories
• acc(t) ? acc-in(t) - ?, acc-in(t) ?, for t gt
  0
• d(vel) acc
• vel-out vel

32
Example Controller HIOA

• Monitors velocity, suggests acceleration every
  time d.
• Tries to ensure velocity does not exceed
  pre-specified vmax.
• U vel-out Y acc-in X vel-sensed,
  acc-suggested, clock
• ? all 0
• H suggest
• Discrete steps
• clock d, clock 0,
• vel-sensed unchanged
• vel-sensed (acc-suggested ?) d ? vmax
• Trajectories
• vel-sensed(t) vel-out(t), for t gt 0
• acc-suggested unchanged
• d(clock) 1
• acc-in acc-suggested
• stops when clock d

33
Simulation Relation R from A to B

• Relation from states(A) to states(B) satisfying
• Every start state of A is related to some start
  state of B.
• If x R y and ? is a discrete step of A starting
  with x, then there is an execution fragment ?
  starting with y such that trace(?) trace(?),
  and ?.lstate R ?.lstate.
• y ?
  ?.lstate.
• R
  R
• x ?
  ?.lstate.
• If x R y and ? is a closed trajectory of A
  starting with x, then there is

34
Simulation Relation

• Theorem If there is a simulation relation from
  A to B then A implements B (inclusion of trace
  sets).

35
Composition A A1 A2

• Assume A1 and A2 are compatible (no common
  outputs, internal actions/variables are private).
• Obtain A A1 A2 by matching external actions,
  variables
• Y Y1 ? Y2 X X1 ? X2 U (U1 ? U2 ) - (Y1 ?
  Y2 )
• O O1 ? O2 etc.
• States Q Projections in Q1, Q2
• Start states, discrete steps, trajectories
  Projections
• Projection/pasting theorem
• If A A1 A2 then tracesA is the set of
  hybrid sequences (of the right type) whose
  restrictions to A1 and A2 are traces of A1 and
  A2, resp.
• Substitutivity theorem
• If A1 implements A2 and both are compatible with
  B, then A1 B implements A2 B.

36
Example Vehicle and Controller

• Vehicle Controller
• Invariant of Vehicle Controller vel ? vmax.
• Prove using induction.
• Uses auxiliary invariants, most importantly
• vel (acc-suggested ?) (d clock) ?
  vmax

vel-out

• vel-sensed
• acc-suggested
• clock

acc-in
acc, vel
37
Hiding

• ActHide(E,A) reclassifies external actions in E
  as internal.
• VarHide(W,A) removes the external variables in W,
  but retains their induced constraints on the
  trajectories.
• Example
• Hide the acc-in variable, which is used for
  communication between the components
• A VarHide(acc-in, Vehicle
  Controller)
• The only remaining external variable is vel-out.
• Prove correctness of A by showing that it
  implements an abstract specification HIOA Vspec,
  which expresses exactly the constraint vel-out ?
  vmax.
• Show using simulation relation.

Vehicle
Controller
38
Progressive HIOAs

• HIOAs
• Should provide some response from any state, for
  any sequence of input actions and input
  trajectories.
• Should not block the passage of time allow time
  to pass to ?.
• Definition An HIOA is progressive if it has no
  execution fragment in which it generates
  infinitely many non-input actions in finite time.
• Theorem A progressive HIOA A can accommodate any
  input hybrid sequence, from every state
• For each state x and each (I,U)-sequence ?,
  there is some execution fragment ? from x such
  that ? ? (I,U) ?.
• Theorem Composition of progressive HIOAs is
  progressive.

39
Receptive HIOAs

• But progressiveness isnt enough
• HIOAs involving only upper bounds on timing are
  not progressive.
• These are important.
• Definition A strategy for an HIOA A is an HIOA
  that is the same as A except that it restricts
  the sets of discrete steps and trajectories.
• Definition HIOA is receptive if it has a
  progressive strategy.
• Theorem A receptive HIOA can accommodate any
  input hybrid sequence.
• Theorem If A1 and A2 are compatible receptive
  HIOAs with progressive strategies B1 and B2, then
  A1 A2 is receptive with progressive strategy
  B1 B2.

40
Example Applications

• Ground transportation
• People-mover (Raytheon)
  
• California PATH automated highway system
• Aircraft control
• TCAS (Lincoln Labs) Livadas, Lygeros, Lynch.
• Quanser helicopter system (MIT Aero/Astro)
  Mitra, Wang, Feron, Lynch 02, 03.
• Spacecraft
• ACME Ha, Lynch, Garland, Kochocki, Tanzman 03

41
TCAS modelLivadas, Lygeros, Lynch 99
Aircraft
Aircraft
Sensor
Sensor
Pilot
Pilot
Conflict detector
Conflict detector
Channel
Conflict resolver
Conflict resolver
Channel
42
Quanser Model Helicopter SystemMitra, Wang,
Feron, Lynch 02, 03

• 3 degrees-of-freedom models, manufactured by
  Quanser
• User controllers not necessarily safe, can crash
  the helicopter on the table.
• Supervisory pitch controller needed to ensure
  safety.
• Must contend with
• Sensor inaccuracies
• Actuator delay
• Limited sampling frequency

43
HIOA model and analysis

• We developed HIOA models for all system
  components Plant, Sensor, Actuator, User
  Controller, Supervisor
• Used the models to help design a safe supervisory
  controller.
• Controller implemented.
• Proof of system safety carried out (manually).

44
Discrete communication among components
sample control command dequeue
usrCtrl
sensor
sensor
plant
supervisor
actuator
0
45
Executions in the User and Supervisor modes
Cannot jump from U to outside of R in a single
step
Recovery Phase
Switch to supervisor settling phase
Return to user mode
46
Contributions

• Developed HIOA model for all components of the
  Quanser helicopter system.
• Including realistic dynamics, inaccuracies,
  delays.
• Used model to help design safe supervisory
  controller.
• Proved correctness, manually
• Using induction
• Each inductive step involves either discrete or
  continuous reasoning.
• Developed candidate language constructs for
  specifying trajectories of HIOAs
• Algebraic and differential equation notation
• Unchanged, invariants, stopping conditions
• State models and activities

47
Future Work HIOA Modeling and Verification
Mitra

• Apply HIOA model to a variety of examples
• Systems with more complicated discrete behavior
  and dynamics.
• Mobile computing, embedded systems.
• Incorporate control theory methods
• Invariant sets, Lyapunov stability, robust
  control.
• Carry out proofs using a theorem prover, e.g.,
  Isabelle.
• Design linguistic support HIOA Language
• Language constructs for describing trajectories
• As addition to IOA language
• Develop analysis tools for HIOA programs
• Theorem-provers, automated tools.
• As addition to IOA toolset
• Automate code generation for software components.

48
TIOA, revisited Kirli, Lynch, Segala,
Vaandrager 03

• Now use what we have learned from modeling hybrid
  systems to redefine our timed automaton model.
• Timed systems do not involve real-world
  components like cars and helicopters---just
  computers and communication networks.
• However, they still involve continuous state
  evolution, e.g., hardware clocks.
• Therefore, we view timed systems as a special
  case of hybrid systems, in which components have
  no continuous interaction.
• Timing behavior described as in HIOA, using
  trajectories and hybrid sequences.

49
Example Time bounded channel

• X now, queue
• ? now 0, queue is empty
• I send(m)
• O receive(m)
• Discrete steps
• send(m)
• Effect add (m, now d) to end of queue
• receive(m)
• Precondition (m,u) is first on queue
• Effect remove first element of queue
• Trajectories
• queue unchanged
• d(now) 1
• stops when clock u for some (m, u) on queue

50
Properties for TIOAs

• Property P for A A subset of the execution
  fragments of A.
• P is a liveness property provided that, for any
  state q of A, there is some execution fragment
  from q that is in P.
• A is receptive for P if there exists a strategy B
  for A such that every execution fragment of B is
  in P.
• Theorem If A1 is receptive for P1 and A2 is
  receptive for P2 then A1 A2 is receptive for
  P1 P2.

51
Current/Future Work TIOA

• Complete the development of a general TIOA model
  for timing-based systems, including
• External behavior, composition, levels of
  abstraction
• Receptivity, liveness properties
• Examples
• Express major ideas from other timed system
  models in the common framework of TIOA
• Congruence, region construction (for
  model-checking)
• Alur, Dill timed automata
• Built-in upper and lower bounds for tasks
• Maler, Manna, Pnueli timed transition systems
• Merritt, Modugno, Tuttle timed automata
• Timing constraints that sometimes hold.
• DePrisco clock timed automata
• Linguistic support, tool support.

52
Probabilistic I/O Automata (PIOA) Segala

• Adds probabilistic transitions (s, a, P), where P
  is a probability distribution on states.
• Includes both nondeterministic and probabilistic
  choices.
• Scheduler Resolves all nondeterminism.
• External behavior represented by a set of trace
  distributions, one for each scheduler.
• Implementation Subset (of sets of trace
  distributions).
• Example applications
• Randomized distributed algorithms
• Rabin-Lehmann Dining Philosophers
• Aspnes-Herlihy randomized consensus
• Security protocols

53
Current work Compositional semantics

• Trace distribution preorder ?D on PIOAs
• Subset (of sets of trace distributions).
• Not preserved by composition.
• Trace distribution precongruence ? DC
  
• Defined as the coarsest precongruence included in
  ? D.
• Preserved by composition.
• But this is not very informative.
• Characterization result for ? DC
• Weak probabilistic forward simulation relation
  from A1 to A2
• Relates states of A1 to distributions over states
  of A2.
• Transitions preserve probabilities.
• Allows arbitrary internal actions.
• Conjecture A1 ? DC A2 if and only if there
  exists a weak probabilistic forward simulation
  relation from A1 to A2 .

54
Future work PIOA

• Restrict the set of schedulers to those that can
  see only external behavior of the component
  automata. Yields a smaller set of trace
  distributions.
• For this restricted set, obtain a
  characterization of the trace distribution
  precongruence. Is it the same as the trace
  distribution preorder?

55
Probabilistic Timed I/O Automata (PTIOA) Segala

• Include time-passage steps, with probability
  distributions on the new state (s,
  pass(t), P)
• Scheduler determines amount of time that passes
  (nondeterministic, not probabilistic).
• External behavior represented by a set of
  distributions of timed traces (one for each
  scheduler).
• Timed trace distribution preorder.
• Timed trace distribution precongruence.

56
Future work PTIOA, PHIOA

• PTIOA
• Reformulate in terms of trajectories, as in TIOA,
  HIOA.
• Characterize the timed trace distribution
  precongruence.
• Generalize TIOA results to include probabilities.
• Define simulation relations, show they imply
  timed trace distribution inclusion.
• Receptiveness?
• PHIOA
• Define a model that generalizes PTIOA and HIOA
• Define external behavior, composition,
  implementation,prove all the right theorems.

57
All the IOA Models

• How do they relate to each other?
• How orthogonal are all the features?

58
3. Security Protocol Modeling and Analysis

• Participants
  John Mitchell, A.
  Ramanathan, A. Scedrov, V. Teague
  Jon Herzog

59
Security Protocol

• Distributed algorithm that uses cryptography to
  achieve its goals.
• Adversary capabilities
• Intercept, replace, remember messages.
• Guess random numbers, perform a bounded amount of
  computation.
• Protocol correctness
• Attacker cannot learn protected secrets.
• Honest participants do not reach incorrect
  conclusions or otherwise exhibit incorrect
  behavior.
• Protocols usually small, but often logically
  complex.
• Analysis important, since correctness is
  critical.

60
Example Challenge-Response

• Alice wants to know if Bob is listening
• Send fresh number n, Bob returns f(n)
• Use encryption to avoid forgery
• Protocol
• Alice ?? Bob nonce K
• Bob ?? Alice nonce 5 K
• Can Alice be sure that
• The message is from Bob?
• The message is a fresh response to Alices
  challenge?

61
Standard modeling and analysis methods

• Finite-state machines
• Model-checking.
• Automata that perform restricted operations
• Inductive reasoning algebra.
• Logic based models
• Formal logical deduction.
• Probabilistic polynomial time Turing machines
• More realistic intruder model
• Harder interaction between protocol and
  cryptography
• Proofs use reduction to hard computational
  problems.

62
Probabilistic Polynomial-Time Process Calculus
for Security Protocol Analysis

• J. Mitchell, A. Ramanathan, A. Scedrov, V. Teague
• P. Lincoln, M. Mitchell

63
Process-Calculus Approach

• Write protocol using a process calculus.
• Express security properties using observational
  equivalence
• P ? Q iff for all contexts C , CP and CQ
  yield the same observations.
• Here, contexts represent adversaries.
• Protocol is secure if no context can distinguish
  it from an idealized version.
• Use formal proof rules for ? to prove security
  properties.

64
Probabilistic Poly Time Process Calculus

• Probability is important
• Protocols use probabilistic primitives Key
  generation, nonce, probabilistic encryption, ...
• Adversary may be probabilistic.
• Complexity bounds are important
• Needed to model possible attacks.
• So
• Define a new process calculus to describe
  probabilistic polynomial time processes.
• Define a new probabilistic observational
  equivalence.
• Express protocol and specification in the pptime
  process calculus.
• Prove security by proving probabilistic
  observational equivalence between protocol and
  specification.

65
Our Process Calculus Syntax

• Bounded ?-calculus with integer terms
• Expressions have size poly in n
• P 0
• cq(n) ?T? send up to q(n)
  bits
• cq(n) (x). P receive
• ?cq(n) . P private channel
• TT P test
• P P parallel
  composition
• ! q(n) . P bounded
  replication

Terms may contain symbol n channel width and
replication bounded by poly in n
66
Probabilistic Semantics

• Process execution corresponds to evaluation of
  the expression describing the process.
• Choice of arbitrary probabilistic scheduler
  resolves all nondeterminism.
• Probabilistic scheduler
• Chooses random values
• Schedules parallel processes probabilistically
• Chooses among enabled communications
  probabilistically
• Execution (evaluation) takes polynomial time, in
  all runs.

67
Probabilistic observational equivalence

• Basic idea
• Prob CP ? yes - Prob CQ ? yes lt
  ?
• But what is ??
• Use security parameter n, representing key
  length.
• Model protocol as a family Pn
• f observational equivalence
• For all contexts (adversaries) C and all
  observations v
• ProbCnPn ? v - ProbCnQn ?
  v lt f(n)
• for sufficiently large n.
• Probabilistic observational equivalence
• P ?f Q for every f, where f(n) 1/p(n) and p
  is a polynomial.

68
Proving probabilistic observational equivalence

• Involves developing a library of rules, e.g.
• P (Q R) ? (P Q) R
• P Q ? Q P
• P 0 ? P
• P ? Q ? CP ? CQ
• Compositionality A ? A and B ? B ? A B ? A
  B
• Challenge Need the right rules
• Rules must handle probabilities correctly, e.g.,
  summing probabilities.
• Sufficiently rich set of rules to capture
  interesting cases of observational equivalence.

69
Future Work PPtime Process Calculus

• Continue to develop framework for protocol
  analysis
• Develop good methods for establishing
  probabilistic observational equivalence
• Set of rules
• Probabilistic simulation relation methods
• Examples
• Diffie-Hellman, Bellare-Rogaway,

70
Formal vs. Computational Approaches to Proving
Correctness of Security ProtocolsHerzog 02

• Formal approach
• Interacting non-probabilistic automata.
• Supports direct proofs, using induction.
• Computational approach
• Interacting probabilistic poly time Turing
  machines.
• Indirect proofs Reductions of attacks to hard
  problems.
• How do the two approaches relate?

71
Formal Approach Dolev, Yao

• Adversary controls the network.
• Encryption, decryption treated as abstract,
  idealized operations.
• Cryptographic abilities of adversary made
  explicit
• Encrypt, decrypt with known keys
• Make random choices, create new keys
• Proof of security
• Adversary abilities do not combine to produce an
  unsafe operation.

72
Computational Approach

• Adversary controls the network
• Encryption instantiated with specific algorithms
• Adversary capable of any feasible (probabilistic
  polynomial time) computation.
• Proof of security
• If any adversary can violate a security
  condition, then an independently-studied,
  apparently hard, computational problem becomes
  easy.
• An apparent contradiction.

73
Relating the Two Approaches

• We would like to use the computational view as
  semantics for the formal view
• Show formal attack exists iff computational
  attack exists.
• Known Formal attacks imply computational
  attacks.
• Open When do computational attacks imply
  formal attacks?
• Answer requires
• Semantics for adversary
• Semantics for honest participants
• Semantics for composition of adversary and honest
  participants.
• Focus of our work so far The adversary.

74
Formal Adversary

• Formal adversary makes queries to honest
  participants, receives responses
• Each query must be deducible from initial
  knowledge, responses, by sequence of
• Encryptions/decryptions with known key
• Pairing/separation of values
• Formal adversary modeled as closure operation on
  messages.

75
Ideal Encryption

• Computational encryption algorithm is ideal if
• no computational adversary, given any set of
  messages, can produce a message outside the
  closure of the set (with non-negligible
  probability)
• Theorem This limits computational adversary to
  formal adversary.
• Theorem This is achievable.

76
Future Work Security Protocols

• Complete the work on formal vs. computational
  approaches
• Define semantics for honest participants
• How do they validate incoming messages?
• No information should be given away in error
  cases.
• Define composition of adversary, honest
  participants
• Obtain general simulation theorems.
• Use the theorems to prove correctness of
  interesting security protocols.
• Express in terms of PTIOA.

77
4. Software Analysis

• Mahesh Viswanathan

78
System monitoring architecture
System Spec
Requirement Spec (MEDL)
Formal verification
Design Consistency
System Code
Monitoring Script (PEDL)
Implementation Consistency
System
Filter
Event Recognizer/ Checker
Run-time Consistency
Communication
Improve system design and execution
79
Checking properties of data streams

• Possible tests on streams
• Closeness of distributions
• Approximate entropy
• Statistical independence
• Example algorithm
• Efficient test for closeness
• Sample points on distribution
• Runtime is sublinear

close OR far?
Pass test if two distributions are close overall
Application embedded device in sensor net
computes useful statistical properties of
collected data
80
NS simulation analysis

• Logical analysis of network simulations in NS
• Apply monitoring techniques to simulation traces
• We performed a series of experiments aimed at
  assessing the approach

Data
NS Simulator
Checker
Monitor
Trace
Metatrace
Properties MEDL
Monitoring Script
81
Property Testing

• Checker should decide if input Data satisfies a
  property P.
• Checker has access to random source.
• Absolute guarantees are hard to obtain
• P Data is identically 0. Must check all the
  bits.
• Easier to get an approximate guarantee
• If Data satisfies property then say Yes with high
  probability.
• If Data is far from satisfying the property
  then say No with high probability.

82
Property Testing

• Property A set P of strings of length n
• Tester Given a string x
• If x in P then say Yes with probability at least
  2/3.
• If at least ? n bits of x must be changed in
  order to satisfy P, then say No with probability
  2/3.
• Cost Number of bits examined.
• Example P the string is sorted in
  nondecreasing order
• Algorithm Repeat 1/ ? times
• Pick index i at random.
• For every m, power of 2, do
• Pick index j within distance m at random
• Check that values at i and j are correct.
• Cost O(log n)

83
Future work

• Explore applications of property-testing methods
  for
• Testing properties of observed computations.
• Model-checking.
• Other work on model-checking
• Algorithms for special classes of state
  transition systems
• Simple hybrid systems, with finitely many
  discrete states, continuous variables that
  evolve at constant rate.
• More complex hybrid systems.
• Look for sub-linear space bounds, polynomial time
  bounds.
• Use ideas from symbolic model-checking.

84
5. Conclusions

• General project description
• Develop methods and tools for modeling and
  analyzing complex systems, emphasizing
• Systems for automated transportation.
• Systems for secure data management and
  communication.
• I/O automaton modeling framework
• Security protocol analysis methods
• Software analysis methods