Security Protocol Specification Languages

1
Security Protocol Specification Languages

• Iliano Cervesato iliano_at_itd.nrl.navy.mil
• ITT Industries, Inc _at_ NRL Washington DC
• http//www.cs.stanford.edu/iliano/

2
Scope of this Course

• Specification languages for cryptographic
  protocols
• Evaluation criteria
• Anthology of languages
• Scientific impact
• Extras . . .
• Advertisement for MSR

3
This Course is not about

• Cryptography
• Applications of crypto-protocols
• Taxonomy of
• Protocols
• Attacks
• Tools
• Verification

4
Outline

• Hour 1 Specification languages
• Hour 2 MSR
• Hour 3 The most powerful attacker
• Hour 4 Reconstructing the intruder

5

• Hour 1
• Specification Languages

6
Hour 1 Outline

• Security protocols
• Dolev-Yao abstraction
• Specification targets
• Major specification languages
• Origins
• Example (Needham-Schroeder)
• Properties
• Evaluation

7
Security Protocols

• Use cryptographic means to ensure
• confidentiality
• authentication
• non-repudiation,
• in distributed/untrusted environment
• Applications
• e-commerce
• trade/military secrets
• everyday computing

Security goals
8
Why is Protocol Analysis Difficult?

• Subtle cryptographic primitives
• Dolev-Yao abstraction
• Distributed hostile environment
• Prudent engineering practice
• Inadequate specification languages
• the devil is in details

9
Correctness vs. Security Mitchell

• Correctness satisfy specifications
• For reasonable inputs, get reasonable output
• Security resist attacks
• For unreasonable inputs, output not completely
  disastrous
• Main difference
• Active interference from the environment

10
Dolev-Yao Model of Security
Bob
Alice
Network
Server
Dan
Charlie
11
Dolev-Yao Abstraction

• Symbolic data
• No bit-strings
• Perfect cryptography
• No guessing of keys
• Public knowledge soup
• Magic access to data

12
Perfect Cryptography

• KA-1 is needed to decrypt MKA
• No collisions
• M1KA M2KB iff M1 M2 and KA KA

13
Public Knowledge Soup

• Free access to auxiliary data
• Abstracts actual mechanisms
• database
• subprotocols,
• But
• not all data are public
• keys
• secrets

14
pictorially
s
a
ka
kb
15
Why is specification important?
good

• Documentation
• communicate
• Engineering
• implementation
• verification tools
• Science
• foundations
• assist engineering

16
Languages to Specify What?

• Message flow
• Message constituents
• Operating environment
• Protocol goals

17
Desirable Properties

• Unambiguous
• Simple
• Flexible
• Adapts to protocols
• Powerful
• Applies to a wide class of protocols
• Insightful
• Gives insight about protocols

18
Language Families

• Usual notation
• Knowledge logic
• BAN
• Process theory
• FDR, Casper
• Spi-calculus
• Petri nets
• Strands
• MSR

• Inductive methods
• Temporal logic
• Automata
• NRL Prot. Analizer
• CAPSL
• Murf

19
Why so many?

• Convergence of approaches
• experience from mature fields
• unifying problem
• scientifically intriguing
• funding opportunities
• Fatherhood pride

20
Needham-Schroeder Protocol

• But
• purely academic
• attack subject to interpretation

• Devised in 78

• Broken in 95 !

Example of weak specification !
21
Usual Notation
A ? B nA, AkB B ? A nA, nBkA A ?
B nBkB
22
How does it do?
?

• Flow
• Expected run
• Constituents
• Side remarks
• Environment
• Side remarks
• Goals
• Side remarks

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

?
?
?
?
23
BAN LogicBurrows, Abadi, Needham

• Roots in belief logic
• reason about knowledge as prot. unfolds
• security principals share same view
• Specification
• usual notation
• idealized protocol
• assumptions
• Goals
• Verification
• Logical inference

24
NS BAN Idealization
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB
A ? B nAkB B ? A ?A ?nB? B?nAkA A ? B ?A
?nA? B, B ? A ?nB? B ?nBkB
More readable syntax proposed later
25
NS BAN Assumptions

• A ? ?kA A
• A ? ?kB B
• A ? nA
• A ? A ?nA? B

• B ? ?kB B
• B ? ?kA A
• B ? nB
• B ? A ?nB? B

26
NS BAN Goals

• B ? A ? A ?nA? B
• A ? B ? A ?nB? B
• Formally derived from BAN rules

27
How does BAN do?
?

• Flow
• Idealized run
• Constituents
• Assumptions
• Environment
• Implicit
• Goals
• BAN formulas

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

?
?
?
?
28
CSP Roscoe, Lowe

• Roots in
• process algebra Hoare
• non-interference
• Specification
• 1 process for each role
• non-deterministic intruder process
• Verification
• Refinement w.r.t. abstract spec.
• FDR model checker for CSP
• Casper interface to FDR

29
CSP NS Initiator
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB

• Init(A, nA)
• user.A?B -gt I_running.A.B -gt
• comm!Msg1.A.B.encr.key(B).nA.a -gt
• comm.Msg2.B.A.encr.key(A)?nA.nB -gt
• if nA nA
• then comm!Msg3.A.B.encr.key(B).nB -gt
• I_commit.A.B -gt session.A.B -gt Skip
• else Stop

Responder is similar
30
CSP Resp. authentication spec.

• AR0 R_running.A.B -gt I_commit.A.B -gt AR0
• A1 R_running.A.B, I_commit.A.B
• AR AR0 Run (S \ A1)

31
How does CSP do?
?

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

• Flow
• Role-based
• Constituents
• Formalized math.
• Environment
• Explicit
• Goals
• Abstract spec.

?
?
?
?
32
Casper Specification of NS

• Free variables
• A, B Agent
• na, nb nonce
• PK Agent -gt PublicKey
• SK Agent -gt SecretKey
• InverseKeys (PK, SK)
• Processes
• INIT(A,na) knows PK, SK(A)
• RESP(B,nb) knows PK, SK(B)
• Protocol description
• 0. -gt A B
• 1. A -gt B na, APK(B)
• 2. B -gt A na, nbPK(A)
• 3. A -gt B nbPK(B)

Specification Secret(A, na, B) Secret(B, nb,
A) Agreement(A, B, na,nb) Agreement(B,A,
na,nb Actual variables Alice, Bob, Mallory
Agent Na, Nb, Nm Nonce Intruder
information Intruder Mallory IntruderKnowledge
Alice, Bob, Mallory, Nm, PK,
SK(Mallory)
33
Spi-calculusAbadi, Gordon

• p-calculus with crypto. Constructs
• Specification
• 1 process for each role
• Instance to be studied
• Intruder not explicitly modeled
• Verification
• Process equivalence to reference proc.

34
Spi NS Initiator
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB

• init(A,B,cAB,KB,KA-)
• (nnA) cABlt A, nAKB gt .
• cAB(x) . case x of yKA- in
• let (y1,y2) y in y1 is nA
• cABlt y2 KB gt .
• 0

35
Spi NS Responder
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB

• resp(B,A,cAB,KA,KB-)
• cAB(x) . case x of yKB- in
• let (y1,y2) y in y1 is A
• (nnB) cABlt y2, nBKA gt .
• cAB(x) . case x of yKB- in y is nB
• 0

36
Spi NS Instance

• inst(A,B,cAB)
• (nKA) (nKB)
• ( init(A,B,cAB,KB,KA-)
• resp(B,A,cAB,KA,KB-))

37
How does Spi do?
?

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

• Flow
• Role-based
• Constituents
• Informal math.
• Environment
• Implicit
• Goals
• Reference proc.

?
?
?
?
38
Strand SpacesGuttman, Thayer

• Roots in trace theory
• Lamports causality
• Mazurkiewiczs traces
• Specification
• Strands
• Sets of principals, keys,
• Verification
• Authentication tests
• Model checking

39
Strands
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB
40
How do Strands do?
?

• Flow
• Role-based
• Constituents
• Informal math.
• Environment
• Side remarks
• Goals
• Side remarks

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

?
?
?
?
41
Inductive methodsPaulson

• Protocol inductively defines traces
• Specification
• 1 inductive rule for each protocol rule
• Universal intruder based on language
• Verification
• theorem proving (Isabelle HOL)
• Related methods
• Bolignano

42
IMs NS
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB

• NS1 evs ? ns A ? B Nonce NA? used evs
• ? Says A B Nonce NA, Agent A KB evs ? ns
• NS2 evs ? ns A ? B Nonce NB? used evs
• Says A B Nonce NA, Agent A KB ? set
  evs
• ? Says B A Nonce NA, Nonce NA KA evs ? ns
• NS3 evs ? ns
• Says A B Nonce NA, Agent A KB ? set evs
• Says B A Nonce NA, Nonce NA KA ? set evs
• ? Says A B Nonce NA KB evs ? ns

43
IMs Environment

• Nil ? ns
• Fake evs ? ns B?Spy X ? synth(analz (spies
  evs))
• ? Says Spy B X evs ? ns
• synth, analz, spies, protocol indep.

44
How do IMs do?
?

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

• Flow
• Trace-based
• Constituents
• Formalized math.
• Environment
• Immutable
• Goals
• Imposs. traces

?
?
?
?
45
NRL Protocol AnalyzerMeadows

• Roots in automata theory
• Specification
• 1 finite-state automata for each role
• Grammar or words unaccessible to attacker
• Verification
• Backward state exploration
• Theorem proving for finiteness

46
NPA NS Resp., action 2
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB

• Subroutine rec_request(user(B,honest),N,T)
• If rcv msg(user(A,H),user(B,honest),Z,N)
• verify(pke(privkey(user(B,honest)),Z),(W,user
  (A,H))),
• not(verify(W,(W1,W2)))
• Then rec_who user(A,H),
• rec_self user(B,honest),
• rec_gotnonce W
• send msg(user(B,honest),rec_self,rec
  _who,N)
• event(user(B,honest),user(A,H),rec_re
  quest,W,N)

47
How does NPA do?
?

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

• Flow
• Role-based
• Constituents
• Prolog code
• Environment
• Explicit
• Goals
• Unreachable state

?
?
?
?
48
RTLA Gray, McLean

• Roots in Temporal Logic (Lamport)
• Specification
• State components that change during a step
• Verification
• Proof in temporal logic
• Evaluation
• Similar to NPA

49
CAPSL Millen

• Ad-hoc model checker
• Specification
• Special-purpose language
• Intruder built-in
• Implementation
• CIL Denker -gt similar to MSR
• Related systems
• Murf Shmatikov, Stern
• ?? Clarke, Jha, Marrero

50
CAPSL NS
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB

• PROTOCOL NS
• VARIABLES
• A, B PKUser
• Na, Nb Nonce, CRYPTO
• ASSUMPTIONS
• HOLDS A B

MESSAGES A -gt B A, Napk(B) B -gt A
Na,Nbpk(A) A -gt B Nbpk(B) GOALS SECRET
Na SECRET Nb PRECEDES A B Na PRECEDES B
A Nb END
51
How does CAPSL do?
?

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

• Flow
• Explicit run
• Constituents
• Declarations
• Environment
• Implicit
• Goals
• Properties

?
?
?
?
52
Two more

• MSR 1.x
• MSR 2.0
• next hour

53

• Hour 2
• MSR

54
Hour 2 Outline

• Origins
• Language description
• Access control
• Execution model

55
MSR 1.xCervesato, Durgin, Lincoln, Mitchell,
Scedrov

• Multiset rewriting with existentials
• Persistent predicates model assumptions
• Role state predicates thread rules through

56
MSR 1.x - Initiator
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB
Nonce generation

• pA0(A) ? L0(A), pA0(A)
• L0(A), pA1(B) ? ?nA. L1(A,B,nA), N(nA,AkB),
  pA1(B)
• L1(A,B,nA), N(nA,nBkA) ? L2(A,B,nA,nB)
• L2(A,B,nA,nB) ? L3(A,B,nA,nB), N(nBkB)

where pA0(A) Pr(A), PrvK(A,kA-1) pA1(B)
Pr(B), PubK(B,kB)
Messagetransmission
57
MSR 1.x - Responder
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB
Role state predicate

• pB0(B) ? L0(B), pB0(B)
• L0(A), pB1(A), N(nA,AkB) ? L1(A,B,nA), pB1(A)
• L1(A,B,nA) ? ?nB. L2(A,B,nA,nB), N(nA,nBkA)
• L2(A,B,nA,nB), N(nBkB) ? L3(A,B,nA,nB)

Persistent Info.
where pB0(B) Pr(B), PrvK(B,kB-1) pB1(A)
Pr(A), PubK(A,kA)
58
Evaluation

• Poor specification language
• Error-prone
• Limited automated assistance
• Very insightful
• Undecidability of protocol correctness
  verification

59
How did we do?
?

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

• Flow
• Role-based
• Constituents
• Persistent info.
• Environment
• In part
• Goals

?
?
?
?
60
MSR 2.0Cervesato

• Redesign MSR as a spec. language
• Easy to use
• Support for automation
• Margin for verification
• Current techniques can be adapted
• Insightful
• Background in type-theory

61
How will we do?
?

• Unambiguous
• Simple
• Flexible
• Powerful
• Insightful

• Flow
• Role-based
• Constituents
• Strong typing
• Environment
• In part
• Goals

?
?
?
?
62
Whats in MSR 2.0 ?

• Multiset rewriting with existentials
• Dependent types w/ subsorting
• Memory predicates
• Constraints

New
New
New
63
Terms

• Atomic terms
• Principal names A
• Keys k
• Nonces n
• Term constructors
• (_ _)
• _ _ __
• _ _

64
Rules

• N(t) Network
• L(t, , t) Local state
• MA(t, , t) Memory
• c Constraints

• N(t) Network
• L(t, , t) Local state
• MA(t, , t) Memory

65
Types of Terms

• A princ
• n nonce
• k shK A B
• k pubK A
• k privK k
• (definable)

• A princ
• n nonce

66
Subtyping
t msg

• Allows atomic terms in messages
• Definable
• Non-transmittable terms
• Sub-hierarchies

67
Role State Predicates
Ll(A,t, , t)

• Hold data local to a role instance
• Lifespan role
• Invoke next rule
• Ll control
• (A,t, , t) data

68
Memory Predicates
New
MA(t, , t)

• Hold private info. across role exec.
• Support for subprotocols
• Communicate data
• Pass control
• Interface to outside system
• Implements intruder

69
Constraints
New
c

• Guards over interpreted domain
• Abstract
• Modular
• Invoke constraint handler
• E.g. timestamps
• (TE TN Td)
• (TN lt TE)

70
Type of Predicates
Sx t. t

• Dependent sums
• t(x) x t
• Forces associations among arguments
• E.g. princ(A) x pubK A(kA) x privK kA

x
71
Roles

• Genericroles
• Anchoredroles

72
MSR 2.0 NS Initiator
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB
73
MSR 2.0 NS Responder
A ? B nA, AkB B ? A nA, nBkA A ? B nBkB
?B
74
Type Checking
New
? P
G t t
t has type t in G
P is well-typed in S

• Catches
• Encryption with a nonce

• Transmission of a long term key

• Circular key hierarchies,

• Static and dynamic uses

• Decidable

75
Access Control
New
? ? P
r is AC-valid for A in G
P is AC-valid in S
G ?A r

• Catches
• A signing/encrypting with Bs key

• A accessing Bs private data,

• Fully static

• Decidable

• Gives meaning to Dolev-Yao intruder

76
An Overview of Access Control

• Interpret incoming information
• Collect received data
• Access unknown data
• Construct outgoing information
• Generate data
• Use known data
• Access new data
• Verify access to data

77
Processing a Rule
Context
G ?A lhs gtgt D G D ?A rhs G ?A lhs ? rhs
78
Processing Predicates on the LHS
G D ?A t gtgt D G D ?A N(t) gtgt D

• Network messages

G D ?A t1,,tn gtgt D G D ?A MA(t1,,tn) gtgt D

• Memory predicates

79
Interpreting Data on the LHS
G D ?A t1, t2 gtgt D G D ?A (t1, t2) gtgt D

• Pairs

G D ?A k gtgt D G D ?A t gtgt D G D ?A tk
gtgt D

• Encryptedterms

G (D,x) ?A x gtgt (D,x)

• Elementary terms

(G,x?) D ?A x gtgt (D,x)
80
Accessing Data on the LHS
G (D,k) ?A k gtgt (D,k)

• Shared keys

(G,xshK A B) D ?A x gtgt (D,x)
(G,kpubK A,kprivK k) (D,k) ?A k gtgt (D,k)

• Publickeys

(G,kpubK A,kprivK k) D ?A k gtgt (D,k)
81
Generating Data on the RHS
(G, xnonce) (D, x) ?A rhs G D ?A ?xnonce.
rhs

• Nonces

82
Constructing Terms on the RHS
G D ?A t1 G D ?A t2 G D ?A (t1, t2)

• Pairs

G D ?A t G D ?A k G D ?A tk

• Shared-key encryptions

83
Accessing Data on the RHS
G, Bprinc ?A B

• Principal

G, Bprinc, kshK A B ?A k

• Shared key

G, Bprinc, kpubK B ?A k

• Public key

G, kpubK A, kprivK k ?A k

• Private key

84
Configurations
Active roleset
C SRS

• Signature
• a t
• Ll t
• M_ t

• State
• N(t)
• Ll(t, , t)
• MA(t, , t)

85
Execution Model
1-step firing
P ? C ? C

• Activate roles
• Generates new role state pred. names
• Instantiate variables
• Apply rules
• Skips rules

86
Variable Instantiation
SR (?xt.r,r) AS ? SR (t/xr,r) AS
S t t SR (?xt.r,r) AS ? SR
(t/xr,r) AS

• Not fully realistic for verification
• Redundancy realizes typing,
• but not completely

87
Rule Application
r F, c ? ?nt. G(n)

• Constraint check
• ? c (constraint handler)

88
Properties

• Admissibility of parallel firing
• Type preservation
• Access control preservation
• Completeness of Dolev-Yaointruder

New
89
Completed Specifications

• Full Needham-Schroeder public-key
• Otway-Rees
• Neuman-Stubblebine repeated auth.
• OFT group key management

90

• Hour 3
• The Most PowerfulAttacker

91
Hour 3 Outline

• Execution with an attacker
• Specifying the Dolev-Yao intruder
• Completeness of the Dolev-Yao intruder

92
Execution with an Attacker

• P, PI ? C ? C
• Selected principal(s) I
• Generic capabilities PI
• Well-typed
• AC-valid
• Modeled completely within MSR

93
The Dolev-Yao Intruder

• Specific protocol suite PDY

• Underlies every protocol analysis tool

• Completeness still unproved !!!

94
Capabilities of the D-Y Intruder

• Intercept / emit messages
• Split / form pairs
• Decrypt / encrypt with known key
• Look up public information
• Generate fresh data

95
DY Intruder Net Interference

• MI(t) Intruder knowledge

96
DY Intruder Decryption
97
DY Intruder Encryption
98
DY Intruder Pairs
I
MI( t1,t2) ?
MI(t1)MI(t2)
?t1,t2 msg
I
? MI( t1,t2)
MI(t1)MI(t2)
?t1,t2 msg
99
DY Intruder Structural Rules
I
MI( t) ?
MI(t)MI(t)
?t msg
I
MI( t) ? ?
?t msg
100
DY Intruder Data Access

• No nonces, no other keys,

101
DY Intruder Data Generation

• Safe data

• Anything else ?

• It depends on the protocol !!!
• Automated generation ?

102
Completeness of D-Y Intruder

• If P ? SRS ? SRS
• with all well-typed and AC-valid
• Then
• P, PDY ? SRS ? SRS

103
Encoding of P, S, S

• P Remove roles anchored on I
• S Map Is state / mem. pred. using MI
• S Remove Is role state pred. add MI

104
Encoding of R

• No encoding on structure of R
• Lacks context!

• Encoding on AC-derivation for R
• A S ? R
• Associate roles from PDY to each AC rule

105
Completeness Proof

• Induction on execution sequence

• Simulate every step with PDY

• Rule application
• Induction on AC-derivation for R
• Every AC-derivation maps to execution sequence
  relative to PDY

• Rule instantiation
• AC-derivations preserved
• Encoding unchanged

106
DY Intruder Stretches AC to Limit
Well-typed
AC-valid
Dolev-Yaointruder
107
Consequences

• Justifies design of current tools
• Support optimizations
• D-Y intr. often too general/inefficient
• Generic optimizations
• Per protocol optimizations
• Restrictive environments
• Caps multi-intruder situations

108

• Hour 4
• Reconstructing the Intruder

109
Hour 4 Outline

• Access Control ? Dolev-Yao intruder
• MSR specification ? Access Control

110
The Dolev-Yao Intruder Model

• Interpret incoming information
• Collect received data
• Access unknown data
• Construct outgoing information
• Generate data
• Use known data
• Access new data

• Same operations as AC!

111
Accessing Principal Names
G, Bprinc ?A B
112
What did we do?

• Instantiate acting principal to I
• Accessed data ? Intruder knowledge
• Meta-variables ? Rule variables
• Ignore context G

113
Checking it out Shared Keys
G, Aprinc, Bprinc, kshK A B ?A k
dual
114
Getting Confident Pub./Priv. Keys
115
Constructing Messages Pairs
G D ?A t1 G D ?A t2 G D ?A (t1, t2)
116
Now, what did we do?

• Instantiate acting principal to I
• Accessed data ? Intruder knowledge
• Meta-variables ? Rule variables
• Ignore G and knowledge context D
• Premises ? antecedent
• Conclusion ? consequent
• Auxiliary typing derivation gives types

117
Carrying on Shared-Key Encrypt.
G D ?A t G D ?A k G D ?A tk
Similar for public-key encryption
118
Generating Data Nonces
(G, xnonce) (D, x) ?A rhs G D ?A ?xnonce.
rhs
I
? ? ?xnonce. MI(x)
Similarly for other generated data
119
Now, what did we do?

• Instantiate acting principal to I
• Accessed data ? Intruder knowledge
• Meta-variables ? Rule variables
• Ignore G and knowledge context D
• Premises ? antecedent
• Conclusion ? consequent
• Auxiliary typing derivation gives types
• One intruder rule for each AC rule
• Save generated object

120
Interpreting Shared-Key Encrypt.
G D ?A k gtgt D G D ?A t gtgt D G D ?A
tk gtgt D

• Similar for
• public-key encryption
• pairing

121
Now, what did we do?

• Instantiate acting principal to I
• Accessed data ? Intruder knowledge
• Meta-variables ? Rule variables
• Ignore G and knowledge context D
• Premises ? antecedent
• Conclusion ? consequent
• Auxiliary typing derivation gives types
• One intruder rule for each AC rule
• Save generated object
• Premises ? consequent
• Conclusion ? antecedant

122
Network Rules
G D ?A t gtgt D G D ?A N(t) gtgt D
G D ?A t G D ?A N(t)
123
Other Rules?

• Either
• redundant
• or, innocuous (but sensible)

124
Dissecting AC
Constructors atoms ? ? ? ? ? ? ?

• 5 activities
• Interpret messagecomponents on LHS
• Access data (keys) on LHS
• Generate data on RHS
• Construct messages on RHS
• Access data on RHS

125
Accessing Data



126
Generating Data

• Again, annotate types

nonce type
shK princ -gt princ -gt type
127
Interpreting Constructors

• Mark arguments as input or output

128
Annotating Declarations

• Integrates semantics of types and constructors
• Trimmed down version of AC
• Allows constructing AC rules
• Allows constructing the Dolev-Yao intruder

129
alternatively

• Compute AC rules from protocol
• There are finitely many annotations
• Check protocol against each of them
• Keep the most restrictive ones that validate the
  protocol
• Exponential!
• More efficient algorithms?

130
The end

• http//www.cs.stanford.edu/iliano/