Formal Methods for Security Protocols

1
Formal Methods for Security Protocols

• Catuscia Palamidessi
• Penn State university, USA

2
Security Protocols

• Contents of previous lectures
• Brief introduction to security protocols
• Aims and properties
• authentication, secrecy, integrity, anonymity,
  etc.
• Brief introduction to Cryptographic tools
• Symmetric and asymmetric cryptography
• one-way functions, door traps
• Vulnerability of Security protocols
• Next Introduction to Concurrency

3
Brief introduction to Concurrency

• The CSP approach
• Communicating Sequential Processes Hoare 78
• Mathematical framework for the description and
  analysis of systems consisting of processes
  interacting via exchange of messages
• Automatic tools available for proving properties
  of CSP specifications
• Model-checker FDR
• Theorem prover PVS

4
The CSP formalism

• A small mathematical language containing the main
  constructs for specifying concurrency,
  parallelism, communication, choice, hiding etc.
• The evolution of processes is based on a sequence
  of events or actions
• Visible actions S
• Interaction with other processes, communication
• Invisible action t
• Internal computation steps

5
The CSP language Syntax

• Inaction Stop
• Termination, deadlock, incapability of performing
  any action, either internal or external
• Input in ? x A g P(x)
• Execute an input action on channel in, get
  message x of type A, then continue as P(x)
• Output out ! m g P(x)
• Execute an output action on channel out, send
  message m, then continue as P(x)
• Recursion P(y1,,yn) Body(y1,,yn)
• Process definition. P is a process name, y1,,yn
  are the parameters, Body(y1,,yn) is a process
  expression
• Example Copy in ? x g out ! m g Copy

6
The CSP Syntax

• External (aka guarded) choice P Q
• Execute a choice between P and Q. Do not choose a
  process which cannot proceed
• Example (a ? x g P(x)) (b ? x g Q(x))
• Execute one and only one input action. If only
  one is available then choose that one. If both
  are available than choose arbitrarily. If none
  are available then block. The unchoosen branch is
  discarded (commitment)
• Internal choice P Q
• Execute an arbitrary choice between P and Q. It
  is possible to choose a process which cannot
  proceed

7
The CSP Syntax

• Parallel operator w/synchronization P Q
• P and Q proceed in parallel and are obliged to
  synchronize on all the common actions
• Example (c ? x g P(x)) (c ! m g Q)
• Synchronization the two processes can proceed
  only if their actions correspond
• Handshaking sending and receiving is
  simultaneous (clearly an abstraction. Buffered
  communication can anyway be modeled by
  implementing a buffer process)
• Communication m is transmitted to the first
  process, which continues as P(m).
• Broadcasting c ! m is available for other
  parallel procs
• Question what happens with the process
• ((c?xgP(x)) (d?y gQ(y)))
  (c!m gR)

8
The CSP Syntax

• Parallel operator w/synchronization and
  interleaving P AQ
• P and Q are obliged to synchronize only on the
  common actions in A
• They interleave on all the actions not in A
• Example (c ? x gP(x)) c ((c ! m gQ) (d !
  n g R))
• the two processes can either synchronize on the
  action on channel c, or the second process can
  perform an action on d. In this second case the
  first process will remain blocked, though, until
  the second will decide to perform (if ever) an
  output action on c.
• Question in what part of the second process
  could this action on c be performed ?
• Abbreviation P Q stands for P f Q

9
The CSPs Syntax

• Hiding P \ A
• P \A behaves as P except that all the actions in
  A are turned into invisible actions. So they
  cannot be used anymore to synchronize with other
  processes.
• One possible use of this mechanism is to avoid
  that external processes interfere with the
  communication channels in P. (Internalization of
  communication in P.)
• Renaming Py/x
• Px/y behaves as P except that all the
  occurrences of x are renamed by y.
• Typically this serves to create different
  instances of the same process scheme
• Abbr Py1,y2 /x1,x2 will stand for
  Py1/x1y2/x2

10
Modeling Security Protocols in CSP

• Security protocols work through the interaction
  of a number of processes in parallel that send
  messages to each other. A formalism for
  concurrency is therefore an obvious notation for
  describing the participants and their role in the
  protocol
• Example The Yahalom protocol
• Message 1 a g b a.na
• Message 2 b g s b.a.na.nbServerKey(b)
• Message 3 s g a b. kab.na.nbServerKey(a)
  .a.kabServerKey(b)
• Message 4 a g b a. kabServerKey(b)
  .nbkab

11
Modeling Security Protocols in CSP

• We assume that each process has channels
• Receive
• Send
• that it uses for all communications with the
  other nodes via the medium
• Let us assume that A (Alice) and B (Bob) use the
  protocol, with A as initiator and B as
  responder, and that J (Jeeves) is the secure
  server

12
Modeling Security Protocols in CSP

• A s view (initiator)
• Message 1 a sends to b a.na
• Message 3 a gets from j b. kab.na.nbServerKey
  (a) .a.kabServerKey(b)
• Message 4 a sends to b a. kabServerKey(b)
  .nbkab
• In CSP this behavior can be modeled as follows
• Initiator(a,na )
• env?b Agent
• g send.a.b.a.na
• g (receive.J.ab. kab.na.nbServerKey
  (a) .m
• kab e Key g
  send.a.b.m.nbkab g Session(a,b,kab,na,nb) )
• nb e Nonce
• m e T

13
Modeling Security Protocols in CSP

• B s view (responder)
• Message 1 b gets from a a.na
• Message 2 b sends to j b.a.na.nbServerKey(b)
• Message 4 b gets from a a. kabServerKey(b)
  .nbkab
• In CSP this behavior can be modeled as follows
• Responder(b,nb )
• (receive.a.b.a.na g send.b.J.b
  .a.na.nbServerKey(b)
• kab e Key g receive.a.b.a.
  kabServerKey(b) .nbkab
• nb e Nonce g Session(b,a,kab,na,nb) )
• m e T

14
Modeling Security Protocols in CSP

• Js view (server)
• Message 2 j gets from b b.a.na.nbServerKey(
  b)
• Message 3 j sends to a b. kab.na.nbServerKey
  (a) .a.kabServerKey(b)
• In CSP this behavior can be modeled as follows
• Server(J,kab )
• (receive.b.J.b .a.na.nbServerKey(b)
• A,B e Agent g send.J.a. b.
  kab.na.nbServerKey(a) .a.kabServerKey(b)
• Nb ,nb e Nonce g Server(J,ks ) )
• Server(J) Server(J,kab )
• kab e KeysServer
• Question why several server processes in
  parallel?

15
Modeling an intruder

• We want to model an intruder that represents all
  potential intruder behaviors
• Intruder(X) learn ? m messages
  gIntruder(close(X U m)
• say ! m X /\
  messages gIntruder(X)
• Close(X) represents all the possible information
  that the attacker can infer from X. Typically we
  assume
• Dolew-Yao Assumptions
• k , m - mk
• mk , k-1 - m
• ltx1, ,xngt - xi
• x1 , , xn - ltx1,,xngt

16
Putting the network together
Initiator(Alice,nA)fake,take/receive,send Re
sponder(Bob,nB)fake,take/receive,send Server
(Jeeves)fake,take/receive,send Intruder(f)t
ake.x.y,fake.x.y/learn,say
Bob
receive
send
Jeeves
Alice
fake.x.Bob
receive
send
receive
send
say
Yves
learn
take.Alice.y
17
Alternative with direct channels
S fake,comm,take,comm,/receive,send,receive,send

• Initiator(Alice,nA)S
• Responder(Bob,nB)S
• Server(Jeeves)S
• Intruder(f)S

Bob
receive
send
Comm.Alice.Bob
Jeeves
Alice
fake.x.Bob
receive
receive
send
send
say
Yves
learn
take.Alice.y
18
Expressing Security Properties in CSP

• Security properties the goals that a protocol is
  meant to satisfy, relatively to specific kinds
  and levels of threat the intruders and their
  capabilities
• We will consider the following security
  properties
• Secrecy
• messages, keys, etc. have not become known
• Authentication
• Guarantees about the parties involved in the
  protocol
• Non-repudiation
• Evidence of the involvement of the other party
• Anonymity
• Protecting the identity of agents wrt particular
  events

19
Anonymity

• We will model events as consisting of two
  components the event itself, x, and the identity
  of the agent performing the event, a
• a.x
• AnUsers the users who want to remain secret
• Given x, define A a.x a e AnUsers
• Definition A protocol described as a CSP system
  P provides anonymity if an arbitrary permutation
  of the events in A, applied to all the traces of
  P, does not alter the set of all possible traces
  of P

20
Anonymity

• Traces of a process the sequences of visible
  actions in all possible runs
• Example a -gt b -gt Stop c -gt d -gt Stop
• Traces a.b.c.d a.c.b.d c.a.b.d
  a.c.d.b c.a.d.b c.d.a.b
• Example a -gt b -gt c -gt Stop b d -gt b -gt
  e -gt Stop
• Traces a.d.b.c.e d.a.b.c.e a.d.b.e.c
  d.a.b.e.c

21
Anonymity

• Let AnUsers p1,p2
• Let A p1.m, p2.m
• Example 1 p1.m -gt p2.m -gt Stop
• Example 2 p1.m -gt Stop p2.m -gt Stop
• Example 3 p1.m -gt Stop p2.m -gt Stop
• Question for each system, say whether or not it
  provides anonymity wrt A

22
Anonymity

• A more involved example
• P p1. m -gt a -gt Stop p2. m -gt a -gt Stop
• p1.m , p2.m
• p1. m -gt b -gt Stop p2. m -gt c -gt Stop
• Question Does P provides anonymity wrt
• A p1.m, p2.m

23
Anonymity

• Answer No
• P has traces (p1.m).b.a , (p2.m).c.a ,
• but not (p2.m).b.a , (p1.m).c.a ,
  
• The permutation p1 -gt p2 , p2 -gt p1
  changes the traces.
• However, if we assume that the observer has no
  visibility of the actions b and c, then the
  system does provide anonymity wrt A p1.m,
  p2.m
• One elegant way to formalize the concept of
  visibility in CSP is to use the the hiding
  operator
• P\b, c provides anonymity wrt A
• Note Hiding A would not be correct. Example
  p1.m -gt Stop

24
Anonymity

• In general, given P, consider the sets
• A a.x a e AnUsers the actions that we
  want to know only partially (we want to know x
  but not a)
• B the actions that we want to observe
• C Actions (B U A) The actions we want to
  hide

A
The system to consider for the Anonymity
analysis P\C Method for any perm r A -gt
A Check that r (traces(P\C)) traces(P\C)
B
C
?
25
The dining cryptographers

• Three cryptographers share a meal
• The meal is paid either by the organization
  (master) or by one of them. The decision on who
  pays is taken by the master
• Each of them is informed by the master whether or
  not he is paying
• GOAL The cryptographers would like to know
  whether the organization is paying or not, but
  without knowing the identity of the cryptographer
  who is paying (if any).

26
The dining cryptographers

• Solution Each cryptographer tosses a coin. Each
  coin is in between two cryptographers.
• The result of each coin-tossing is visible to the
  adjacent cryptographers, and only to them.
• Each cryptographer examines the two adjacent
  coins
• If he is not paying, he announces agree if the
  results are the same, and disagree otherwise.
• If he is paying, he says the opposite
• Claim if the number of disagree is even, then
  the master is paying. Otherwise, one of them is
  paying. In the latter case, the non paying
  cryptographers will not be able to deduce whom
  exactly is paying

27
Example The dining cryptographers
Crypt(0)
pays.0
notpays.0
Coin(0)
Coin(1)
look.2.0
Master
out.1
Crypt(1)
Crypt(2)
Coin(2)
28
The dining cryptographers

• Specification in CSP Master and Coins
• Master
• Sn pays.n -gt notpays.(n1) -gt notpays (n2) -gt
  Stop
• notpays.0 -gt notpays.1 -gt notpays.2 -gt Stop
• Coin(n) Heads(n) Tails(n)
• Heads(n) look.n.n.hd -gtStop
  look.(n-1).n.hd -gtCoin(n)
• Tails(n) look.n.n.tl -gt Stop
  look.(n-1).n.tl -gtCoin(n)
• Note the arithmetic operations are modulo 3

29
The dining cryptographers

• Specification in CSP Cryptographers
• Crypt(n) notpays(n) -gt Check(n)
• pays(n) -gt Check(n)
• Check(n) look.n.n?x -gt look.n.(n1)?y -gt
• if (xy) then
  out.n. agree -gt Stop
• else
  out.n. disagree -gt Stop
• Check(n) look.n.n?x -gt look.n.(n1)?y -gt
• if (xy) then
  out.n. disagree -gt Stop
• else
  out.n. agree -gt Stop

30
The dining cryptographers

• Specification in CSP The whole system
• Crypts Crypt(0) Crypt(1) Crypt(2)
• Coins Coin(0) Coin(1) Coin(2)
• Meal Master pays, notpays ( Coins
  look Crypts )

31
The dining cryptographers

• The anonymity property
• A pays.0, pays.1, pays.2
• B out
• C Actions (B U A) look,notpays
• Theorem For every permutation r A -gt A, we
  have
• r(Traces(Meal\C)) traces(Meal\C)
• This theorem means that an external observer
  cannot infer which cryptographer has paid.
• This theorem can be proved by using the automatic
  tool FDR.

32
The dining cryptographers

• One can argue that previous result is not strong
  enough a cryptographer has more information than
  an external observer. Let us then do the analysis
  for a cryptographer, say Crypt(0)
• A pays.1, pays.2
• B pays.0, notpays.0, look.0, out
• C Actions (B U A)
• Theorem For every permutation r A -gt A, we
  have
• r(traces(Meal\C)) traces(Meal\C)
• This means that if Crypt(1) or Crypt(2) pay, then
  Crypt(0) cant infer which of them has paid. The
  same can be shown for the other two. So Meal\C
  provides the desired anonymity property.

33
The dining cryptographers

• Example of a case in which the anonymity property
  does not hold.
• Assume that Crypt(0) can access the result of the
  third coin, namely has visibility of the result
  of the action look.2.2
• A pays.1, pays.2
• B pays.0, notpays.0, look.0, out U
  look.2.2
• C Actions (B U A)
• We have that for some permutation r A -gt A,
• r(traces(Meal\C)) / traces(Meal\C)
• pays.2 notpays.0 look.00.heads look.0.1.heads
  look.2.2.heads out.2.disagree YES
• pays.1 notpays.0 look.00.heads look.0.1.heads
  look.2.2.heads out.2.disagree NO