6.4 Verifying RA Property for DTR1
6.4.1 The DTR1 Model in CSP
6.4.1.1 Data types.
The following data types are used:
• Nonces tNonce.id|idPIu represents nonces.
• P8
represents all peers that could take part in the system.
• Counts represents the counter values. For simplicity, assume Counts N.
• Agents P 8
Y tNM , CA, VFurepresents all agents in the network except for the
adversary. This includes peers, the agent that manages nonces, the CA and the honest peer that carries out the neighborVerification protocol.
6.4.1.2 Events.
The events used in the model come from the following sets: 1. ChurnEvents tChurn.x |x Ptjoin, leaveuP
8
u. This represents churn events.
2. SigMessages tSqR.x , SqI .x|x PNonces P 8
Countsu. This represents TPM-
signed messages containing counter values after being read or incremented. 3. NonceMessages tSqN .xny|nP Noncesu. 4. CertMessages tCert.x|x P P 8 P 8 P 8
Countsu. This represents neighbor
certificates issued by the CA to peers during churn events. The event Cert.xp, l, r, cy,
for example, is the neighbor certificate issued for p, and it asserts that p’s immediate neighbors when its counter value is c is l and r.
6.4.1.3 Channels.
The following channels are used in the model:
• send , receive, take, fake : Agents.Agents.Messages • learn, say : Messages
• output : P8
.P8
• completeChurn : ChurnMessages • unlock : Agents.P8
6.4.1.4 Nonce Manager process.
This process supplies fresh and unique nonces to other agents via the send channel. The nonces are used during churn and verification.
NonceSender(n) = ü jPAgents send.NM.j.SqN.xnyÑ STOP NonceManager = ||| nPN onces NonceSender(n)
Compared with other CSP implementation of the nonce manager, the process NonceManager is more efficient to compile and run in FDR (see [30] for more details).
6.4.1.5 Peer processes.
Each peer is modeled by a process representing a TPM.
TPMs = iPP 8 TPM(i,0) TPM(i,c) = ü nPN onces jPAgents receive.j.i.SqN.xny Ñ ü d¥c
send.i.j.SqR.xn, i, dyÑunlock.V F.iÑTPM(i,d)
l ü
d¡c
send.i.j.SqI.xn, i, dyÑunlock.CA.iÑTPM(i,d) Æ Æ Æ Æ Æ Æ Æ Æ
Each TPM process receives nonces on the receive channel, then sends back SigMessages events on the send channel. The TPM is locked when verification or churn is in progress,
which is to ensure the atomicity of these protocols (discussed early in Section 6.1). The events on the unlock channel signal that the churn or verification protocol has finished.
6.4.1.6 CA Process.
This process models the CA that issues neighbor certificates when a peer joins or leaves the network. The high-level protocol is described in Section 4.3.2. In CAProcesspps, pnq,
ps is the set of nodes that are currently in the network, pn is the set comprising nodes that have left or are about to join the network.
First, the process receives a churn request from a peer, either for joining or leav- ing the network. The request is in the form of the event receive.i .CA.Churn.xjoin, iy or
receive.i .CA.Churn.xleave, iy for some i. It checks that iP ps if i is joining the network,
and that iPpnif i is leaving the network. Next, it gets fresh nonces from the Nonce Man-
ager process, in the form of the event receive.NM .CA.SqN .xny for some value of n. The
nonces are forwarded to the relevant nodes (the joining/leaving node and its immediate neighbors) in the form of the event send .CA.i .SqN .xny for some values of i and n. The
processes representing these nodes are then locked, meaning that they cannot communi- cate events that are not related to the churn process, until the churn process completes. Once received the signed messages from those nodes containing their newly incremented counter values, which are in the form of the event receive.i .CA.SqI .xn, i , cyfor some values
of n, i and c, the CA issues new neighbor certificates for these nodes, then sends them to the nodes in the form of the event send .CA.i .Cert.xi , l , r , cyfor some values of i, l, r and c.
Next, it outputs on channel completeChurn, for example completeChurn.Churn.xjoin, iy,
to signal that the churn event for some node i has completed, or in other words, that the network has moved to a new state (Figure 6.1.1). Finally, the nodes involved during the churn process are unlocked by the events of the form unlock .CA.i, so that they can start communicating other events that are not churn-related.
CAProcess(ps,pn) = |ps|0 & Join0(ps,pn)
l|ps|1 & Join1(ps,pn)
JoinAndLeaveN(ps,pn) =
iPpn
receive.i.CA.Churn.xjoin, iyÑJoinN(i,ps,pn)
l ü iPps receive.i.CA.Churn.xleave, iy Ñ if |ps|¡2 then LeaveN(i,ps,pn) else Leave2(i,ps,pn) Æ Æ Æ Æ JoinN(i,ps,pn) = ü n1,n2,n3PN onces
receive.N M.CA.SqN.xn1yÑsend.CA.i.SqN.xn1y
Ñ Ü c1,c2,c3PCounts receive.i.CA.SqI.xn1, i, c1yÑ let SpsYtiu pl, rqneighborpi,Sq pl1, r1qneighborpl,Sq pl2, r2qneighborpr,Sqwithin send.CA.i.Cert.xi, l, r, c1y Ñreceive.N M.CA.SqN.xn2y Ñsend.CA.l.SqN.xn2y Ñreceive.l.CA.SqI.xn2, l, c2y Ñsend.CA.l.Cert.xl, l1, i, c2y Ñreceive.N M.CA.SqN.xn3y Ñsend.CA.r.SqN.xn3y Ñreceive.r.CA.SqI.xn3, r, c3y Ñsend.CA.r.Cert.xr, i, r2, c3y ÑcompleteChurn.Churn.xjoin, iy Ñunlock.CA.iÑunlock.CA.l Ñunlock.CA.rÑCAProcess(S,pnztiu) Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ
The function neighborpp, psq returns the left and right neighbor of p in the set ps.
More precisely,
neighborpp, psqpleftpp, psq,rightpp, psqq
leftpp, psql if lPps ^ p 1 Ppsztlu. cdpp, lq¤cdpp 1 , lq rightpp, psqr if rPps ^ p 1 Ppsztru. cdpr, pq¤cdpr, p 1 q
The details of other sub-processes, namely Join0(ps,pn), Join1(ps,pn), Leave2(ps,pn) and LeaveN(ps,pn), can be found in Appendix D.
6.4.1.7 Adversary Process.
This process models the adversary whose aim is to break the NA property. In particular, it attempts to make the Verifier accept incorrectly that two nodes are immediate neighbors of each other in the current network. The adversary is modeled as having control of all peers, which means that it could ask TPMs to increment their counters and generate signed messages on their values. However, it cannot fake the signatures coming from TPMs, which reflects the property that TPM operations are trusted.
MemoryNonce(n) = learn.SqN.xny ÑReplayNonce(n)
ReplayNonce(n) = say.SqN.xnyÑReplayNonce(n)
MemorySigR(n,i,c) = learn.SqR.xn, i, cyÑReplaySigR(n,i,c)
MemorySigI(n,i,c) = learn.SqI.xn, i, cyÑReplaySigI(n,i,c)
ReplaySigR(n,i,c) = say.SqR.xn, i, cyÑReplaySigR(n,i,c)
ReplaySigI(n,i,c) = say.SqI.xn, i, cyÑReplaySigI(n,i,c)
MemoryCert(i,l,r,c) = learn.Cert.xi, l, r, cyÑReplayCert(i,l,r,c)
ReplayCert(i,l,r,c) = say.Cert.xi, l, r, cyÑReplayCert(i,l,r,c)
Memory = nPN onces MemoryNonce(n) ||| nPN onces,iPP,cPCounts MemorySigR(n,i,c) ||| MemorySigI(n,i,c) ||| i,l,rPP,cPCounts MemoryCert(i,l,r,c) ChurnInitiator = ü iPP
say.Churn.xjoin, iyÑChurnInitiator lsay.Churn.xleave, iyÑChurnInitiator
Adversary = Memory|||ChurnInitiator
The adversary can start a churn event for any node in the network, modeled by the ChurnInitiator sub-process. It can eavesdrop (on the learn channel), remember, and replay (on the say channel) all messages sent between peers and the other agents in the network. Its infinite memory for remembering messages is modeled by the Memory sub- process. In the literature, modeling such the powerful adversary has been used when analyzing security protocols in CSP [83].
6.4.1.8 Verifier Process.
This process models the neighborVerification protocol described in Section 4.3.2, i.e. it models the honest peer that verifies if two other nodes are immediate neighbors of each other. The process sends and receives messages using the send and receive channel re- spectively. The output.l .r event, for example, indicates that the verifying peer accepts that l is the immediate left neighbor of r in the current state of the system.
VerifierProcess = ü nPN onces receive.N M.V F.SqN.xny Ñ ü i,l,rPP 8 send.V F.i.SqN.xny Ñ ü cPCounts receive.i.V F.SqR.xn, i, cy Ñreceive.i.V F.Cert.xi, l, r, cy Ñif lr and li then
output.i.i Ñunlock.V F.i
ÑSTOP else VerifierProcessN(l,i) Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ VerifierProcessN(l,i) = ü nPN onces receive.N M.V F.SqN.xnyÑsend.V F.r.SqN.xny Ñ ü clPCounts receive.l.V F.SqR.xn, l, cly Ñ ü llPP 8 receive.l.V F.Cert.xl, ll, i, cly Ñoutput.l.iÑunlock.V F.l Ñunlock.V F.i ÑSTOP
Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ Æ
Notice that VerifierProcess models the verification that happens only once, unlike CAProcess which allows for the many churn events to happen. There are two reasons for it:
• VerifierProcess is combined with the other processes by a parallel operator, which means that the verification can occur at any state of the system. If on all the traces of the system model, verification returns the correct result, then it can be concluded that the neighborVerification protocol returns the correct result for any state of the system (or the NA property is satisfied).
completeChurn take fake say learn Adversary TPMs receive send receive receive send send Nonce Verifier send Manager CA unlock unlock output
Figure 6.4.1: Channels and processes in the model of DTR1
fication executed more than once. If VerifierProcess were defined recursively, so that the verification protocol would occurs more than once in a trace, the results of these verification protocols would be completely independent of each other. In other words, the adversary cannot rely on running more verifications to help it succeed in making another verification return the wrong result.
6.4.1.9 Putting it together.
Figure 6.4.1 illustrates how the processes are joined together to create the complete model for DTR1. To model the adversary eavesdropping on the communication between peers and the other agents, the send channel, which is used by the CA, TPM and Verifier to send messages, are mapped to the take channel to which the adversary process listens (by renaming its learn channel to take). To model the adversary replaying messages, its say channel is mapped to the fake channel on which messages are received by the CA, TPM and Verifier process. Notice that the send channel used by the Nonce Manager process is mapped to the fake channel, so that the communication between Nonce Manager and the other agents is not accessible by the adversary.
Name Details Applied to RAd1 learn take.i.j |i, j P Agents, ti, ju Y P H Adversary
RAd2 say fake.i.j |i, j P Agents, ti, ju Y P H Adversary
RCom1 send take T P M s, CAP rocess
and V erif ierP rocess
RCom2 receive fake T P M s, CAP rocess
and V erif ierP rocess
RN once1 send.NM.i take.NM.i | iP P N onceM anager
RN once2 send.NM.j fake.NM.j | j RP N onceM anager
χi t|take.i.a, f ake.a.i|iPP, aP Agents|u
χe t|take.a.i, f ake.i.a|iPP, aP Agents|u
Table 6.4.1: Renaming relations and synchronization sets
by the adversary process to map learn and say channels to take and fake, are many-to-one mappings. They introduce nondeterminism, which increases the adversary’s power. In particular, the mapping allows the adversary to send a message originally intended for one process to another different process.
Network = Adversary χi TPMs zχi
CAandVFProcess = CAProcessptu,Pq ||| VerifierProcess
OtherAgents = NonceManager t|f ake.N M|u CAandVFProcess Impl = OtherAgents χe Network
zt|take, f ake, unlock|u