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
• Brief introduction to Cryptographic methods
• Vulnerability of Security protocols
• Introduction to CSP
• Modeling security protocols in CSP
• principals, server, intruder
• Expressing security properties in CSP
• anonymity
• Verification of security protocols using FDR
• example (of anonymity) Dining cryptographers

3
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
• No information leakage
• Authentication
• No falsification of identity
• Non-repudiation
• Evidence of the involvement of the other party
• Anonymity
• Protecting the identity of agents wrt particular
  events

4
Secrecy and authentication

• Safety properties a certain bad thing should not
  happen
• Explicit annotations In the CSP approach, these
  properties are defined by enhancing the code of
  the processes with explicit signal claiming the
  success of the protocol wrt the intended
  property
• Secrecy Claim_secret. m
• Information m has not become known to the
  intruder
• Authentication Run with A , Commit with B
• The matching of these two events guarantees
  identities of A and B

5
Secrecy and authentication
B
A
B
A
Intr
Intr
Protocol run
Run with A
Claim_Secret.m
Commit with B
6
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
• Authentication of the participants
• Kab should remain secret
• We may require secrecy also on nb

7
Example Secrecy in the Yahalom protocol

• CSP description of the two parties - Original
• 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
• nb e Nonce g
  Session(a,b,kab,na,nb) )
• m e T
• 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

8
Example Secrecy in the Yahalom protocol

• CSP description of the two parties - Enhanced
• 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
• nb e Nonce g
  signal.Claim_Secret.a.b.kab
• m e 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 e Key g receive.a.b.a.
  kabServerKey(b) .nbkab
• nb e Nonce g signal.Claim_Secret.a.b.kab
• m e T g Session(b,a,kab,na,nb) )

9
Example Secrecy in the Yahalom protocol

• CSP description of the server
• 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

10
Example Secrecy in the Yahalom protocol

• CSP description of the intruder
• 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
• k , m - mk
• mk , k-1 - m
• ltx1,,xngt - xi
• x1 ,, xn - ltx1,,xngt

11
Example Secrecy in the Yahalom protocol

• Initiator(Alice,nA) S Responder(Bob,nB) S
  Server(Jeeves) S Intruder(f) S
• S fake,take/receive,send
• S take.x.y/learnfake.x.y, leak/say

Jeeves
receive
send
Alice
Bob
receive
send
send
receive
fake.x.Bob
take.Alice.y
learn
say
Yves
leak
12
Example Secrecy in the Yahalom protocol

• The property to be verified
• Signal.Claim_Secret.a.b.m occurs in tr
• a
• not(leak.m occurs in tr)
• for all traces tr belonging to Traces(System)
• this property can be verified automatically by
  checking the traces

13
Authentication

• The CSP approach is based on inserting signals
• Running.a.b (in as protocol)
• Agent a is executing a protocol run apparently
  with b
• Commit.b.a (in bs protocol)
• Agent b has completed a protocol run apparently
  with a
• Authentication is achieved if Running.a.b always
  precedes Commit.b.a in the traces of the system
• Weaker or stronger forms of authentication can be
  achieved by variations of the parameters of these
  signals and the constraints on them

14
Authentication in the Yahalom Protocol

• The Yahalom Protocol aims at providing
  authentication of both parties authentication
  of the initiator to the responder, and viceversa
• We will analyze the two authentication properties
  separately
• This requires two separate enhancements of the
  protocol

15
Yahalom authentication of initiator

• CSP description of the two parties - Enhanced
• 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
  signal.Running_Initiator.a.b.na.nb.kab
• nb e Nonce g
  send.a.b.m.nbkab
• m e 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 e Key g receive.a.b.a.
  kabServerKey(b) .nbkab
• nb e Nonce g signal. Commit_Responder.b.a.na.nb.k
  ab
• m e T g Session(b,a,kab,na,nb) )

16
Yahalom authentication of initiator
Initiatora
Responderb
Server

• 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

• Comm.Resp.b.a.na.nb.kab

17
Yahalom authentication of initiator

• The 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 in Traces(System)
• Again, this property can be verified
  automatically by checking the traces

18
Yahalom authentication of responder

• CSP description of the two parties - Enhanced
• 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
• nb e Nonce g
  signal.Commit_Initiator.a.b.na.nb.kab
• m e 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 e Key g signal.Running_Responder.b.
  a.na.nb
• nb e Nonce g receive.a.b.a. kabServerKey(b)
  .nbkab
• m e T g Session(b,a,kab,na,nb) )

19
Yahalom authentication of responder
Server
Responderb
Initiatora

• 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

• Comm.Init.a.b.na.nb.kab

20
Yahalom authentication of responder

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

21
Authentication

• A similar analysis was done by Gavin Lowe for the
  Needham-Schoeder Public Key protocol
• Authentication of responder Yes
• Authentication of initiator No
• There is a trace which contains
  signal.Commit_Responder.b.a.
• preceded only by
• signal.Running_Initiator.a.i

22
Non-repudiation

• Goal to provide the parties of an interaction
  with evidence so that later they cannot deny
  having participated
• Example The Zhou-Gollmann protocol
• Message 1 a -gt b fNRO .b.n.cSka
• Message 2 b -gt a fNRR .a.n.cSkb
• Message 3 a -gt j fSUB .b.n.kSka
• Message 4 b lt-gt j fCON .a.b.n.kSkj
• Message 5 a lt-gt j fCON .a.b.n.kSkj
• c mk where m is the message to be transmitted
• a and b are the parties, j is the trusted server
• fNRO , fNRR, etc. are flags identifying the
  steps. n is a nonce
• Ska, Skb, etc. are signature keys known only to
  their owners
• a can prove that b has got the message by
  presenting
• fNRR .a.n.cSkb and fCON .a.b.n.kSkj

23
The Zhou-Gollmann protocol

• Non-Repudiation of Recipient
• a can prove that b has got the message by
  presenting
• fNRR.a.n.cSkb and fCON .a.b.n.kSkj
• Non-Repudiation of Origin
• b can prove that a has sent the message by
  presenting
• fNRO.b.n.cSka and fCON .a.b.n.kSkj

24
CSP analysis of Non-Repudiation

• Specification of the Zhou-Gollmann protocol in
  CSP
• Agenta(S)
• b e Agent, m e 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 e S evidence.a.m -gt Agenti(S)
• Close(S) represent the capability of inferring
  new information
• Server(S)
• receive.a.Jeeves?. fSUB .b.n.kSka
• -gt Server(S U fCON
  .a.b.n.kSkj)
• b e Agent, m e S ftp.a.Jeeves.m -gt
  Server(S)

25
The Zhou-Gollmann protocol in CSP
evidence.a
evidence.b
a
b
ftp.a
ftp.b
send..b
send..a
J
receive..b
receive..a
receive..J
send..J
medium
26
Analysis of the Zhou-Gollmann protocol

• Non-Repudiation of Recipient
• evidence.a.fNRR.a.n.cSkb in tr a b sent
  (fNRR.a.n.c) for every trace tr
• evidence.a.fCON.a.b.n.kSkj in tr a
  receive.a.j.fCON.a.b.n.kSkj in tr for every
  trace tr
• Non-Repudiation of Origin
• evidence.b.fNRO.b.n.cSka in tr a a sent
  (fNRO.b.n.c) for every trace tr
• evidence.b.fCON.a.b.n.kSkj in tr a a sent
  (fSUB.b.n.k) for every trace tr
• Again, these properties on traces can be proven
  automatically