1. Modeling Security Protocols in CSP
ISA 763- Fall 2007
Chapter 2 and 3 of Ryan and Schneider
Thanks to Professor Catuscia Palamidessi’s notes

2. Example: The Yahalom Protocol
The protocol
Message 1: a -> b : a.na
Message 2: b -> s : b.{a.na.nb}ServerKey(b)
Message 3: s -> a : {b.kab.na.nb}ServerKey(a) {a.kab}ServerKey(b)
Message 4: a -> b : {a.kab}ServerKey(b) .{nb}kab
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.nb}ServerKey({a} {a.kab}ServerKey(b)
A b: {a.kab}ServerKey(b) {nb}kab
The Responder (=B)
B a : a.na
B j : {a.na.nb}ServerKey(b)
B  a: {a.kab}ServerKey(b) {nb}kab
The Server Jeeves (= J)
J b: b. {a.na.nb}ServerKey(b)
J a : {b.kab.na.nb}ServerKey(Ka). {a.kab}ServerKey(b)

4. Objectives Develop CSP programs for all three roles In each role:
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.kab}serverKey(b).{nB}.kab)  P(B,a,nB, kab) ]
One that aborts on an incorrect message
□ kab∈Key [recieve.a.B.({a.kab}serverKey(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.a{b.kab.na.nb}ServerKey(a)..{a.kab}kb.
kab∈Key g send.a.b.{a.kab}kab
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.nb}ServerKey(b) g
kab∈Key receive.a.b.{a.kab}ServerKey(b).{a.nb}kab
a∈Agent g Session(b,a,kab,nb,na)
na∈Nonce

9. The Server Jeeves Server(J,Kab ) = kab∈Key {a.kab}ServerKey(b)
receive.b.J.b{a.nanb}ServerKey(b) g
send.J.a.{b.kab.nanb}ServerKey(a)
kab∈Key {a.kab}ServerKey(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 User’s 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.<a,na>)
Syntax: fact := Encrypt.fact.fact |
Hash.fact.fact|Sq.fact* |
Key.k|Nonce.n|Text.t
Abbreviations: Write {k}m for Encrypt.k.m and g(|m|) for Hash.g.m, k for Key.k, n for Nonce.n, t for text.t and <m1,…mn> for Sq.<m1,…mn>, m1.m2 for <m1,m2>.
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?m:messageIntruder(Close(XU{m})
□ say!m:message∩X  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} ⊢ Sq< x1,…xn>
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 [say=channel 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 Anne Bob Yves leak send receive send
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 ||| Jeeves [[fake,take/receive,send]]
Agent(anne) [[fake,take/receive,send]]
|||
Agent(bob) [[fake,take/receive,send]]
Jeeves [[fake,take/receive,send]]
|| Yves[[take.x.y,fake.x.y/learn,say|x,y∈AgentsU{Jeeves}]]
{|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.Sq<A,Na>
{Sq<A,Na>} ⊢ Na
{A,Na,Nc} ⊢ Sq<A,Na,Nc>
{Sq<A,Na,Nc>, ServerKey(C)} ⊢
{Sq<A,Na,Nc>} ServerKey(C)
{C, {Sq<A,Na,Nc>}ServerKey(C)}}
⊢Sq.<C,{Sq<A,Na,Nc>}ServerKey(C)}}>

19. A Sample Run -2 Agent Intruder {<A,K>} ServerKey(C)>
Externally
Agent
Which
Sees
Intruder
fake.C.J.m J
receive.C.J.m
Say. Sq.<C,{Sq<A,Na,Nc>}ServerKey(C)}>
take.J.A.m
send.J.A.m
Say. Sq.<{Sq<C,K,Na,Nc>}ServerKey(A)},
{<A,K>} ServerKey(C)>
fake.J.A.m A
receive.J.A.m
learn.Sq.<{Sq<C,K,Na,Nc>}ServerKey(A)},
take.A.C.m
learn.<{<A,K>} ServerKey(C),{Nc}K>

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 ∩ 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 A
Intr B
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.a{b.kab.na.nb}ServerKey(a).m
kab∈Key g send.a.b.m.{nb}kab
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.nb}ServerKey(b) g
kab∈Key receive.a.b.{a. kab}ServerKey(b).{nb}kab
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)≡ s:signal 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 a’s protocol:
a is executing a run apparently with b
Commit.b.a in b’s protocol:
b completed a protocol run apparently with a

33. Authentication A
Intr B
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.a{b. kab.na.nb}ServerKey(a) .m
kab ∈ Key g signal.Running_Initiator.a.b.na.nb.kab
nb∈ Nonce g send.a.b.m.{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.nb}ServerKey(b)
kab∈Key g receive.a.b.{a. kab}ServerKey(b) .{nb}kab
nb e Nonce g signal. Commit_Responder.b.a.na.nb.kab
m∈T g Session(b,a,kab,na,nb) )

37. Authenticating the Initiator - 2
Initiatora
Responderb
Server
a.na
b.{a.na.nb}ServerKey(b)
{b.kab.na.nb}ServerKey(a) {a.kab}ServerKey(b)
Run_Init.a.b.na.nb.kab
{a.kab}ServerKey(b) .{nb}kab
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.a{b. kab.na.nb}ServerKey(a) .m
kab∈Key g send.a.b.m.{nb}kab
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.nb}ServerKey(b)
kab∈Key g signal. Running_Responder.b.a.na.nb
nb∈Nonce g receive.a.b.{a. kab}ServerKey(b) .{nb}kab
m∈T g Session(b,a,kab,na,nb) )

40. Authenticating the Responder -2
Initiatora
Responderb
Server
a.na
Run_Resp.b.a.na.nb.
b.{a.na.nb}ServerKey(b)
{b.kab.na.nb}ServerKey(a) {a.kab}ServerKey(b)
{a.kab}ServerKey(b) .{nb}kab
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 Lowe’s 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?d’1?d’2 
XXXXX….
signal.Commit.A-role.A.B.d’1.d’2  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 \ (Σ - 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 \ (Σ - 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,d2})(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?d’1?d”2 
signal.Commit.A-role.A.B.d’1.?d’2  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?d’1?d’2 
RUN({signal.Commit.A-role.A.B.d’1.?d’2})
 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?d’1?d”2 
signal.Commit.A-role.A.B.d’1.?d’2  stop]n
Agreement completed in n runs, but each commit is matched by only one run.

49. Weak agreements No guarantee on B’s 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.ds|ds∈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 Lemma: If
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)m+n

51. Aliveness A further weakening: Aliveness(A-role)(B) ≡
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) ≡

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,AuthTime)(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,AuthTime)(B)n, then
SYSTEM sat TimedAgreeement(B-role,A-role,ds’,AuthTime)(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 < 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 -> Agenti(S)
□ receive.b.a?.?m -> Agenta(close├(S U {m}))
□ □ {m∈S} evidence.a.m -> 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 ≡  M:fact; b:Agent
send.a.b.m’/\ (m’contains 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 -> b : {fNRO .b.l.c}Ska
// send an encrypted msg C with run l, recipient b
Message 2 b -> a : {fNRR .a.l.c}Skb
//send signed record with sender a, run l and ciphertext c
Message 3 a -> j : {fSUB .b.l.k}Ska
// send encryption key k to the server j
Message 4 b <-> j : {fCON .a.b.l.k}Skj
// use ftp-get to retrieve a signed record of a, b, l and k
Message 5 a <-> j : {fCON .a.b.l.k}Skj
m= plaintext message
k=encryption key
c = k(m) the ciphertext
a=originator, b=recipient, j=trusted server
fNRO , fNRR= protocol steps
L= protocol run ID
Ska=a’s 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.c}Skb
// message was received by b
and {fCON .a.b.l.k}Skj
// key k was deposited
In terms of the evidence signal (NRR(tr)):
evidence.a.{fNRR.a.l.c}SKb in tr  b sent .{fNRR.a.l.c}
evidence.a.{fCON.a.b.l.k}SKj in tr  receive.a.j.{fSUB.b.l.c}SKa 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.c}Ska
// a sent the msg C
and {fCON .a.b.l.k}Skj
// key k was deposited
In terms of the evidence signal (NRO(tr)):
evidence.b.{fNRO.b.l.c}SKa in tr  a sent .{fNRO.a.l.c}
evidence.b.{fCON.a.b.l.c}SKj 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 □{b∈Agent, m∈S} send.a.b.m -> Agenti(S)
Agenta(S) ≡
□{b∈Agent, m∈S} send.a.b.m -> Agenti(S)
□ receive.a.b?m -> Agenta(close(S U {m}))
□ ftp.a.Jeeves?m -> Agenta(close(S U {m}))
□ {m∈S} evidence.a.m -> Agenti(S)
Server(S) ≡
receive.a.Jeeves?. {fSUB .b.l.k}Ska
-> Server(S U {fCON .a.b.l.k}Skj)
□{b∈Agent, m∈S} ftp.a.Jeeves.m -> Server(S)

70. Zhou-Gollmann in CSP - 3
Network=(|||a∈Agent Agenta(IKa) ||{|ftp|} Server {|send|}U||{|receive|} Medium(Ø) )
The correctness requirements
System sat NRO(tr) and
System sat NRR(tr)

71. Anonymity in CSP

72. Definitions There are many definitions of anonymity.
Ref papers on:
Most definitions are probabilistic and very dependent on the application
The Basic Issue: protect the identity of an agent associated with a given event or message

73. CSP Formulation
Preventing the identity of agents associated with a message
The message itself need not be hidden
So, an event is modeled to have two parts: a.x
a: agent (originator)
x: content
A protocol or a transaction must covey x without revealing a
Also other selected agents must not be able to deduce that a issued a.x

74. The Attacker Model
A group of agents that can observe and deduce information
The medium may or may not be reliable
Usually the medium is assumed to be reliable

75. Users and Observers
The principle of anonymity: a data item that could have originated from one agent could have originated from a collection of agents in a given set. That is said to preserve anonymity!
Anonusers = the set of users whose identities should be masked
A = {a.x | a∈Anonusers}
A protocol P described will provide anonymity to a set of users A if any permutation pA of A is in the acceptable set of traces of P

76. Other Parameters Set of Observable Events: B (say)
Necessary condition for anonymity: A∩B=∅
Events that not in A or B have to be abstracted out.
ABSC(P) = events to be abstracted out from the protocol P. Hence C = Σ \ (A U B) is abstracted out!
Means: hidden, masked or renamed
Condition for anonymity is:
pA (ABSC(P))=ABSC(P) C
Protocol P A B

77. The Dining Cryptographer’s Problem
Reference:
Section 3.5 Modeling and analysis of security protocols, P. Ryan and S. Snyder
The dining cryptographer’s problem: unconditional sender and recipient un-traceability, Journal of Cryptology,
The problem: A collection of cryptographers share a meal. At the end of the meal, they are secretly informed if one of them have to pay. If not, the host would pickup the tab. The cryptographers would like to know which alternative occurs without revealing which cryptographer pays, if it is one of them – without revealing which cryptographer has to pay!

78. Dining Cryptographer’s Algorithm
Each cryptographer tosses a coin
visible to herself and her right hand neighbor
So each cryptographer see two coins;
say self and right.
Each cryptographer gets one of two messages, paying or not paying from the host = master
Each cryptographer makes an announcement agree or disagree using the following algorithm
If not paying say agree iff self=right
The paying cryptographer says the opposite
If #(disagree) is even then the host pays

79. The Dining Cryptographers
out.0
looki,j,x:
Cryptographer i
reads value x
from coin j
Crypt(0)
look.0.0
look.0.2
pays.0
notPays.0
Coin(0)
Coin(2)
The
Master
look1.0
look.2.2
notPayy.1
notPays.2
pays.1
pays.2
Crypt(1)
Crypt(2)
out.2
Out.1
look.1.1
look.2.1
Coin(1)

80. The Master as a CSP Process
Master≡(Πi:Cryptnames pays.i
→notPays.((i+1)mod 3)
→ notPays.((i+2) mod 3) →Stop)
Π (notPays.0
→ notPays.1
→ notPays.2
→ Stop))
Non-deterministically chooses to pay cryptographer i or not to pay either – implying host pays

81. Cryptographer as a CSP process
Crypt(i) ≡notPays.i→look.i.i.?x
→look.i.(i+1 mod 3).?y
→(if (x=y) then (out.i.agree →Stop)
else (out.i.disagree →Stop))
□(pays.i→look.i.i.?x
→(if (x=y) then (out.i.disagree →Stop)
else (out.i.agree →Stop))
If asked to pay and (x=y) say agree and else disagree
If asked not to pay and (x=y) say disagree and else agree
look.i.j.x ≡cryptographer i reading value x for coin j

82. The Coin as a CSP Process
Coin(i)≡ Heads(i) Π Tails(i)
where
Heads(i)≡ (look.i.i.heads→Heads(i) )
□ ( look(i-1 mod 3).i.heads →Heads(i) )
Tails(i)≡ (look.i.i.tails→Tails(i) )
□ ( look(i-1 mod 3).i.tails→Tails(i) )

83. Constructing the System
Crypts ≡ Crypt(0)|||Crypt(1)|||Crypt(2)
Coins ≡ Coin(0)|||Coin(1)|||Coin(2)
Meal≡ ((Crypts ‖ Coins) ‖ Master)
{|look|} {|pays|}U{|notPays|}

84. Anonymity w.r.t. a Table Observer
If anonymity is desired with respect to an observer of Meal (i.e. someone at the table)
Such an observer should only see values agree and disagree announced on channel out
notPays and look should be abstracted. Hence
A = { pays.i | 0 < i < 2} = {| pays |}
B = { out.i | 0 < i < 2} = {| out |}
C = Σ \ (A U B) - all other events should be abstracted.

85. Anonymity w.r.t. a Table Observer
System: Meal \ { |look, notPays |}
Anonymity requirement:
pA(Meal\{|look,notPays|})=Meal\{|look,notPays|}
What other events are available? : {|out|}
So what does a trace consist of?
Only of out.i.agree or out.i. disagree events for 0<i<2:
What does any permutation on {0,1,2} do?
Satisfying the anonymity requirement!

86. Anonymity w.r.t. a Table Observer
Allowing more visible events:
Can allow look.i.j.x events to be visible but not their value:
Let flook(look.i.j.x) = look.i.j – i.e. drop the value
Erasing/hiding the data value!
New anonymity requirement:
pA(flook(Meal)\{|notPays|})=flook(Meal)\{|notPays|}
Is it satisfied?

87. Anonymity of Cryptographer 0-I
Cryptographer (i+1) mod 3 and (i+2) mod 3 wants to remain anonymous from cryptographer i.
Take i=0 (others are similar)
Events indistinguishable by cryptographer i: A= {pays.1, pays.2}
Events visible to cryptographer 0:
B = {pays.0, notPays.0} U {|look.0|} U {|out|}
C = Σ \ (A U B)

88. Anonymity of Cryptographer 0-II
Only one permutation pA that satisfy
pA(Meal\C) = Meal\C
maps pays.1 ↔ pays.2
Is tr∈ Meal\C ↔ tr ∈ pA(Meal\C) hold?

89. Anonymity of Cryptographer 0-III
Consider the case where Cryptographer 0 has access to the value of coin 2, i.e. look.2.2.x (i.e. By eavesdropping on the transmission). Then
A= {pays.1, pays.2}
B = {pays.0, notPays.0} U {|out|} U {|look.0,look.2.2|}
C = Σ \ (A U B)
Consider the trace:
tr =<pays.2, notpays.0, look.0.0.heads, look.0.1.heads, look.2.2.heads, out.2.disagree >
Then tr∈ Meal\C but tr∉ pA(Meal\C).
Violating anonymity!

90. Analysis of a Violation
Heads on all three coins are observed:
Hence out.2.disagree is consistent with pays.2
However not consistent with pays.2
So if pays.2 is replaced with pays.1, the rest of the trace is not consistent with that change
That is, the rest of the trace contains sufficient information to distinguish pays.1 from pays.2 – violating anonymity!

91. Correcting a Violation
Suppose look.2.2 is not available
Results in the trace
tr’ =<pays.2, notpays.0, look.0.0.heads, look.0.1.heads, out.2.disagree >
Then tr∈Meal\C and tr∈pA(Meal\C)
Regaining anonymity!
Conclusion: if the information about Coin(2) is not available, then anonymity is regained!