On Formalising and Analysing the Tweetchain Protocol

Mariapia Raimondo

1 a

, Simona Bernardi

2 b

and Stefano Marrone

1 c

Dip. di Matematica e Fisica, Universit

a della Campania “Luigi Vanvitelli”, Caserta, Italy

Dpto. de Inform

atica e Ingenier

ıa de Sistemas, Universidad de Zaragoza, Zaragoza, Spain

Keywords:

Distributed Ledger Technology, Formal Modelling, Tweetchain, Tamarin Prover, Model Checking.

Abstract:

Distributed Ledger Technology is demonstrating its capability to provide ﬂexible frameworks for information

assurance capable of resisting to byzantine failures and multiple target attacks. The availability of develop-

ment frameworks allows the deﬁnition of many applications using such a technology. On the contrary, the

veriﬁcation of such applications are far from being easy since testing is not enough to guarantee the absence

of security problems. The paper describes an experience in the modelling and security analysis of one of

these applications by means of formal methods: in particular, we consider the Tweetchain protocol as a case

study and we use the Tamarin Prover tool, which supports the modelling of a protocol as a multiset rewriting

system and its analysis with respect to temporal ﬁrst-order properties. With the aim of making the modeling

and veriﬁcation process reproducible and independent of the speciﬁc protocol, we present a general structure

of the Tamarin Prover model and of the properties to veriﬁed. Finally, we discuss the strengths and limitations

of the Tamarin Prover approach considering three aspects: modelling, analysis and the veriﬁcation process.

1 INTRODUCTION

The digitization of the economy and, more in gen-

eral, of the society is an unstoppable process that re-

cent times are just accelerating. Being able to track

events and being sure of the identity of the parties in-

volved in a transaction are cornerstones of both dig-

ital economies and smart societies and their enabler,

the Internet of Things (IoT) technology.

This non-repudiation property is guaranteed by a

new family of technologies: the Distributed Ledger

Technology (DLT). Even if the concept of DLT

is not new, its mass diffusion started with Bit-

coin (Nakamoto, 2009) and other blockchain applica-

tions: a comprehensive explanation of the differences

between blockchain and DLTs can be found in (Pan-

war and Bhatnagar, 2020). From a security perspec-

tive, the literature (Lin and Liao, 2017; Yu et al.,

2018; Lee and Jang, 2020; Dai et al., 2017; Kumar

and Mallick, 2018) analyses a number of possible at-

tacks on blockchain, even if their practical relevance

has not been demonstrated.

Blockchain received a lot of interest not only from

the academic community but also from the indus-

https://orcid.org/0000-0001-7483-7987

https://orcid.org/0000-0002-2605-6243

https://orcid.org/0000-0003-1927-6173

trial one: the presence of development frameworks

is spreading the usage of this technology by helping

software designers in integrating blockchain in their

applications and in getting its beneﬁts. Such frame-

works differ from each other by many features: kind

of proof of stake, support to smart contracts, being

permissioned/permissionless, etc.

Some examples of such frameworks are:

• Exonum: a blockchain framework developed for

the enterprise panorama in 2017. It is based on

a Rust-based open source code and Application

Programning Interface (API)

;

• Hyperledger Fabric: oriented to the develop-

ment of high-scaling enterprise applications in a

ﬂexible-permissioned environment

;

• Openchain: designed for issuing and managing

digital assets, it is more oriented to ﬁnancial set-

tings. It relies on smart contract modules

;

• Ripple: a permissioned open source framework,

based on a Python API, it is based on probabilis-

tic voting. Features like “issuance” allow users

to lock a particular asset and transfer it and, ul-

https://github.com/exonum

https://github.com/hyperledger/fabric

https://github.com/openchain

Raimondo, M., Bernardi, S. and Marrone, S.

On Formalising and Analysing the Tweetchain Protocol.

DOI: 10.5220/0010427907810791

In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 781-791

ISBN: 978-989-758-491-6

781

timately, lowers the transaction cost, speeding up

the transaction while maintaining transparency

One of the most challenging contexts where

blockchain promises a greater impact is the ﬁeld of

the IoT; such challenges are inherent to the nature of

the devices used in IoT. These devices present the fol-

lowing features that are hard to match with the re-

sources needed by DLTs and, more in general, by

cryptographic applications:

• limited computational power, that does not al-

low very cheap devices to participate to the

blockchain;

• absence of speciﬁc cryptographic hardware capa-

ble of accelerating such computations;

• low capacity of storing large transaction foot-

prints;

• limited battery that contrasts with the high energy

demand due to the continuous interaction with the

Peer-to-peer (P2P) network.

These applications are becoming more and more per-

vasive in both the economic and societal texture so

that they can be considered business critical applica-

tions. The capability to sell by software companies

operating in this ﬁeld, also relies on their capabilities

to certify blockchain-based software and to guarantee

that the theoretical properties of DLTs are matched

by concrete protocols and software. Formal valida-

tion techniques would constitute a cornerstone in the

diffusion of such approaches.

The main objective of this work is to provide a

concrete experience in the modelling and analysis of

a block-chain based protocol with formal methods.

Rather than providing an overview and a generic com-

parison of such methods, this paper focuses on one

among the most promises methods, to clearly high-

light its strengths and weaknesses. In particular, the

formalism and the underlying solution tool used in

this paper is the well-known Tamarin Prover (Meier

et al., 2013), which is used since 2013 in the mod-

elling of cryptographic mechanisms.

Even if many of the concerns dealt with in this pa-

per can be generalized to a generic blockchain appli-

cation, the objective of this paper is to present an ap-

plication of Tamarin Prover modelling approach to a

case study: the Tweetchain protocol deﬁned in (Buc-

cafurri et al., 2017a; Buccafurri et al., 2017b). This

protocol perfectly ﬁts with the scope of this work

since it is meant to provide a light-weight public

ledger for IoT and crowd-sourcing applications.

The paper is structured as follows: Section 2 pro-

vides the background on Tweetchain protocol and

https://github.com/ripple

Tamarin Prover. Section 3 shows the structure and

the details of the Tweetchain modelling and analy-

sis. Section 4 reports some considerations on the pre-

sented experience. Section 5 presents related works;

Section 6 summarises the paper and draws future re-

search directions.

2 BACKGROUND

In this section, basic concepts of Tweetchain and

Tamarin Prover are presented in Subsections 2.1

and 2.2, respectively.

2.1 The Tweetchain Protocol

The Tweetchain protocol has been developed and in-

troduced in (Buccafurri et al., 2017a; Buccafurri et al.,

2017b) to overcome the problems in applying full

public permissionless ledger based mechanisms in

the IoT domain. Tweetchain exploits the pervasive-

ness of Online Social Networks (OSN) in human-

to-machine and machine-to-machine communication;

the usage of OSN compensates the limitations of pure

blockchain-based approaches.

In fact, the Tweetchain community (C) is me-

diated by a special user, the welcome proﬁle (W ),

whose scope is to provide a sort of yellow pages

for all the “regular users” (x). Let us suppose that:

(1) each party has a Twitter account and signs in;

(2) a generic party u owns a chain of hash values

#HC

, #HC

, . . . , #HC

(i−1)

where the hash values are

the digests of the i − 1 messages already sent by u.

The Tweetchain registration scenario is speciﬁed by

the Uniﬁed Modeling Language (UML) sequence di-

agram of Figure 1.

Before interacting in any way with other

Tweetchain actors, each party has to sign in Twitter.

As a ﬁrst step to join C, x publishes a Hello tweet, con-

taining the ﬁrst elements HC

and HC

of the hash-

chains of x and W , respectively, to register itself to W .

W , after verifying the tweet, sends a Welcome tweet as

a response. The latter contains the hash value #HC

computed on the base of its hash-chain, and the Twit-

ter id (#T ID

) of the Hello message sent by x

The ﬁnal step of the registration procedure pre-

scribes that x chooses among the members of C its

set of veriﬁers V

= {v

x,s

} ⊂ C, where s is described

in (Buccafurri et al., 2017a). To this aim, x gener-

ates this subset according to a publicly known pseudo-

In Twitter, each tweet has a unique id.

ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering

782

User Welcome page Verifier

Follows

publishes hello tweet:

publishes welcome tweet:

Sends Private followership request

Follows

publishes follow_welcome tweet:

Twitter

Verifies hello tweet

Verifies followership

request

Computes his verifiers

with PRNG

Figure 1: The Tweetchain registration scenario.

random algorithm and a public seed

. The use of pub-

licly veriﬁable information, in this phase, is motivated

by the necessity of assuring that each party in C does

not choose its set of veriﬁers in a malicious way. Af-

ter this check, each v

x,s

conﬁrms and follows the user

x and publishes a Follow welcome tweet.

Once the registration has been carried out, the user

x belongs to the community, thus he/she is able to gen-

erate a transaction intended for another user r of C. A

transaction, in this context, corresponds to the posting

of a t-tweet, a particular tweet reporting the last ele-

ment i of the hash-chain of the sender HC

, the Twit-

ter id T ID

of latest approved transaction (i.e., the

T ID of the p-th t-tweet posted by user y) and, clearly,

the reference to the intended recipient. In particu-

lar, T ID

plays the role that the cryptographic hash

of the previous block (included in the header of an-

other block) plays in a blockchain, i.e., it allows to

link them.

As soon as x posts a t-tweet, the users of V

have

to validate the transaction using a particular protocol

shortly explained below. After the check, a veriﬁer

v posts a conﬁrmation tweet containing: the last ele-

ment j of its hash-chain HC

, the content of the trans-

action, the Twitter id T ID

, of the transaction to vali-

date, and T ID

, of the previous one, to link them, and

the boolean variable status that represents the result

As a seed, the protocol may use the Twitter user id that

is unique and publicly available, as proposed by (Buccafurri

et al., 2017a); this choice is not mandatory.

of the validation process (1 - success, 0 - failure).

The veriﬁcation protocol for a veriﬁer v consists

of the following tasks:

1. checking that the sender has not already used the

hash-chain element HC

involved in the t-tweet;

2. using HC

(or a previous elements in the hash-

chain) to search on Twitter for the related tweet

until a Hello tweet or another t-tweet is found;

3. checking that v has validated the tweet found in

the previous step;

4. verifying the validity of the transaction related to

T ID

, i.e., looking for a ”sufﬁcient number” of

conﬁrmation tweets on Twitter, posted by the ver-

iﬁers of y

;

5. verifying that the recipient of the transaction be-

longs to the community.

To summarize, the underlying idea of Tweetchain is

to deﬁne a consensus protocol using tweets, to en-

code transactions, and meshed replications, to substi-

tute the proof of work and thus the need of fees for

miners. The consensus on transactions is based on the

presence of a sufﬁcient number of valid conﬁrmation

tweets from the community.

The meaning of sufﬁcient is clariﬁed in (Buccafurri

et al., 2017a)

On Formalising and Analysing the Tweetchain Protocol

783

2.2 The Tamarin Prover

The Tamarin Prover (Meier et al., 2013) is a sym-

bolic model checker largely used for the modeling

and analysis of cryptographic protocols. This tool has

proved its suitability in analysing cryptographic pro-

tocols used in different application domains, which

span from 5G (Basin et al., 2018) to vehicular net-

works (Whiteﬁeld et al., 2017) and trusted computing,

using Elliptic Curve Cryptography (ECC) (Whiteﬁeld

et al., 2019). The current version of the tool is 1.6.0

and can be downloaded under GNU’s GPL v3.0

According to the classical model checking ap-

proach, a security protocol model and a speciﬁcation

of the desired properties have to be fed to the Tamarin

Prover to begin the analysis process; furthermore, the

tool also allows the user to add rules to check the be-

haviour of the adversary.

Protocols and properties can be speciﬁed, respec-

tively, with labeled multiset rewriting rules and ﬁrst

order logic formulas over symbols (i.e., the lemmas).

The adversary model, set by default, is the Dolev-Yao

model (Dolev and Yao, 1983): such an adversary con-

trols the network and can delete, inject, modify and

intercept messages on the network.

There are two ways of constructing proofs (i.e.,

analysing the model): the automated mode, that com-

bines deduction and equation reasoning with heuristic

to guide the proof search; and the interactive mode,

which allows the user to manually guide the proof

search while still exploiting the automated proof

search efﬁciency. In both the cases, the Tamarin

Prover generates a Labeled Transition System (LTS)

from the protocol and the adversary models, where:

(1) the states are multisets of facts, and the initial state

is the empty set; and (2) each transition transforms a

state (i.e., a multiset of facts) into another state, ac-

cording to the used rewrite rule.

Security properties to be veriﬁed are speciﬁed us-

ing lemmas, which are identiﬁed by a name and a

guarded ﬁrst-order formula over the action facts (i.e.,

the transition labels). There are two types of lemmas:

exists-trace lemmas, to check the existence of a trace

holding the property, and all-traces, to verify whether

the property holds for all the possible traces.

Moreover, it is possible to constrain the state-

space exploration by means of special lemmas named

restriction, which allow the analyst to deﬁne proper-

ties that each trace must satisfy.

Finally, when modelling a non-trivial protocol, it

might happen to run into the partial deconstruction,

which can lead to non-termination when verifying

lemmas. A way to overcome this problem is to use

https://github.com/tamarin-prover

the keyword sources in some lemmas, which will help

in the pre-computation phase. Recently, the Tamarin

Prover developers have improved the tool providing

support to the users by automating the generation of

sources lemmas (Cortier et al., 2020).

3 MODELLING AND ANALYSING

TWEETCHAIN

This section describes the modelling of the

Tweetchain protocol and a preliminary security

analysis of the protocol with the Tamarin Prover tool.

In particular, Figure 2 depicts the overall structure

of the Tamarin Prover model, that includes both the

model of the protocol and the security properties to be

veriﬁed on the model itself during the analysis. The

model of the protocol is detailed in Subsection 3.1,

whereas the speciﬁcation of the security properties

and the results of the analysis are described in Sub-

section 3.2.

3.1 The Model of the Protocol

The model of the Tweetchain protocol (top part of

Figure 2) has been developed trying to preserve the

notation and the structure used in (Buccafurri et al.,

2017a) as far as possible. In particular, the model is

composed of six sections: Entering Twitter, Joining

Community, Utility rules, Followership, Transaction,

and Restriction. The ﬁrst ﬁve sections correspond to

Tamarin rules while the last one contains Tamarin ax-

ioms.

The Entering Twitter section, corresponds to the

initial fragment Twitter Sign in of the sequence

diagram in Figure 1, and the action of signing

into Twitter is modelled with two Tamarin rules,

create entity W and create entity, which create

the Welcome page W and a generic user x, respec-

tively. The need to differentiate W and all the users

that want to join the community arises from the ne-

cessity of avoiding modelling (and analysing) issues.

In fact, with the rule create entity W, it is gener-

ated a persistent fact !Community ID W(...), which

contains the necessary information that any user x

needs to check the authenticity of a tweet posted from

W , and the hashchain of W , that has to be available

to a generic user x that aims at joining the commu-

nity, whilst the hashchain of x bears only when he/she

sends a Hello tweet.

The Joining Community section includes three

Tamarin rules: hello

tweet, welcome tweet and

community joined. There are a few highlights that

are worth mentioning: the ﬁrst rule models the action

ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering

784

1 rule he ll o t w ee t :

2 let

3 H C 1 x = h (˜ r o o t H C x )

4 in

5 [ S t 0 (x , id x , pu b k x , lt k x ) , !C o mm u ni ty ID W ( $W , i d W , pubk W , H C 1 W ) ,

6 Fr (˜ T I D 1 x ) , Fr (˜ r o o t H C x ) ]

7 −−[ Neq ( x , $W ) , H EL LO se n t (x , $W ), Uniq u e Hello ( x) ]−>

8 [ S t 1 (x , id x , pu b k x , l t k x , H C 1 x , ’ H EL L O se n t ’, ˜ T I D 1 x ) , HC(x, <’empty’, HC 1 x>) ,

9 Out (< <x , H C 1 x , H C 1 W , ’ He llo ’, $W>, s i g n (<x, H C 1 x , H C 1 W , ’ He l l o ’, $W>, l t k x )>) ,

10 Out (< <x ,˜ T I D 1 x>, s i g n (<x,˜ T I D 1 x>, l tk x )>) ]

Listing 1: Speciﬁcation of the hello tweet rule.

Model

Entering Twitter

create_entity_WR

create_entityR

Transaction

t_tweetR

conﬁrmation_status_*R

transaction_endedR

TID_chainR

Restriction

inequalityA

uniqueEntA

equalityA

Followership

followership_requestR

follow_welcome_tweetR

attestation_followR

Joining Community

hello_tweetR

welcome_tweetR

community_joinedR

Utility rules

reveal_ltkR

Property

Tracing

trace_WELCOMEs_HE...L

trace_WELCOMEr_WE...L

trace_PRIVATE_REQr...L

trace_VERIFstart_TRA...L

trace_FOLLOW_WEL...L

Guards

reach_GenL

reach_HELLO_sL

reach_HELLO_rL

reach_WELCOME_rL

Figure 2: The structure of the Tamarin Prover model.

of posting a Hello tweet by a user x, who wishes to

join the community, and contextually creates his/her

hash-chain (HC(...) fact, highlighted in Listing 1).

The second rule models the reception of the Hello

and the sending of the Welcome messages by W ; the

latter represents the conﬁrmation that x has joined the

community. The state reached by x is modelled by a

persistent fact !Community ID(...).

The last part of the registration (i.e., Followership

phase) concerns the building of the set V

of the fol-

lowers of x, which are designated as veriﬁers of the

transactions generated by x. We propose a simpli-

ﬁed model for this phase, as the entire sequence of

interactions would be tricky to model and to man-

age: concretely, we model the veriﬁcation step that

x sends the follow request to a user y who belongs to

the community. The Followership phase is modelled

by means of three rules: followership

request,

follow welcome tweet and attestation follow.

The Transaction section deals with the generation

and conﬁrmation of a new transaction. Let us assume

a user x, belonging to the community, wants to gener-

ate a new transaction addressed to a recipient r. The

ﬁrst task x has to do is to retrieve the chain containing

the IDs of the approved transactions; such a retrieved

chain is generated by means of another Tamarin rule

(i.e., TID chain).

The transaction is modelled with the rule t tweet

(shown in Listing 2). The application of this rule gen-

erates a new fact TID temp(...), where the ID of

the transaction is stored, whilst the TID chain(...)

is carried unchanged. This two-step mechanism is

mandatory as a new transaction ID can be added to

the chain only when it is approved by the community.

Moreover, user x ensures that user r belongs to the

community, too. At last, the transaction veriﬁcation

is modelled by two rules confirmation status 1

(shown in Listing 3) and confirmation status 0.

Both rules recover the TID chain and TID temp and

check that: 1) the user x has used its last hash-

chain element in the transaction (Eq(...) fact),

and 2) that the veriﬁer v and the recipient r are two

distinct users (Neq(...) fact). Then, depending

on the success or failure of the checks, v posts a

new tweet containing a boolean variable status set

to 1, or 0, and updates, or leaves unchanged, the

TID

chain, respectively. The last rule of the proto-

col is transaction ended and models the reception

of the conﬁrmation tweet.

On Formalising and Analysing the Tweetchain Protocol

785

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: Speciﬁcation 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: Speciﬁcation 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 deﬁned 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 veriﬁed (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

deﬁned 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 speciﬁc

rule is used, i.e., a speciﬁc 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, deﬁned 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: Speciﬁcation of a reachability lemma.

This rule models the sending action by a veriﬁer 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

veriﬁer 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

. We did not analyzed the other two prop-

erties, considered in the work by (Buccafurri et al.,

This property is meant to verify that each transaction

can always be veriﬁed by the Tweetchain community: see

SP1 in (Buccafurri et al., 2017b).

ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering

786

2017b), because of the modelling simpliﬁcation of the

veriﬁcation step adopted in this work.

The authenticity is veriﬁed for each exchanged

message, i.e., for each pair of send-receive rules, and

it corresponds to check the following property in the

LTS: “If user x receives a message m from user y, then

y has sent m to x earlier”. In the protocol model, the

sender authenticity is obtained by signing the mes-

sages with his/her private key, and any user can verify

the identity of the sender using the built-in message

theory of Tamarin that deﬁnes a signature scheme.

Thus, for a given message m exchanged in the reg-

istration scenario shown in Figure 1, we deﬁned two

different lemmas for the veriﬁcation of its authenticity

that account of the capability of the adversary to steal

the private key of the parties involved in the communi-

cation. Such lemmas are labeled as fake trace ...

and trace ...: in the former, the adversary is able to

steal conﬁdential data (i.e., the private keys) whereas

in the latter, he/she is not.

Listing 5 and Listing 6 show the two types

of lemmas used to check the authenticity of the

follow welcome tweet message. The lemma in

Listing 5 can be read as follows: “for each fol-

low welcome tweet, received by x at time instant i

with y as a sender, then there exists a time instant j,

subsequent to i, in which y has sent such a message to

x.”

1 l emma f a k e t r a c e F OL L OW W E L Cr F O L L O W W E L C s :

2 "All y x #i . F O L L O W W EL CO ME r e c e i v ed (y ,x) @

3 ==>

4 Ex #j. FO L L O W W E L C O M E s e n t ( y , x ) @ j & j<i"

Listing 5: Speciﬁcation of a fake trace ... lemma.

The trace ... lemma (Listing 6) has two more con-

straints (lines 3-4) in the premise than the previous

lemma (Listings 5). Such constraints limit the capa-

bility of the adversary to steal the private key of any

user involved in the communication, i.e., the adver-

sary is not able to impersonate him/her.

1 l emma tr a c e F O LL O W W E L C r F O L L O W W E L C s :

2 "All y x #i . ( F O L L O W W EL CO ME r e c e i v e d (y ,x )

3 & not ( Ex # r. RevLtk (x ) @ r)

4 & not ( Ex # r. RevLtk (y ) @ r))

5 ==>

6 Ex #j. FO L L O W W E L C O M E s e n t ( y , x ) @ j & j<i"

Listing 6: Speciﬁcation of a trace ... lemma.

It is straightforward that for these messages it is cru-

cial to check that the adversary cannot impersonate

other users, and, thus, we expect that the analysis

gives different results between fake trace... and

trace ... lemmas. The analysis results of the most

relevant lemmas are reported in Table 1.

Table 1: Results for the Tweetchain protocol.

Lemma Result

fake trace WELCOMEs HELLOs false

trace WELCOMEs HELLOs true

fake trace WELCOMEr WELCOMEs false

trace WELCOMEr WELCOMEs true

fake trace PRIVATE REQr PRIVATE REQs false

trace PRIVATE REQr PRIVATE REQs true

fake trace FOLLOW WELCr FOLLOW WELCs false

trace FOLLOW WELCr FOLLOW WELCs true

As mentioned in Subsection 2.2, when modelling

large protocols in Tamarin, it might happen to run

into partial deconstruction, and it happened for the

Tweetchain protocol, too. In fact, most of the proofs

of non-trivial lemmas of our model did not termi-

nate, because the tool had troubles in determining the

source of a variable (namely, the tweet ID TID).

To overcome this issue, a source lemma has been

added. Such a lemma helps in the pre-computation

phase, as it adds information useful to the model

checker. In particular, in this case, the source lemma

expresses that whenever a t tweet (containing the

TID variable) is used, then either the adversary stole

and sent it over the public channel or a TID chain

rule has been applied before.

Table 2 shows the comparison of the model anal-

ysis with and without the source lemma.

Table 2: Comparison of veriﬁcation with and without

source lemma.

Lemma Source No Source

reach FOLLOW WELCOME s true non-term

reach TRANSACTION s true non-term

fake trace WELCs HELLOs false false

trace WELCs HELLOs true non-term

fake trace PR REQr PR REQs false non-term

trace PR REQr PR REQs true non-term

fake trace F WELCr F WELCs false non-term

trace F WELCr F WELCs true non-term

Finally, some data about the analysis times are re-

ported. Far from being a formal performance analy-

sis of Tweetchain model solution, the proposed model

has been solved in batch mode using the follow-

ing HW/SW conﬁguration: a Linux Ubuntu Server

20.04.1 LTS hosting a Tamarin 1.6.0 and running

on a quad-code Intel(R) Xeon(R) CPU E5-2650L v4

1.70GHz, with 8 Gb of RAM. In case of analysis ter-

mination, it took at most few minutes to analyse each

lemma.

On Formalising and Analysing the Tweetchain Protocol

787

4 DISCUSSION AND

LIMITATIONS

The discussion of the main results of the case study

is reported in three main threads: modelling, analysis

and process.

4.1 Modelling

The language of Tamarin has been proved to be a good

tool for the modelling of security features in commu-

nication protocols.

This fact is because Tamarin provides primitives

oriented to security modelling: elements as hashing,

encryption, fresh value computation, represent a valu-

able aid for the modeller.

On the other hand, the difference in the scope

between Tamarin and other “general-purpose” model

checkers is reﬂected by some modelling choices that

make Tamarin not perfectly ﬁtting into the problem

here tackled. One of the main limitations of the lan-

guage is constituted by the absence of a way to model

arrays. Such a modelling element is present in other

model checkers — e.g., NuSMV and SPIN — and al-

lows to model hash chains, a crucial passage in the

modelling of the veriﬁcation steps.

Another passage in the Tweetchain veriﬁcation

step that is hard to model is the consensus mecha-

nism where a sufﬁcient number of veriﬁers agree with

the sent transaction. The difﬁculty relies upon that, as

well as for integers and bytes, there is no possibility to

model arrays of protocol participants; hence, to model

a majority voting would be very hard in Tamarin.

In the proposed model, we have overcome all

these difﬁculties by reducing the weight of the com-

putational aspects model. In this way, it is easier to

obtain a partial model of the Tweetchain protocol. At

the best of our knowledge, indeed, Tamarin represents

a useful modelling framework for protocols and not

for code: computational aspects are tough to model in

Tamarin, and hence some alternatives should be ex-

plored and, in case, integrated.

A notable alternative is constituted by the State-

ful Applied Pi Calculus (SAPiC) formalism which

promises to improve the modelling power of the

Tamarin Prover with the possibility of dealing with

global protocol state. As multiset rewriting is a “low-

level” speciﬁcation language with no direct support

for concurrent message passing, encoding protocols

correctly becomes tricky. The difﬁculties found in

this paper are common to a part of the scientiﬁc com-

munity. SAPiC proposes a process calculus which is

a variant of the applied pi-calculus with constructs

for manipulation of a global state by processes run-

ning in parallel. The language can be translated into

Tamarin Prover, preserving all security properties ex-

pressible in a dedicated ﬁrst-order logic (Li et al.,

2019). Expressing the Tweetchain model according

to the SAPiC notation constitutes one of the future

works of this paper.

4.2 Analysis

A ﬁrst consideration is that the analysis phase

strongly depends on the model and that a ﬂawed

model always affects its capability to be analysable.

This is a fact for many formal languages, including

Tamarin where the tuning activity of a model is a non-

trivial task.

A great support is given by the interactive mode,

which is an excellent way to analyse (and debug) a

model and to shorten the model tuning task. It is far

from the intentions of Tamarin development group,

in fact, to create a “push-button” technology: using

the interactive mode is the only way to know if there

is some partial deconstruction left. Moreover, it pro-

duces graphs of the proofs of the lemmas, allowing

the users to explore the proof state space and to in-

spect the attack graphs. In this way, the modeller has

a previous feedback on the model enabling a faster

tuning phase.

In particular, for what concerns the partial decon-

struction, sometimes it is difﬁcult to ﬁnd the perfect

source lemma. In fact, it is necessary to solve partial

deconstruction, but it has to be proved true, as it helps

the tool in the precomputation phase and thus all the

proofs of the model rely on the sources lemmas. The

graphical user interface helps a lot in this task.

Furthermore, the authors have used the version

1.6.0 of Tamarin, that introduced the mechanisms of

automatic generation of source lemmas. This mech-

anism, as well as other restriction-related elements,

can dramatically improve the efﬁciency of the anal-

ysis process; instead, a less-than-perfect choice of

lemmas and restrictions can easily lead to a non-

terminating analysis process. As the Tamarin devel-

opers highlighted in (Cortier et al., 2020), this feature

only worked with many simple protocols, and thus it

was not useful for our large Tweetchain protocol.

4.3 Process

Formal modelling is an error-prone task, especially

when handling with complex protocols involving one

protocol relying on the security features exposed by

another protocol or security mechanism. As the com-

plexity and the pervasiveness of networked systems

grow, it is more and more uncommon to see “inde-

ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering

788

pendent” security solutions. The Tweetchain conﬁrms

this trend by relying, as an example, on the security of

Twitter, as the description of the protocol prescribes

(see Section 2.1

). As a consequence, there is a need

for a compositional method at both modelling and

analysis levels. By adopting the ﬁrst level, methods

and tools related to the reuse of existing models (e.g.,

a TLS model) into the wider model using this proto-

col, fosters the generation of larger models. By adopt-

ing the second level of composition, the reuse is at the

analysis level. At the best of our knowledge, there are

just a few attempts to support Tamarin composition at

model-level (Blot et al., 2017).

Another family of mechanisms is related to auto-

matic generation of Tamarin models from high-level

formalisms (e.g., from UML Sequence Diagrams).

Even if there are plenty of approaches able to generate

formal models automatically, there are no scientiﬁc

works speciﬁcally focusing on Tamarin. A scientiﬁc

paper proposes the generation of Tamarin model from

the Alice & Bob notation (Basin et al., 2015): this is

undoubtedly a starting point for future research tasks.

It is necessary to point out that a full automation of

the modelling task can be achieved only in case of

existing compositional approaches.

It seems natural that, even if this paper must limit

this discussion merely on the Tweetchain protocol,

many of the considerations here reported can be ex-

tended to other DLT approaches.

5 RELATED WORKS

In the scientiﬁc literature, many papers formalise and

analyse blockchain mechanisms. These works are

framed into the general research directions that the

scientiﬁc community has drawn on the topic of the

blockchain (Lu, 2019). It is worth to underline that

many of the works dealing with formal veriﬁcation fo-

cus on smart contracts; in particular, they apply both

traditional and speciﬁc methods (e.g., the application

of functional programming techniques as in (Bharga-

van et al., 2016)) to verify Solidity programs or to

deﬁne subsets of general purpose programming lan-

guages for securely writing smart contracts in a se-

cure manner. Two surveys of these works are in (Al-

makhour et al., 2020; Liu and Liu, 2019a).

Among all the formal veriﬁcation techniques,

model checking has received a lot of interest due to

the possible goal of a “push-button” technology able

The reader should note that also the Twitter au-

thentication mechanisms relies on external protocols as

HyperText Transfer Protocol over Secure Socket Layer

(HTTPS),Transport Layer Security (TLS), OAuth.

to verify security properties without the human inter-

action. Belonging to this category, there are the fol-

lowing works: (Liu and Liu, 2019b), which models

smart contracts using Colored Petri Nets (CPN); (Os-

terland and Rose, 2020), which translates Solidity

in Promela to verify them by SPIN; (Lahbib et al.,

2020), where the Event-B framework is used for both

modelling and analysing smart contract using both

model checking and simulation; (Nehai et al., 2018),

that models smart contracts with NuSMV.

Another recent and interesting survey starts with

a quantitative analysis of the research works in this

ﬁeld (Singh et al., 2020). The two most interesting

analysis dimensions are related to the addressed secu-

rity concern aspects and to the used formal method.

Fig. 3 reports the ﬁgure from the cited paper high-

lighting that less than one paper over ﬁve addresses

security concerns: please note that, in the pie chart,

both the absolute number of the works falling in a cat-

egory and the percentage with respect to the overall

considered works are provided (comma-separated).

Among the papers related to theorem proving that

aim at tackling the problem of security assurance of

blockchain protocols, we mention the work (Sun and

Yu, 2020) where the famous Coq theorem prover has

been successfully adopted.

At the best of our knowledge, none of these works

explicitly addresses cryptographic issues even if, the

work published in (Li et al., 2019) models and anal-

yses a smart contract protocol using Tamarin Prover.

Furthermore, authors of (Li et al., 2019) still focus

on the internal smart contract mechanisms while the

submitted paper is on the exchange protocol. An-

other missing aspect of the blockchains this work at-

tempts to model and analyse is related to the veriﬁca-

tion mechanism of transaction chains.

6 CONCLUSIONS

This paper has presented a concrete experience in

formal validation of a blockchain based protocol in

Tamarin. This experience conﬁrmed the value of the

Tamarin Prover as a valid tool for the modelling and

the analysis of security mechanisms; but, differently

from other case studies, the Tweetchain protocol puts

in evidence some limitations of the tool.

Section 4 reports a discussion on the limit of the

approach proposed in this paper and has also high-

lighted which are the points where to focus future re-

search effort. Among these, the ﬁrst points where to

focus research attention are: the deﬁnition of an au-

tomated methodology deriving formal models from

high-level formalisms (e.g., UML, Domain Speciﬁc

On Formalising and Analysing the Tweetchain Protocol

789

Figure 3: The issues and vulnerability aspects of smart contracts tackled by formalization approaches (Singh et al., 2020).

Modeling Language (DSML)) by using Model Driven

Engineering (MDE) approaches; the usage of differ-

ent model checkers that support array type naturally

and where it would be simpler to model chain of

hash codes (e.g. Promela and SPIN (Ben-Ari, 2008),

NuSMV (Cimatti et al., 2002), UPPAAL (Behrmann

et al., 2004) — where also timing issues could be con-

sidered).

ACKNOWLEDGEMENTS

The work of Mariapia Raimondo was formerly

funded by the grant “Orio Carlini” for young re-

searchers 2019 — GARR Consortium (Italy). Cur-

rently, she is granted by INPS — Istituto Nazionale di

Previdenza Sociale (Italy) — with the PhD program

— XXXVI cycle.

REFERENCES

Almakhour, M., Sliman, L., Samhat, A., and Mellouk, A.

(2020). Veriﬁcation of smart contracts: A survey. Per-

vasive and Mobile Computing, 67.

Basin, D., Keller, M., Radomirovi

c, S., and Sasse, R.

(2015). Alice and bob meet equational theories. Lec-

ture Notes in Computer Science (including subseries

Lecture Notes in Artiﬁcial Intelligence and Lecture

Notes in Bioinformatics), 9200:160–180.

Basin, D., Radomirovic, S., Dreier, J., Sasse, R., Hirschi,

L., and Stettler, V. (2018). A formal analysis of 5g au-

thentication. In Proceedings of the ACM Conference

on Computer and Communications Security, pages

1383–1396.

Behrmann, G., David, A., and Larsen, K. (2004). A tu-

torial on uppaal. Lecture Notes in Computer Sci-

ence (including subseries Lecture Notes in Artiﬁcial

Intelligence and Lecture Notes in Bioinformatics),

3185:200–236.

Ben-Ari, M. (2008). Principles of the SPIN model checker.

Springer-Verlag London.

Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Golla-

mudi, A., Gonthier, G., Kobeissi, N., Kulatova, N.,

Rastogi, A., Sibut-Pinote, T., Swamy, N., and Zanella-

eguelin, S. (2016). Formal veriﬁcation of smart con-

tracts: Short paper. In PLAS 2016: Proceedings of

the 2016 ACM Workshop on Programming Languages

and Analysis for Security, page 91–96, New York, NY,

USA. Association for Computing Machinery.

Blot, E., Dreier, J., and Lafourcade, P. (2017). Formal Anal-

ysis of Combinations of Secure Protocols. In 10th In-

ternational Symposium on Foundations & Practice of

Security, page 15, Nancy, France.

Buccafurri, F., Lax, G., Nicolazzo, S., and Nocera, A.

(2017a). Overcoming limits of blockchain for iot ap-

plications. In ACM International Conference Pro-

ceeding Series, volume Part F130521.

Buccafurri, F., Lax, G., Nicolazzo, S., and Nocera, A.

(2017b). Tweetchain: An alternative to blockchain for

crowd-based applications. Lecture Notes in Computer

Science (including subseries Lecture Notes in Artiﬁ-

cial Intelligence and Lecture Notes in Bioinformatics),

10360 LNCS:386–393.

Cimatti, A., Clarke, E., Giunchiglia, E., Giunchiglia, F., Pi-

store, M., Roveri, M., Sebastiani, R., and Tacchella,

A. (2002). Nusmv 2: An opensource tool for sym-

bolic model checking. Lecture Notes in Computer

Science (including subseries Lecture Notes in Artiﬁ-

cial Intelligence and Lecture Notes in Bioinformatics),

2404:359–364.

Cortier, V., Delaune, S., and Dreier, J. (2020). Automatic

generation of sources lemmas in tamarin: Towards au-

tomatic proofs of security protocols. Lecture Notes in

Computer Science (including subseries Lecture Notes

ForSE 2021 - 5th International Workshop on FORmal methods for Security Engineering

790

in Artiﬁcial Intelligence and Lecture Notes in Bioin-

formatics), 12309 LNCS:3–22.

Dai, F., Shi, Y., Meng, N., Wei, L., and Ye, Z. (2017).

From bitcoin to cybersecurity: A comparative study

of blockchain application and security issues. In

2017 4th International Conference on Systems and In-

formatics, ICSAI 2017, volume 2018-January, pages

975–979.

Dolev, D. and Yao, A. (1983). On the security of public key

protocols. IEEE Transactions on Information Theory,

29(2):198–208.

Kumar, N. and Mallick, P. (2018). Blockchain technology

for security issues and challenges in iot. In Procedia

Computer Science, volume 132, pages 1815–1823.

Lahbib, A., Ait Wakrime, A., Laouiti, A., Toumi, K., and

Martin, S. (2020). An event-b based approach for

formal modelling and veriﬁcation of smart contracts.

Advances in Intelligent Systems and Computing, 1151

AISC:1303–1318.

Lee, M. and Jang, D. (2020). A survey of blockchain se-

curity issues. JP Journal of Heat and Mass Transfer,

2020(Special Issue 1):29–35.

Li, X., Su, C., Xiong, Y., Huang, W., and Wang, W. (2019).

Formal veriﬁcation of bnb smart contract. In Proceed-

ings - 5th International Conference on Big Data Com-

puting and Communications, BIGCOM 2019, pages

74–78.

Lin, I.-C. and Liao, T.-C. (2017). A survey of blockchain

security issues and challenges. International Journal

of Network Security, 19(5):653–659.

Liu, J. and Liu, Z. (2019a). A survey on security veriﬁcation

of blockchain smart contracts. IEEE Access, 7:77894–

77904.

Liu, Z. and Liu, J. (2019b). Formal veriﬁcation of

blockchain smart contract based on colored petri net

models. In Proceedings - International Computer

Software and Applications Conference, volume 2,

pages 555–560.

Lu, Y. (2019). The blockchain: State-of-the-art and research

challenges. Journal of Industrial Information Integra-

tion, 15:80–90.

Meier, S., Schmidt, B., Cremers, C., and Basin, D. (2013).

The TAMARIN prover for the symbolic analysis of

security protocols. Lecture Notes in Computer Science

(including subseries Lecture Notes in Artiﬁcial Intel-

ligence and Lecture Notes in Bioinformatics), 8044

LNCS:696–701.

Nakamoto, S. (2009). Bitcoin: A peer-to-peer electronic

cash system.

Nehai, Z., Piriou, P.-Y., and Daumas, F. (2018). Model-

checking of smart contracts. In Proceedings - IEEE

2018 International Congress on Cybermatics: 2018

IEEE Conferences on Internet of Things, Green Com-

puting and Communications, Cyber, Physical and So-

cial Computing, Smart Data, Blockchain, Computer

and Information Technology, iThings/GreenCom/CP-

SCom/SmartData/Blockchain/CIT 2018, pages 980–

987.

Osterland, T. and Rose, T. (2020). Model checking smart

contracts for ethereum. Pervasive and Mobile Com-

puting, 63.

Panwar, A. and Bhatnagar, V. (2020). Distributed ledger

technology (dlt): The beginning of a technologi-

cal revolution for blockchain. In 2nd International

Conference on Data, Engineering and Applications

(IDEA), pages 1–5.

Singh, A., Parizi, R., Zhang, Q., Choo, K.-K., and Dehghan-

tanha, A. (2020). Blockchain smart contracts formal-

ization: Approaches and challenges to address vulner-

abilities. Computers and Security, 88.

Sun, T. and Yu, W. (2020). A formal veriﬁcation frame-

work for security issues of blockchain smart contracts.

Electronics (Switzerland), 9(2).

Whiteﬁeld, J., Chen, L., Kargl, F., Paverd, A., Schneider, S.,

Treharne, H., and Wesemeyer, S. (2017). Formal anal-

ysis of V2X revocation protocols. Lecture Notes in

Computer Science (including subseries Lecture Notes

in Artiﬁcial Intelligence and Lecture Notes in Bioin-

formatics), 10547 LNCS:147–163.

Whiteﬁeld, J., Chen, L., Sasse, R., Schneider, S., Treharne,

H., and Wesemeyer, S. (2019). A symbolic analysis of

ECC-based direct anonymous attestation. In Proceed-

ings - 4th IEEE European Symposium on Security and

Privacy, EURO S and P 2019, pages 127–141.

Yu, Y., Li, Y., Tian, J., and Liu, J. (2018). Blockchain-based

solutions to security and privacy issues in the internet

of things. IEEE Wireless Communications, 25(6):12–

18.

On Formalising and Analysing the Tweetchain Protocol

791