![](bg6.png)
1 rule t tw ee t :
2 let
3 H C n e w x = h ( H C b x )
4 in
5 [ S t x 2 (x , id x , p u bk x , l t k x , H C 1 x , ’ F O L L O W W EL CO ME r e c e i v ed ’ , T I D 1 x ) ,
6 HC (x , <H C a x , H C b x>) , ! Co m mu n it y I D (r , id r , p u bk r , H C 1 r ) ,
7 TID chain(<issuer prec, TID prec>) , Fr (˜ T I D x ) ]
8 −−[ Neq ( x , r ) , T R AN SA C TI O N sen t (x ,r ,˜ T ID x ) , O U T TR A NS ( T ID pr ec ) ]−>
9 [ S t x 3 (x , id x , p u bk x , l t k x , H C 1 x , ’ TR A NS AC T IO N s e nt ’ , T I D 1 x ) ,
10 HC (x , <H C b x , H C n e w x>) , TID chain(<issuer prec, TID prec>) , TID temp(<x, ∼TID x>) ,
11 Out (<x, ˜ TI D x>) , Ou t (< <x , H C n ew x , TI D prec , ’ content ’ , r>,
12 sign ( <x, H C ne w x , T ID pr e c , ’ co n t e n t ’ , r>, l t k x ) >) ]
Listing 2: Specification of the t tweet rule.
1 rule c on fi rm at io n st a t u s 1 :
2 [ S t 2 (v , id v , pu b k v , l t k v , H C 1 v ,’ W E LC O ME re ce i ve d ’ , T I D 1 v ) ,
3 ! Co mm u ni ty ID ( x , id x , p ubk x , H C 1 x ) , TID chain(<issuer succ, TID succ>) , TID temp(<x, TID x>) ,
4 HC (x , <H C ol d x , H C n e w x>) , HC (v , <H C o ld v , H C n e w v>) ,
5 In (< <x , H C n ew x , T I D succ , ’ content ’ , r>, au th ms g >) ]
6 −−[ Neq ( v , x ) , Neq(v,r) ,
7 Eq ( v e r i f y ( au t h ms g , <x , H C n ew x , TI D succ , ’ content ’ , r>, pu bk x ) , t r u e ) ,
8 Eq( h(HC old x), HC new x) , V E RI F s ta r ts (v , x ) ]−>
9 [ S t v 3 (v , id v , p u bk v , l t k v , H C 1 v ,’ C ON F PO S s en t ’ , T I D 1 v ) , T ID c h ai n (<x , T I D x>) ,
10 Out (< <v , H C ne w v , x , T ID x , ’1 ’ , T I D succ , ’ content ’ , r>,
11 sign ( <v, H C ne w v , x , TID x , ’1 ’ , T I D su c c , ’ con t e n t ’ , r>, l t k v ) >) ]
Listing 3: Specification of the confirmation status 1 rule.
To facilitate the analysis process with the Tamarin
Prover, the model includes some additional features
in the Utility Rules and Restriction sections.
The Utility Rules section contains the reveal ltk
rule that can be used when the attacker should not be
able to retrieve some information. In particular, dur-
ing the analysis, this rule checks if the adversary has
stolen some private information of a party (e.g., a pri-
vate key).
For the same sake of analysis complexity reduc-
tion, we defined a set of restrictions in the Restriction
section: equality and inequality, and uniqueEnt,
which ensures that each entity involved in the proto-
col is created only once.
3.2 Security Analysis of the Protocol
The security analysis of the protocol is carried out us-
ing the model, described in Subsection 3.1, and the
security properties to be verified (bottom part of Fig-
ure 2), which are herein described.
Before specifying the security properties of inter-
est, we performed a preliminary analysis aimed at
checking the correctness of the model. Concretely, we
defined a set of lemmas that enable to check the states
reachability of the LTS. The structure of a reachability
lemma is simple: it checks the existence of the nec-
essary entities and a timepoint for which a specific
rule is used, i.e., a specific state of the LTS is reached
from the initial state. These lemmas are marked with
a reach ... name.
An example of reachability lemma is shown in
Listing 4 that is used to verify the execution of the
attestation follow rule, defined in the protocol
model.
1 l emma re a c h F O L L O W W E L C O M E s : exists−tra c e
2 " Ex y x # i . F OL LO W WE LC OM E se nt (y ,x) @ i "
Listing 4: Specification of a reachability lemma.
This rule models the sending action by a verifier y,
after the reception of a followership request sent by x.
In particular, the lemma checks the reachability of the
state FOLLOW WELCOME sent at timepoint i, where the
verifier y sends a Follow welcome tweet to x.
The security properties of interest concern the au-
thenticity of the messages sent over Twitter. In partic-
ular, with reference to the analysis carried out in (Buc-
cafurri et al., 2017a), we checked whether the Trans-
action Authenticity property holds for the modelled
protocol
9
. We did not analyzed the other two prop-
erties, considered in the work by (Buccafurri et al.,
9
This property is meant to verify that each transaction
can always be verified by the Tweetchain community: see
SP1 in (Buccafurri et al., 2017b).
ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering
786