Modeling Security Protocols in CSP

1
Modeling Security Protocols in CSP
ISA 763- Fall 2007
Chapter 2 and 3 of Ryan and Schneider Thanks to
Professor Catuscia Palamidessis notes
2
Example The Yahalom Protocol

• The protocol
• Message 1 a -gt b a.na
• Message 2 b -gt s b.a.na.nbServerKey(b)
• Message 3 s -gt a b.kab.na.nbServerKey(a)
  a.kabServerKey(b)
• Message 4 a -gt b a.kabServerKey(b) .nbkab
• Objectives
• Authentication of the participants
• Kab should remain secret
• Secrecy also on na, nb,

3
Three Views of the Participants

• The Initiator (A)
• A? b a.na
• A? j b.kab.na.nbServerKey(a
  . a.kabServerKey(b)
• A? b a.kabServerKey(b) .nbkab

• The Responder (B)
• B? a a.na
• B? j a.na.nbServerKey(b)
• B ? a a.kabServerKey(b) .nbkab

• The Server Jeeves ( J)
• J? b b. a.na.nbServerKey(b)
• J? a b.kab.na.nbServerKey(Ka).
  a.kabServerKey(b)

4
Objectives

• Develop CSP programs for all three roles
• Take the process through the protocol
• In each role
• Alternate between sending and receiving
• Each process will
• Generate keys
• Generate nonces
• Perform encryption and decryption

5
Encoding - I

• Encryption function encrypt(k,m)
• Decryption function dcrypt(k,m)
• Keys serverKey(b)
• shared between server and b
• Other cannot understand it!

6
Encoding - II

• A CSP process that understands only messages of
  the kind kab
• ? kab? Key recieve.a.B.(a.kabserverKey(b).n
  B.kab) ? P(B,a,nB, kab)
• One that aborts on an incorrect message
• ? kab?Key recieve.a.B.(a.kabserverKey(B).nB
  kab) ? P(B,a,nB, kab)
• ? AbortRun(B)
• Above can be written in the a? x format of CSP.

7
Initiator the initial version

• Initiator(a,na)
• env?b Agent
• g send.a.b.a.na g
• receive.J.ab.kab.na
  .nbServerKey(a)..a.kabkb.
• kab?Key g send.a.b.a.kabkab
• nb?Nonce g Session(a,b,kab,na,nb)
• m?T

8
Responder the initial version

• Responder(b,nb)
• receive.a.b.a.na g
• send.b.J.b.a.na.nbServerKey(b) g
• kab?Key receive.a.b.a.kabServerKey(b).a.n
  bkab
• a?Agent g Session(b,a,kab,nb,na)
• na?Nonce

9
The Server Jeeves

• Server(J,Kab )
• receive.b.J.ba.nanbServerKey(
  b) g
• send.J.a.b.kab.nanbServerKey(a)
• kab?Key
  a.kabServerKey(b)
• a,b?Agent
• na,nb?Nonce
• Server(J) Server(J,Kab)
• kab?KeyServer

10
Users

• To model disjoint sets of nonces, we define two
  sets Nonce_Ia and Nonce_Ib
• Define Users Anne and Bob as Useranne and
  UserBob where
• Usera Initiator(a,n) Responder(b,n)
• n? Nonce_Ia n? Nonce_Ib

11
Data Types

• CSP operates over abstractly specified data
  types, and not their (bit-pattern)
  representations
• Use notations like Encrypt.k.(Sq.lta,nagt)
• Syntax fact Encrypt.fact.fact
• Hash.fact.factSq.fact
• Key.kNonce.nText.t
• Abbreviations Write km for Encrypt.k.m and
  g(m) for Hash.g.m, k for Key.k, n for Nonce.n,
  t for text.t and ltm1,mngt for Sq.ltm1,mngt, m1.m2
  for ltm1,m2gt.
• Note Sq stands for sequence.

12
The Intruder Process

• The intruder is modeled as a process that
  communicates over channels with Alice and Bob
  non-deterministically at will
• The intruder builds its knowledge-base of facts
  by learning the facts that come over the channels
  and logical reasoning
• Intruder(X) intruder that knows X a
  collection of predicate instances
  (knowledge-base)
• Intruder process Intruder(X)
• learn?mmessage?Intruder(Close(XUm)
• ? say!mmessagenX ? Intruder(X)
• Close (X) deductive closure of X

13
Proof Rules for Intruder Deductions

• k,m ? encrypt(k,m)
• encrypt(k,m), k-1 ? m
• Sq., x, ? x
• x1,xn ? Sqlt x1,xngt
• Can form the deductive closure with these rules
  and others from Predicate Logic.

14
Constructing the Network

• Reliable agents Alice, Bob, server Jeeves
• Intruder Yves
• Network Connections
• Send.a.b.m An event inside a reliable agent
• matched up with learn.m learn channel name
  event of the intruder
• Receive.a.b.m An event inside a reliable agent
• matched up with say.m saychannel name event of
  the intruder
• Send and learn channels are connected (by
  renaming) to the external take channel
• Receive and say channels are connected (by
  renaming) to the fake channel of the intruder

15
Network Connections
Jeeves
send
receive
Anne
Bob
send
receive
send
receive
fake.x.Bob
take.Anne.y
learn
say
Yves
leak
16
Network Connections

• Sender and receiver fields of the intruder are
  missing in the intruder
• because conveys no useful information to the
  intruder
• So learn.m is mapped to all take.a.b.m of all
  legitimate choices of a and b
• So say.m is mapped to all fake.a.b.m of all
  legitimate choices of a and b pretending to be
  from b
• Internally, agents and map take and fake to send
  and receive.
• So send, receive, learn and say are internal
  names and take and fake are external channel
  names.

17
Network Connections

• Agent(anne) fake,take/receive,send
• Agent(bob) fake,take/receive,send
• Jeeves fake,take/receive,send
• Yvestake.x.y,fake.x.y/learn,sayx,y?Agen
  tsUJeeves
• take,fake
• The dotted lines in the picture represents
  renaming

18
A Sample Run - 1
Externally Agent Which sees Intruder
Take.A.C.m A Send. A.C.M Learn.SqltA,Nagt SqltA,Nagt ? Na A,Na,Nc ? SqltA,Na,Ncgt SqltA,Na,Ncgt, ServerKey(C) ? SqltA,Na,Ncgt ServerKey(C) C, SqltA,Na,NcgtServerKey(C) ?Sq.ltC,SqltA,Na,NcgtServerKey(C)gt
19
A Sample Run -2
Externally Agent Which Sees Intruder
fake.C.J.m J receive.C.J.m Say. Sq.ltC,SqltA,Na,NcgtServerKey(C)gt
take.J.A.m J send.J.A.m Say. Sq.ltSqltC,K,Na,NcgtServerKey(A), ltA,Kgt ServerKey(C)gt
fake.J.A.m A receive.J.A.m learn.Sq.ltSqltC,K,Na,NcgtServerKey(A), ltA,Kgt ServerKey(C)gt
take.A.C.m A receive.J.A.m learn.ltltA,Kgt ServerKey(C),NcKgt
20
Direct Communication

• Need to allow direct communication between agents
  without Intruder interference
• Make take and fake alternatives to the original
  communication
• RenAgent(A)
• Agent(A)fake,com,take,com /
• receive,receive,send,send
• Com provides an alternative channel for honest
  agents to communicate.

21
Improved Network Connections
Jeeves
send
receive
Anne
Bob
Com.Anne.Bob
send
receive
send
receive
fake.x.Bob
take.Anne.y
learn
say
Yves
leak
22
Specifying Protocol Goals

• Chapter 3 of Ryan and Schneider

23
Protocol Security Objectives

• Participants modeled as participant processes.
• Attackers modeled as Intruder processes.
• What objectives should the protocol satisfy in
  the presence of the intruder?
• Secrecy Item m is intended to be a secret until
  the end of the protocol.
• Authenticity When completed, some guarantees are
  needed about the participation of some parties
  the protocol is apparently run with.
• Non-repudiation Evidence of the involvement of
  the other party
• Anonymity Protecting the identity of agents with
  respect to particular events

24
Secrecy

• At some point in the protocol a signal
  Claim_secret.M will be inserted into the protocol
  by means of a Signal a special channel to make
  secrecy claims
• Signals are not facts. Signal n Fact Ø
• Information appearing on the Signal channels are
  claims expressing the claimants conditions.
• Can specify secrecy claims (such as trace
  properties) without this channel, but is more
  complex.

25
Secrecy
B
A
Intr
Protocol run
Claim_Secret.m
26
Secrecy of the Yahalom Protocol

• Expand Yahalom to Yahalom by inserting secrecy
  claims
• Secrecy claims signal.Cliam_Secret.a.b.s
• Says at this point in a s run apparently with
  b, the protocol guarantees that Yves cannot
  obtain s.

27
The Initiator with Signals

• Initiator(a,na )
• env?b Agent
• g send.a.b.a.na g
• receive.J.ab.kab.na.nbSe
  rverKey(a).m
• kab?Key g send.a.b.m.nbkab
• nb?Nonce g signal.Cliam_Secret.a.b.kab
• m?T g Session(a,b,kab,na,nb)

28
Responder the initial version

• Responder(b,nb )
• receive.a.b.a.na g
• send.b.J.b .a.na.nbServerKey(b) g
• kab?Key receive.a.b.a. kabServerKey(b).nbk
  ab
• na?Nonce ? signal.Claim_Secret.a.b.kab
• a?Agent gSession(b,a,kab,na,nb) )

29
The Leak Channel

• In order to check if Kab appears on the say
  channel, we can check that by copying its
  messages into a leak channel.
• The trace Secret can be expressed as the trace
  property
• Secretab(tr) ?ssignal Claim_Secreta.b.s. in tr
  ? (leak.s. in tr)

30
Where to insert the signal?

• A process should signal Claim-Secret..s as soon
  as sees s called strong secrecy
• Sometimes a secret created within a protocol run
  and used only if the protocol terminates without
  problems.
• For example session keys useless unless the
  protocol runs to completion
• Then Signal.Claim-Secret..s should be placed at
  the end of the protocol.

31
Authentication
32
Authentication in CSP

• Insert two signals to the protocol
• Running.a.b in as protocol
• a is executing a run apparently with b
• Commit.b.a in bs protocol
• b completed a protocol run apparently with a

33
Authentication
B
A
Intr
Run with A
Commit with B
34
Authentication in CSP

• Authentication is achieved if Running.a.b always
  precedes Commit.b.a in all traces of the system
• Weaker or stronger forms of authentication can be
  achieved by varying the parameters of these
  signals and their constraints

35
Authentication in Yahalom

• The Yahalom Protocol wants to authenticate both
  parties to each other
• Requires two separate enhancements to the
  protocol
• We will analyze the two authentication properties
  separately

36
Authenticating the Initiator - 1

• Initiator(a,na )
• env?b Agent
• g send.a.b.a.na
• g
  (receive.J.ab. kab.na.nbServerKey(a) .m
• kab ? Key g
  signal.Running_Initiator.a.b.na.nb.kab
• nb? Nonce g
  send.a.b.m.nbkab
• m? T g
  Session(a,b,kab,na,nb) )
• Responder(b,nb )
• 
  (receive.a.b.a.na g send.b.J.b .a.na.nbServerKey
  (b)
• kab?Key g receive.a.b.a.
  kabServerKey(b) .nbkab
• nb e Nonce g signal. Commit_Responder.b.a.na.nb.k
  ab
• m?T g Session(b,a,kab,na,nb) )

37
Authenticating the Initiator - 2
Server
Initiatora
Responderb

• a.na

• b.a.na.nbServerKey(b)

• b.kab.na.nbServerKey(a) a.kabServerKey(b)

• Run_Init.a.b.na.nb.kab

• a.kabServerKey(b) .nbkab

• Com_Resp.b.a.na.nb.kab

38
Authenticating the Initiator - 3

• Property to be verified
• signal. Running_Initiator.a.b.na.nb.kab
• precedes
• signal.Commit_Responder.b.a.na.nb.kab
• in all the Traces(System)
• Again, this property can be verified
  automatically by checking all traces

39
Authenticating the Responder -1

• Initiator(a,na )
• env?b Agent
• g send.a.b.a.na
• 
  (receive.J.ab. kab.na.nbServerKey(a) .m
• kab?Key g
  send.a.b.m.nbkab
• nb?Nonce g
  signal.Commit_Initiator.a.b.na.nb.kab
• m?T g
  Session(a,b,kab,na,nb) )
• Responder(b,nb )
• 
  (receive.a.b.a.na g send.b.J.b .a.na.nbServerKey
  (b)
• kab?Key g signal. Running_Responder.b.a
  .na.nb
• nb?Nonce g receive.a.b.a. kabServerKey(b)
  .nbkab
• m?T g Session(b,a,kab,na,nb) )

40
Authenticating the Responder -2
Server
Initiatora
Responderb

• a.na

• Run_Resp.b.a.na.nb.

• b.a.na.nbServerKey(b)

• b.kab.na.nbServerKey(a) a.kabServerKey(b)

• a.kabServerKey(b) .nbkab

• Run_Init.a.b.na.nb.kab

41
Authenticating the Responder-3

• The property to be verified
• signal. Running_Responder.b.a.na.nb
• precedes
• signal.Commit_Initiator.a.b.na.nb.kab
• in all possible Traces(System)
• Again, this property can be verified
  automatically by checking the traces

42
Forms of Authentication Objectives

• From Sections 4 and 5 of Gavin Lowes paper on
  a hierarchy of authentication specifications
• Recap of specifications
• Agreeement(B-role,A-role,ds)(B) where
• B-role Role of agent being authenticated
• A-role Role of the recipient of authentication
• ds data items agreed upon for authentication
• B identity of agent being autheticated

43
Authentication Agreements

• Agreeement(B-role,A-role,d1,d2)(B)
• XXXXX..
• signal.Running.B-role.B?A?d1?d2 ?
• XXXXX.
• signal.Commit.A-role.A.B.d1.d2 ? stop
• Objective In all traces, signal.Running precedes
  signal.Commit.
• Can be stated as a refinement statement
• Agreeement(B-role,A-role,d1,d2)(B) ?T
• SYSTEM \ (S - aAgreement)

44
Recall Trace Semantics

• Recall P ?T Q if trace(Q) ? trace(P)
• P \ S removing all events in S from P
• So Agreeement(B-role,A-role,d1,d2)(B) ?T
• SYSTEM \ (S - aAgreement) is
  valid if all symbols that do not belong to the
  alphabet of Agreement are removed from system
  traces, then the remaining system traces must be
  a subset of that of Agreeement(B-role,A-role,d1,d
  2)(B) .
• Written as
• SYSTEM sat Agreeement(B-role,A-role,d1,d2)(B)
  or
• SYSTEM meets Agreeement(B-role,A-role,d1,d2)(B)

45
Generalizing Authentication

• Agents agreeing on some data, not others
• Agreeement(B-role,A-role,d1)(B)
• signal.Running.B-role.B?A?d1?d2 ?
• signal.Commit.A-role.A.B.d1.?d2 ? stop
• Commitment based on d1 but not d2.
• Lemma ds2 ? ds1 implies
• SYSTEM sat Agreeement(B-role,A-role,ds1)(B) ?
  SYSTEM sat Agreeement(B-role,A-role,ds2)(B)

46
Non-injective agreements

• Allow A to commit on every run of B
• NI-Agreement(B-role,A-role,d1,d2)(B)
• signal.Running.B-role.B?A?d1?d2 ?
• RUN(signal.Commit.A-role.A.B.d1.?d2)
• ? stop
• One instance of Running by B-role, A-role runs as
  many runs as possible !
• Similarly, NI-Agreement(B-role,A-role,d1,d2)(B)n
  allows the protocol to be run at most n times,
  but allows any number of runs of B to match with
  a single run of A

47
More properties of agreements

• Lemma ds2 ? ds1 implies
• SYSTEM sat NI-agreeement(B-role,A-role,ds1)(B) ?
  SYSTEM sat NI-agreeement(B-role,A-role,ds2)(B)
• Lemma If
• SYSTEM sat Agreeement(B-role,A-role,ds1)(B) then
  SYSTEM sat NI-agreeement(B-role,A-role,ds2)(B)

48
A weaker version of non-injectivity

• Agents agreeing on some data, not others
• Agreeement(B-role,A-role,d1)(B)n
• signal.Running.B-role.B?A?d1?d2 ?
• signal.Commit.A-role.A.B.d1.?d2 ? stopn
• Agreement completed in n runs, but each commit is
  matched by only one run.

49
Weak agreements

• No guarantee on Bs role and data
• WeakAgreement(B-role,A-role,d1,d2)(B)
• signal.Running.?B-role.!B?A?ds ?
• RUN(signal.Commit.A-role.A.B.dsds?Data)
• ? stop
• A completes play A-role an arbitrary number of
  runs if B runs at least once playing some role
  using some data values

50
Weak vs. Non-injective

• SYSTEM sat WeakAgreement(B-role,A-role,d1,d2)(B)
  n specify a system satisfying a week agreement in
  n rounds
• Lemma If
• SYSTEM sat NI-agreeement(B-role,A-role,ds2)(B)m
  then SYSTEM sat WeakAgreement(B-role,A-role,d1,d2
  )(B)mn

51
Aliveness

• A further weakening
• A receives no guarantee that B was running the
  same protocol with A
• Only that B was running the protocol with someone
• Aliveness(A-role)(B)
• signal.Running?B-role!B?C?ds ?
• RUN(signal.Commit.A-role.A.B.ds ds?Data
  /\ A?Agent ) ? Stop
• Agreement SYSTEM sat Aliveness(a-role)(B)

52
Aliveness vs. Weak-agreement

• Lemma If
• SYSTEM sat WeakAgreement(B-role,A-role,d1,d2)(B
  )n then
• SYSTEM sat Aliveness(a-role)(B)n

53
Agreeing on the Protocol

• Use an extra field for the protocol ID
• Aliveness(ProtId,A-role)(B)
• signal.Running.protId?B-role!B?C?ds ?
• RUN(signal.Commit.protId.A-role.A.B.ds
  ds?Data /\ A?Agent ) ? Stop
• Running different protocols
• Aliveness(?ProtId,A-role)(B)
• signal.Running.protId?B-role!B?C?ds ?
• RUN(signal.Commit.protId.A-role.A.B.ds
  ds?Data /\ A?Agent ) ? Stop

54
Recentness

• Two approaches
• Using nonces
• Using time
• Need another field in agreements
  Agreement(Resp-Role, Init-role, Na,Nb)(Bob)m
• Assumptions
• A and B invented Nonces Na and Nb not too distant
  in the past
• Nonces are new i.e. have not been used in the
  recent past

55
Timed Authentication

• Need to authenticate within a time window
  AuthTime.
• Each agent has a built-in timeout MaxRunTime.
• Requires a discrete clock
• Add timeouts to un-timed versions of
  authentication objectives

56
Clocks

• Tock(n) performs at most n tocks
• Tock(n) If n 0 then SKIP
• else (tock?Tock(n-1)? SKIP),
• TSKIP tock?TSKIP ? SKIP
• AddTime(P,MaxRunTime)
• tock?AddTime(P,MaxRunTime) ?
• ( (P Tock(MaxRunTime) ) ? tock?TSKIP)
• Q ? P initially acts like Q but on receiving
  interrupt act like R

57
Timed Authentication

• TimedAgreeement(B-role,A-role,ds,AuthTime)(B)
• AddTime(Agreement(B-role,A-role,ds)(B),AuthTime)
• The process allows at most AuthTime tocks to
  occur between the Running and Commit events
  i.e. during the execution Agreement(B-role,A-Role,
  ds).
• Specification
• SYSTEM sat TimedAgreeement(B-role,A-role,ds,AuthT
  ime)(B)n
• Need to redefine Pn P tock P tock
  . tock P
• Other un-timed specifications can be enriched to
  have timed versions

58
Properties of timed Authentication

• If ds ? ds and
• SYSTEM sat TimedAgreeement(B-role,A-role,ds,AuthTi
  me)(B)n, then
• SYSTEM sat TimedAgreeement(B-role,A-role,ds,Auth
  Time)(B)n
• Similar results hold for other timed versions of
• TimedNonInjectiveAgreement
• TimedWeakAgreement
• TimedAliveness

59
Monotonicity of Timed Specs

• If TimedSpec(_) stands for any of the specified
  timed authentication specifications and t lt t,
• and SYSTEM sat TimedSpec(t)
• then
• SYSTEM sat TimedSpec(t)

60
Un-timed vs. Timed Specs

• Suppose TimedSpec(_) is the timed version of
  Spec(_) and
• SYSTEM sat TimedSpec(t,_)
• then,
• SYSTEM sat Spec(_)

61
Non-repudiation
62
Non-repudiation Objectives

• Provide the parties of an interaction with
  evidence so that later they cannot deny having
  participated
• Participants and trust
• May not trust each-other.
• Different from previous models
• Can derive facts
• Attackers are different
• Could live in the media
• Participants could be attackers.

63
Signals and Arguments of Evidence

• evidence.a.m agent a signals receipt of
  evidence of message m
• Agenta(S)
• ?b?Agent, m?S send.a.b.m -gt Agenti(S)
• ? receive.b.a?.?m -gt Agenta(close(S U m))
• ? ? m?S evidence.a.m -gt Agenti(S)
• System( b?Agent Agenti(IKa) Medium(IKm))
• Close (S) Deductive closure of knowledge
• Argument evidence.a..m in tr ? b sent m

64
Sending and Agent Knowledge

• a sent m ? Mfact bAgent
• send.a.b.m/\ (mcontains m)
• Axioms for contains
• m contains m
• m contains m ? m.m contains m
• m contains m ? m.m contains m
• m contains m ? k(m) contains m

65
The Zhou-Gollmann Protocol -1

• Message 1 a -gt b fNRO .b.l.cSka
• // send an encrypted msg C with run l, recipient
  b
• Message 2 b -gt a fNRR .a.l.cSkb
• //send signed record with sender a, run l and
  ciphertext c
• Message 3 a -gt j fSUB .b.l.kSka
• // send encryption key k to the server j
• Message 4 b lt-gt j fCON .a.b.l.kSkj
• // use ftp-get to retrieve a signed record of a,
  b, l and k
• Message 5 a lt-gt j fCON .a.b.l.kSkj
• // use ftp-get to retrieve a signed record of a,
  b, l and k
• m plaintext message
• kencryption key
• c k(m) the ciphertext
• aoriginator, brecipient, jtrusted server
• fNRO , fNRR protocol steps
• L protocol run ID
• Skaas private signature key

66
The Zhou-Gollmann Protocol -2

• Non-Repudiation of Receipt a can prove that b
  has got the message by presenting
• fNRR .a.l.cSkb
• // message was received by b
• and fCON .a.b.l.kSkj
• // key k was deposited
• In terms of the evidence signal (NRR(tr))
• evidence.a.fNRR.a.l.cSKb in tr ? b sent
  .fNRR.a.l.c
• evidence.a.fCON.a.b.l.kSKj in tr ?
  receive.a.j.fSUB.b.l.cSKa in tr

67
The Zhou-Gollmann Protocol -2

• Non-Repudiation of Origin b can prove that a has
  sent the message by presenting
• fNRO .b.l.cSka
• // a sent the msg C
• and fCON .a.b.l.kSkj
• // key k was deposited
• In terms of the evidence signal (NRO(tr))
• evidence.b.fNRO.b.l.cSKa in tr ? a sent
  .fNRO.a.l.c
• evidence.b.fCON.a.b.l.cSKj in tr ? a
  sent.fSUB.b.l.k

68
The Zhou-Gollmann in CSP -1
evidence.a
evidence.b
a
b
ftp.a
ftp.b
send..b
send..a
J
receive..b
receive..a
receive..J
send..J
medium
69
Zhou-Gollmann in CSP - 2

• Agenta(S)
• ?b?Agent, m?S send.a.b.m -gt Agenti(S)
• ? receive.a.b?m -gt Agenta(close(S U m))
• ? ftp.a.Jeeves?m -gt Agenta(close(S U m))
• ? m?S evidence.a.m -gt Agenti(S)
• --------------------------------------------------
  -------------------------------------------
• Server(S)
• receive.a.Jeeves?. fSUB .b.l.kSka
• -gt Server(S U fCON
  .a.b.l.kSkj)
• ?b?Agent, m?S ftp.a.Jeeves.m -gt Server(S)

70
Zhou-Gollmann in CSP - 3

• Network(a?Agent Agenta(IKa) ftp Server
  sendUreceive Medium(Ø) )
• The correctness requirements
• System sat NRO(tr) and
• System sat NRR(tr)