Computer Security 463'10 Formal Methods

1
Computer Security463.10 Formal Methods

• Fall 2005

2
Required

• Reading
• J. M. Wing. A symbiotic relationship between
  formal methods and security. Proceedings NSF
  Workshop on Computer Security, Fault Tolerance,
  and Software Assurance From Needs to Solution.
  December 1998.
• L. C. Paulson. Proving properties of security
  protocols by induction. Proceedings of the 10th
  Computer Security Foundations Workshop, 1997,
  page 70-83

3
Introduction

• National Security Agency was the major source of
  funding formal methods research and development
  in the 70s and early 80s
• Formal security models
• Tools for reasoning about security
• Applications of using these tools to prove
  systems secure
• The use of Internet brings security to the
  attention of masses
• What kind of problems can formal methods help to
  solve in security
• What problems will formal methods never help to
  solve

4
The Limits of Formal Methods

• Systems will never made 100 secure
• Formal methods will not break this axiom
• Assumptions about the systems environment
• Hard to state them explicitly
• The system could be deployed in an environment
  not originally designed
• For convenience or lack of an alternative
• Clever intruders find out how to violate these
  assumptions
• Security is not an either/or property
• Pays more, gains more
• Eg. Passwords, certificates, biometrics are
  measured in terms of degree of security for
  authentication

5
What Formal Methods Can Do

• Delimit the systems boundary the system and its
  environment
• Characterize a systems behavior more precisely
• Define the systems desired properties precisely
• Prove a system meets its specification
• Tell under what circumstances a system cannot
  meet its specification

6
How They Can Help

• These capabilities of formal methods help
  practitioner in two ways
• Through specification, focusing on designers
  attention
• What is interface
• What are the assumptions about the system
• What is the system supposed to do under this
  condition and that condition
• What are the systems invariant properties
• Through verification
• Prove a system meet its security goals
• Find out the weakness of the system

7
History-Past

• Early formal method research funded by the
  National Security Agency, centered on proving
  systems secure
• Bell-LaPadula model
• Biba integrity model
• Clark-Wilson model
• The systems of interest to prove secure were
  operating systems, more specifically, kernels

8
Process of Proving

• Process of proving entails 3 parts
• Formal specification
• State the property of the system
• For example -property
• Model the system so that one can formally prove
  the property
• Model might be a semantic structure like a state
  machine or a syntactic structure like a logical
  expression
• Proof
• Methods
• Rely on induction over traces of the state
  machine model
• Or rely on deduction to show that an implication
  holds
• Automatically proved by machine or require
  interactive guidance of human

9
The Orange Book

• US Trusted Computer System Evaluation Criteria
  The Orange Book
• Produced by NCSC (National Computer Security
  Center) in 1985
• Provide a standard metric for NCSC to compare the
  security of different computer systems
• Guide computer system vendors in the design and
  development of secure systems
• Provide a means for specifying security
  requirements in Government contracts
• Levels D, C1,C2,B1,B2,B3,A1,A2
• Certified A.1 means that one formally specify the
  systems security requirements, formally model
  the system and formally prove that the model
  meets its specification

10
Major Results of Early 80s

• Major results of early 80s were theorem proving
  tools with general purpose
• Affirm (USC)
• Support for reasoning about equational logic
• Formal Development Methodology (FDM) System
  (System Development Corporation)
• Support for non-deterministic state machine model
• Gypsy (U. Texas Austin)
• Support for program verification of a subset of
  Pascal, including a verification condition
  generator
• (Enhanced) Hierarchy Development Methodology
  (HDM) (Stanford)
• SPECIAL specification language
• Collection of decision procedures for
  propositional logic

11
Tools Specific for Security

• Tools specific to reason about security
• Specifies an insecure state and the tool searches
  backwards to determine whether that state is
  reachable
• Interrogator
• Based on Prolog, exhaustive search, fully
  automatic
• NRL Protocol Analyzer
• Based on Dolev and Yaos work on algebraic term
  rewriting model for two-party cryptographic
  protocols
• Less automatic
• BAN logic Logic of Authentication
• Reason in terms of belief Logic
• Accumulates belief during the run of the protocol
• E.g., the freshness of message

12
Two Different Styles of Formal Methods

• Two different styles of formal methods
• The UK and European style
• Focus was on specification, on the systems high
  level design and on the paper-and-pencil analysis
• The US and Canadian style
• Focus was on verification, from the systems high
  level design through its code-level
  implementation down to its bit-level
  representation in hardware, and on
  machine-assisted analysis

13
History-Present

• Since early 90s, there was an explosion of new
  developments
• Three threads in the development of formal
  methods
• Model checking
• hardware verification
• Theorem proving
• Software specification

14
Model Checking

• Model Checking
• In 1996, model checker FDR was used to exhibit a
  flaw in the Needham-Schroeder protocol
• Since then many other model check tools or other
  proving tools showed the same thing
• Other protocols were or are being checked
• SSL by Stanford
• IKE, SET by Meadows
• Netbill electronic payment protocol

15
Theorem Proving

• Theorem proving approaches
• General purpose theorem prover Isabelle was used
  to reason 5 classic authentication protocols and
  their variation
• Coq was used to analyze the Needham-Schroeder
  protocol and SET
• PVS was used to verify authentication protocol

16
Hybrid Approaches

• Hybrid approaches
• Embodies both model checking and theorem proving
  functionalities
• Improved NRL protocol analyzer analyze IKE and
  SET protocol
• Improved NRL embodies both model checking (e.g.,
  brute force search )and theorem proving (e.g.,
  lemma generation)

17
Practice of Building Secure Systems

• Build secure systems
• Solid crypto base
• Encryption, hash, signature
• Protocols
• Authentication, key exchange protocol
• Standard reliable network protocol
• Systems and general purpose programming language
• Kerberos authentication
• Applications
• Online banking
• Online shopping
• Bill Payment

Applications
Systems/PL
Protocols
Crypto
Crypto
System Layers
18
Security Guarantees

• Security guarantees reverse
• Crypto base precisely tells us
• What is guaranteed
• What is not guaranteed
• What is still open problem
• Protocols
• formal methods provide some guarantee
• Systems/PL
• Commercial technology like Authenticode, Active
  X, Java provide varying degrees of security
• Applications
• Not very much at all

Applications
Systems/PL
Protocols
Crypto
Security Guarantees
19
A Case Study Proving Properties of Security
Protocols by Induction

• Cryptographic protocols let agents communicate
  securely over insecure network
• Secrecy spy cannot read the contents of messages
  intended for others
• Authenticity agents can identify themselves to
  others, but nobody can masquerade as somebody else

20
Two Popular Approaches

• Formal methods to analyze security protocols
• State exploration
• Model checking
• Model protocol as finite state system
• Verify by exhaustive search all reachable states
• Pros find attacks quickly
• Cons require drastic simplifying assumptions to
  make state space small
• Belief logics
• BAN Logic
• Formally express what an agent may infer from
  messages received
• Pros short proof expressed at high level of
  abstraction
• Cons do not address secrecy

21
An Inductive Approach

• Borrow elements from both approaches
• From state exploration concrete notion of events
• From belief logic derive guarantees from each
  protocol messages
• Inductive approach
• Traces of events A sends X to B
• Protocols are formalized as the set of all
  possible traces of events
• An agent may extend a trace in any way permitted
  by the protocol, given what he can see in current
  trace
• Any number of interleaved runs
• Modeling Accidents and general attacker
• Mechanize proofs
• Properties proved by Induction on traces
• Using theorem prover Isabelle

22
Why an Inductive Approach

• Necessary formal tool is inductive definition
• Inductive definition lists the possible actions
  an agent or system can perform
• Corresponding induction rule helps to reason
  about the consequences of an arbitrary finite
  sequence of such actions
• Highly general used to specify the semantics of
  program languages for long time
• Each security property is proved by induction
  over the protocol

23
Overview

• Method includes
• Theory of message analysis
• Theory describing standard features of protocols
• Individual protocol description rest on the
  former two common base
• Formalization assume an encrypted message can
  neither be altered nor read without the
  appropriate key

24
Messages

• Messages items may include
• Agent names A, B,
• Nonces Na, Nb,
• Keys Ka, Kb , Kab ,
• Compound messages X, X
• Encrypted messages Crypt K X
• Structure of each message is explicit
• Different types of components cannot be confused
• Note (K-1)-1 K

25
Message Analysis

• H an agents initial knowledge and the history
  of all messages sent in a trace
• parts H obtained from H by repeatedly adding
  components of compound messages and the bodies of
  encrypted messages
• Crypt K X 2 parts H ) X 2 parts H
• analz H obtained from H by repeatedly adding
  components of compound messages and by decrypting
  messages whose keys are in analz H
• Represents maximum knowledge a spy can learn
  without breaking ciphers
• Crypt K X 2 analz H, K-12 analz H) X 2 analz H
• synth H repeatedly adding agent names, forming
  compound messages and encrypting with keys
  obtained in H
• Model the messages a spy could build up from
  elements of H
• X 2 synth H, K 2 H ) Crypt K X 2 synth H

26
Model the attacker

• Observe all traffic, that is H
• Sends fraudulent messages from synth (analz H )
• May be able to get a set of lost long-term keys
  of those agents
• May be able to get session keys accidentally lost
• May be an agent by itself, so as to sent normal
  protocol messages and fraudulent ones

27
Modeling a protocol

• Each event in a trace has form Says A B X
• Each agents state is
• represented by its initial knowledge
• Its key shared with the server
• The list of events he can see
• Honest agents only read messages addressed to
  themselves

28
Example Protocol

• A variant of Otway-Rees protocol
• A ! B Na, A, B, Na, A, BKa
• B ! S Na,A,B, Na, A, BKa,Nb, Na,A, BKb
• S ! B Na, Na,Kab Ka, Nb, Kab Kb
• B ! A Na , Na,Kab Ka

29
Model its steps

• Protocol steps are modeled as possible extensions
  of a trace with new events
• If evs is a trace and N_a is unused, may add
• Says A B Na, A, B, Na,A,BKa
• If evs has Says A B Na, A, B, X and Nb is
  unused, may add
• Says B S Na, A, B, X, Nb, Na,A,BKb
• A instead of A is because B does not know the
  true sender
• Using X is because B cannot read Na,A,BKa

30

• If evs has Says B S Na, A, B, Na,A,BKa,
  Nb, Na,A,BKb and Kab is unused, may add
• Says S B Na, Na,Kab Ka, Nb, Kab Kb
• If evs has Says B S Na, A, B, X, Nb,
  Na,A,BKb and Says S B Na,X, Nb, Kab
  Kb , may add
• Says B A Na,X
• An agent may be in several protocol runs
  concurrently, the trace represents his state in
  all these runs
• Agents may respond to past events, no matter how
  old they are. They may respond any number of
  times or never

31
Three Additional Rules for Protocol

• Protocol description usually requires three
  additional rules
• The empty list , is a trace
• Fake If evs is a trace, X 2 synth(analz H ) is a
  fraudulent message and B ? Spy, then add
• Says Spy B X
• Modeling attacks
• Oops If evs is a trace and S distributed key K
  to A, Na and Nb were used, then add
• Says A Spy Na ,Nb ,K
• Models accidental loss of session keys
• Nonces identify the protocol run

32
Attack to the Example Protocol

• An attack to the protocol
• A ! B Na, A, B, Na, A, BKa
• 1. C ! A Nc, C, A, Nc, C, AKc
• 2. A ! S Nc, C, A, Nc, C, AKc ,Na,
  Nc, C, AKa
• 2. CA ! S Nc, C, A, Nc, C, AKc ,Na,
  Nc, C, A Ka
• 3. S ! A Nc, Nc,Kca Kc, Na, Kca Ka
• CB ! A Na , Na,Kca Ka
• Replacing Na by As original nonce Na
  eventually cause A to accept key Kca as a key
  shared with B

33
A Mechanized Theory of Messages

• Mechanized using Isabelle/HOL
• an instantiation of generic theorem prover
  Isabelle to higher-order logic
• Why Isabelle
• Support for inductively defined sets
• its automatic tools for proving

34
Brief Introduction to Isabelle

• Working with Isabelle means creating theories
• A named collection of types, functions and
  theorems
• theory T B1Bn
• declarations,
• definitions,
• proofs
• end

35
exampleTheory

• theory exampleTheory Main
• datatype 'a list Nil Cons 'a 'a list
• consts append 'a list gt 'a list gt 'a
  list
• primrec
• "append Nil ys ys"
• "append (Cons x xs) ys Cons x (app xs ys)
• lemma simp "append xs Nil xs"
• apply (induct xs)
• apply auto
• done
• end

datatype datatype declaration consts function
declaration primrec recursive definition of a
function lemma define a theorem and its proving
process simp an attribute for a lemma
36
Main Datatype Definition

• datatype agent Server Friend nat Spy
• datatype msg Agent agent
• Nonce nat
• Key key
• Mpair msg msg
• Crypt key msg

37
Induction Definition for parts H

• For parts H
• X 2 H Crypt K X 2 parts
  H
• X 2 parts H X 2 parts H
• X,Y 2 parts H X,Y 2 parts H
• X 2 parts H Y 2 parts H

38
Induction Definition for analz H

• For analz H
• X 2 H
• X 2 analz H
• Crypt K X 2 analz H K-1 2 analz H
• X 2 analz H
• X,Y 2 analz H X,Y 2 analz H
  
• X 2 analz H Y 2 analz H

39
Induction Definition for synth H

• For synth H
• X 2 H X 2 synth H K 2 synth
  H
• X 2 synth H Crypt K X 2 synth H
• X 2 synth H Y 2 synth H Agent A 2 synth H
• X,Y 2 synth H

40
Isabella Syntax for analz H

• consts analz msg set gt msg set
• inductive analz H
• intros
• Inj X2 H ) X 2 analz H
• Fst X,Y2 analz H ) X 2 analz H
• Snd X,Y2 analz H ) Y 2 analz H
• Decrypt Crypt K X 2 analz H
• Key (invKey K) 2 analz
  H
• ) X 2 analz H
  

• Inductive definition on analz H
• Inj, Fst, Snd and Decrypt are introduction rules

41
Simplification Rules

• They are monotonic (let G µ H)
• parts G µ parts H
• analz G µ analz H
• synth G µ synth H
• They are idempotent
• parts (parts H) parts H
• analz (analz H) analz H
• synth (synth H) synth H
• Other equations
• parts (analz H) parts H
• analz (parts H) parts H
• parts (synth H) parts H synth H
• analz (synth H) analz H synth H
• synth (parts H) ? irreducible
• synth (analz H) ? irreducible

42
Symbolic Evaluation parts H

• For parts H
• ins X H X H
• parts(ins(Agent A) H)ins(Agent A) (parts H)
• parts(ins(Nonce N) H)ins(Nonce N)(parts H)
• parts(ins (Key K) H)ins(Key K)(parts H)
• parts(ins(X,Y) H)insX,Y(parts (ins X
  (ins Y H)))
• parts(ins(Crypt K X) H)ins(Crypt K X)(parts (ins
  X H))

43
Symbolic Evaluation analz H

• For analz H
• analz(ins(Agent A) H)ins(Agent A)(analz H)
• analz(ins(Nonce N) H)ins(Nonce N)(analz H)
• analz(ins(X,Y) H)insX,Y(analz (ins X
  (ins Y H)))

44

• keysFor H K-1 9 X. Crypt K X 2 H
• K ? keysFor (analz H )
• analz (ins (Key K) H) ins (Key K) (analz H)
• analz (ins (Crypt K X) H)
• ins (Crypt K X) (analz (ins X H)) if K-12 analz
  H
• ins (Crypt K X) (analz H) otherwise
• Nested encryption give rise to nested
  if-then-else expression

45
Symbolic Evaluation synth H

• Symbolic evaluation of synth is impossible since
  its result is infinite.
• No necessary to do the symbolic evaluation
• Instead need to simplify assumption of the form X
  2 synth H, which arise when considering whether a
  certain message might be fraudulent
• Nonce N 2 synth H ) Nonce N 2 H
• Key K 2 synth H ) Key K 2 H (Key and Nonce are
  unguessable)
• Crypt K X 2 synth H )
• Crypt K X 2 H or
• X 2 synth H and K 2 H
• If know K ? H , then Crypt K X is a replay rather
  a spoof

46
Statistics for Simplification Rules

• Over 90 theorems are proved about parts, analz,
  synth, keysFor
• Most are proved by induction with respect to the
  relevant inductive definition, which only needs
  three command each
• Most of them can be later used by other theorems
  for automatic simplification

47
Events and Agent Knowledge

• datatype event Says agent agent msg
• Function sees models the set of messages an agent
  receives from a trace
• sees lost A ((Says A B X ) evs)
• ins X ( sees lost A evs) if A 2 B, Spy
• sees lost A evs otherwise
• lost a set of agents whose keys have been lost
  to the spy
• A who sees in this action

48
Initial Knowledge

• From the empty trace, an agent sees his initial
  state
• sees lost A initState lost A
• Each agent share a long term key with Server,
  E.g. shrK A
• initState lost Server all long term keys
• initState lost (Friend i)Key(shrK(Friend i))
• initState lost Spy Key(shrK(A)) A 2 lost

49
The Formal Protocol Specification

• A variant of Otway-Rees protocol
• A ! B Na, A, B, Na, A, BKa
• B ! S Na,A,B, Na, A, BKa,Nb, Na,A, BKb
• S ! B Na, Na,Kab Ka, Nb, Kab Kb
• B ! A Na , Na,Kab Ka

50
Rules for Modeling the Protocol

• Nil 2 otway
• Fake evs 2 otway B ? Spy X2 synth( analz (
  sees lost Spy evs) )
• ) Says Spy B X evs 2 otway
• OR1 evs 2 otway A ? B B ? Server Nonce NA ?
  used evs
• ) Says A B Nonce NA, Agent A, Agent
  B,
• Crypt (ShrK A) Nonce NA, Agent
  A, Agent B evs 2 otway
• OR2 evs 2 otway B ? Server Nonce NB ? used
  evs
• Says A B Nonce NA, Agent A, Agent
  B, X 2 set_of_list evs
• ) Says B Server Nonce NA, Agent A,
  Agent B, X, Nonce NB,
• Crypt (ShrK B) Nonce NA, Agent
  A, Agent B evs 2 otway
• OR3 evs 2 otway B ? Server Key Kab ? used
  evs
• Says B Server Nonce NA, Agent A,
  Agent B,
• Crypt (ShrK A) Nonce NA, Agent
  A, Agent B, Nonce NB,
• Crypt (ShrK B) Nonce NA, Agent
  A, Agent B 2 set_of_list evs
• ) Says Server B Nonce NA,
• Crypt (ShrK A) Nonce NA, Key
  Kab

51

• OR4 evs 2 otway A ? B
• Says B Server Nonce NA, Agent A,
  Agent B, X, Nonce NB, X
• 2 set_of_list evs
• Says S B Nonce NA, X, Crypt (ShrK
  B) Nonce NB, Key K
• 2 set_of_list evs
• ) Says B A Nonce NA, X
• Oops evs 2 otway B ? Spy
• Says Server B Nonce NA, X, Crypt (ShrK B)
  Nonce NB, Key K
• 2 set_of_list evs
• ) Says B Spy Nonce NA, Nonce NB,
  Key K evs 2 otway
• Nil, Fake, OR1 OR4 are rule names
• Nil for empty trace
• Fake for fraudulent messages
• OR1 OR4 for protocol steps
• Otway the set of all traces
• evs 2 otway states that evs is an existing
  trace, also is current trace
• used evs contains all message components that
  are accessible to some agent

52
Protocol Proofs

• First theorem to prove any protocol description
  are possibility properties
• Not assure liveness
• Merely message formats agree from one step to the
  next
• possibility properties for Otway-Rees
• For all agents A, B, distinct from themselves and
  the server, there is a key K, Nonce N and a trace
  such that the final message
• B ! A Na , Na,Kab Ka is sent
• This property can be proved by joining up the
  protocol rules in order and showing that all
  their precondition can be met
• The assertion that nobody sends messages to
  themselves is proved by induction and auto tactic
• 8 A, X . Says A A X ? set_of_list evs

53
Forwarding Lemmas

• Used to reason about steps in which an agent
  forwards an unknown item.
• E.g., a rule for OR2
• Says A B Nonce NA, Agent A, Agent B, X 2
  set_of_list evs
• X 2 analz (sees
  lost Spy evs)
• The proof is trivial since X is transmitted in
  clear
• Sometimes the forwarding party may remove a layer
  of encryption and reveal something to the spy
• E.g., a rule for Oops
• Says S B Nonce NA, X, Crypt (ShrK B) Nonce
  NB, Key K
• 2 set_of_list evs ) Key K 2 parts (sees
  lost Spy evs)

54
Regularity Lemmas

• Concern occurrences of a particular item X as a
  possible message component, so it always has form
  
• X 2 parts (sees lost Spy evs)!
• It impose conditions on the appearance of X in
  any message
• E.g, a basic regularity law
• Key(shrK A) 2 parts (sees lost Spy evs) , A 2
  lost
• this rule states that secret keys remain secret
  unless it is lost

55
Unicity Theorems

• Fresh session keys and nonces uniquely identify
  their messages of origin. But we must exclude the
  possibility of spoof messages
• For session keys, e.g
• 9 B Na Nb X. 8 B Na Nb X.
• Says S B Na, X, Crypt(shrK B)Nb,K
• 2 set_of_list evs !
• B B Æ Na Na Æ Nb Nb Æ X X
• Assume really originated from Server
• K uniquely determines the other four components
• For nonces, e.g
• 9 B. 8 B Crypt(shrK A)Na,Agent A, Agent B
• 2 parts (sees lost Spy evs ) ! B B
• Assume A ? lost
• Na uniquely determines identity of B
• Guarantees are not built into logic but proved

56
Proving Secrecy Theorems Example 1

• E.g 1, with Oops, the compromise of some session
  keys does not compromise other keys
• If K can be analyzed from a set of session keys
  and messages
• Either K is one of those keys
• Or it can be analyzed from the messages alone
• K 2 analz( K sees lost Spy evs) ,
• K 2 K Ç K 2 analz(sees lost Spy
  evs)
• Here K is an arbitrary set of session keys and
  not necessarily present in evs
• If the agents long term keys are not lost, the
  spy cannot get the new session key from the old
  ones

57
Proving Secrecy Theorems Example 2

• E.g 2 step 3 in protocol distributes the session
  key only to A and B
• Assume the server issue key K to A and B
• Says Server B Na,Crypt (ShrK A) Na, K,
• Crypt (ShrK B) Nb, K
  2 set_of_list evs
• Assume A, B ? lost
• Assume K is not lost in an Oops event involving
  the same nonces
• Says B Spy Na, Nb, K ? set_of_list evs
• Then K ? analz(sees lost Spy evs)
• The key is never available to the spy

58
Proving Further Guarantees

• The step 3 secrecy theorem described above is
  worthless on it own
• The attack we have see
• Need further guarantee
• If either A or B receives the expected nonce,
  then the server has indeed sent the critical step
  3
• When prove for this assurance, it failed, which
  suggest the attack

59
A correct protocol

• A ! B Na, A, B, Na, A, BKa
• B ! S Na,A,B, Na, A, BKa, Na,Nb,A, BKb
• S ! B Na, Na,Kab Ka, Nb, Kab Kb
• B ! A Na , Na,Kab Ka

60
Secrecy Bs Guarantee

• Bs guarantee is as follows
• Assume
• B ? lost
• B ? Spy
• if Says B S Na, Agent A, Agent B, X,
  Crypt(ShrK B)Na, Nb, Agent A, Agent B 2
  set_of_list evs
• If Says S B Na, X, Crypt (ShrK B) Nb, Key
  K 2 set_of_list evs
• Then the server has sent a correct instance of
  step 3

61

• Proof requires several subsidiary lemmas
• If the encrypted part of message 2 appears (that
  is Nb), then a suitable version of 2 was actually
  sent
• Nb uniquely identifies the other component of
  message 2s encrypted part(by unicity lemma)
• A nonce cannot be used both as Na and Nb in two
  protocol runs
• If A ? lost then Crypt(ShrK A)Na, Agent A,
  Agent B and Crypt(ShrK A)Na, Na, Agent A,
  Agent A cannot be both in parts(sees lost
  Spy evs)

62
Secrecy As Guarantee

• As guarantee is as follows
• Assume
• A ? lost
• A ? Spy
• if Says B A Na, Crypt(ShrK A)Na, Key K
  2 set_of_list evs
• If A recalls sending
• Says A B Na, Agent A, Agent B, Crypt (ShrK
  A) Na, Agent A, Agent B
• Then the server has sent a correct instance of
  step 3 for some Nb
• The proof process is similar to that for the
  guarantee of B

63
Conclusion

• Two versions of the protocol were studied
• In first version, the participants are not
  assured that the server has distributed the keys
  to the correct agents
• In second version, the participants are assured
  the keys are distributed correctly
• Inductive method for proving properties of a
  protocol is highly automated
• A command can generate tens or hundreds of
  inferences
• Small changes to protocols involve only small
  changes to proof scripts

64
Statistics

• 200 theorems about 10 protocol variants
• ( 3 Otway-Rees, Needham-Schroeder, )
• 110 rules proved concerning messages
• 2-9 minutes CPU time per protocol
• Few hours or days human time per protocol
• Over 1200 proof commands in all

65
Summery

• What Formal Methods Can Do and its limitation
• History of formal methods
• A Case Study Proving Properties of Security
  Protocols by Induction
• theorem prover Isabelle
• Introduced some primary datatypes, simplification
  rule, lemmas
• Prove the secrecy properties of a variant of
  Otway-Rees protocol