Title: Modeling Security Protocols in CSP
1Modeling Security Protocols in CSP
ISA 763- Fall 2007
Chapter 2 and 3 of Ryan and Schneider Thanks to
Professor Catuscia Palamidessis notes
2Example 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,
3Three 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)
4Objectives
- 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
5Encoding - I
- Encryption function encrypt(k,m)
- Decryption function dcrypt(k,m)
- Keys serverKey(b)
- shared between server and b
- Other cannot understand it!
6Encoding - 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.
7Initiator 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
8Responder 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
9The 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
10Users
- 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
11Data 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.
12The 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
13Proof 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.
14Constructing 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
15Network Connections
Jeeves
send
receive
Anne
Bob
send
receive
send
receive
fake.x.Bob
take.Anne.y
learn
say
Yves
leak
16Network 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.
17Network 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
18A 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
19A 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
20Direct 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.
21Improved Network Connections
Jeeves
send
receive
Anne
Bob
Com.Anne.Bob
send
receive
send
receive
fake.x.Bob
take.Anne.y
learn
say
Yves
leak
22Specifying Protocol Goals
- Chapter 3 of Ryan and Schneider
23Protocol 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
24Secrecy
- 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.
25Secrecy
B
A
Intr
Protocol run
Claim_Secret.m
26Secrecy 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.
27The 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)
-
28Responder 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) )
29The 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)
30Where 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.
31Authentication
32Authentication 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
33Authentication
B
A
Intr
Run with A
Commit with B
34Authentication 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
35Authentication 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
36Authenticating 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) )
37Authenticating the Initiator - 2
Server
Initiatora
Responderb
- b.kab.na.nbServerKey(a) a.kabServerKey(b)
38Authenticating 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
39Authenticating 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) )
40Authenticating the Responder -2
Server
Initiatora
Responderb
- b.kab.na.nbServerKey(a) a.kabServerKey(b)
41Authenticating 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
42Forms 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
43Authentication 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)
44Recall 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)
45Generalizing 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)
46Non-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
47More 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)
48A 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.
49Weak 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
50Weak 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
51Aliveness
- 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)
52Aliveness vs. Weak-agreement
- Lemma If
- SYSTEM sat WeakAgreement(B-role,A-role,d1,d2)(B
)n then - SYSTEM sat Aliveness(a-role)(B)n
53Agreeing 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
54Recentness
- 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
55Timed 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
56Clocks
- 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
57Timed 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
58Properties 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
59Monotonicity 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)
60Un-timed vs. Timed Specs
- Suppose TimedSpec(_) is the timed version of
Spec(_) and - SYSTEM sat TimedSpec(t,_)
- then,
- SYSTEM sat Spec(_)
61Non-repudiation
62Non-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.
63Signals 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
64Sending 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
65The 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
66The 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 -
67The 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
68The 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
69Zhou-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)
70Zhou-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)
71Anonymity in CSP
72Definitions
- There are many definitions of anonymity.
- Ref papers on http//wiki.uni.lu/secan-lab/Anonym
ity-Papers.html - 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
73CSP 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
74The 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
75Users 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
76Other Parameters
- Set of Observable Events B (say)
- Necessary condition for anonymity AnBØ
- 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 S \ (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
77The Dining Cryptographers Problem
- Reference
- Section 3.5 Modeling and analysis of security
protocols, P. Ryan and S. Snyder - The dining cryptographers problem unconditional
sender and recipient un-traceability, Journal of
Cryptology, 1-1998. - 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!
78Dining Cryptographers 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 selfright
- The paying cryptographer says the opposite
- If (disagree) is even then the host pays
79The 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)
80The Master as a CSP Process
- Master(?iCryptnames pays.i
- ?notPays.((i1)mod 3)
- ? notPays.((i2) 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
81Cryptographer as a CSP process
- Crypt(i) notPays.i?look.i.i.?x
- ?look.i.(i1 mod 3).?y
- ?(if (xy) then (out.i.agree ?Stop)
- else (out.i.disagree ?Stop))
- ?(pays.i?look.i.i.?x
- ?look.i.(i1 mod 3).?y
- ?(if (xy) then (out.i.disagree ?Stop)
- else (out.i.agree ?Stop))
- If asked to pay and (xy) say agree and else
disagree - If asked not to pay and (xy) say disagree and
else agree - look.i.j.x cryptographer i reading value x for
coin j
82The 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) )
83Constructing the System
- Crypts Crypt(0)Crypt(1)Crypt(2)
- Coins Coin(0)Coin(1)Coin(2)
- Meal ((Crypts ? Coins) ? Master)
- look paysUnotPays
84Anonymity 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 lt i lt 2 pays
- B out.i 0 lt i lt 2 out
- C S \ (A U B) - all other events should be
abstracted.
85Anonymity 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
0ltilt2 - What does any permutation on 0,1,2 do?
- Satisfying the anonymity requirement!
86Anonymity 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?
87Anonymity of Cryptographer 0-I
- Cryptographer (i1) mod 3 and (i2) mod 3 wants
to remain anonymous from cryptographer i. - Take i0 (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 S \ (A U B)
88Anonymity 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?
89Anonymity 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 S \ (A U B)
- Consider the trace
- tr ltpays.2, notpays.0, look.0.0.heads,
look.0.1.heads, look.2.2.heads, out.2.disagree gt - Then tr? Meal\C but tr? pA(Meal\C).
- Violating anonymity!
90Analysis 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!
91Correcting a Violation
- Suppose look.2.2 is not available
- Results in the trace
- tr ltpays.2, notpays.0, look.0.0.heads,
look.0.1.heads, out.2.disagree gt - 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!