A Trust and Reputation System for IoT Exploiting Distributed Ledger Technology

The advent of Bitcoin, and consequently Blockchain, has ushered in a new era of decentralization. Blockchain enables mutually distrusting entities to work collaboratively to attain a common objective. However, current Blockchain technologies lack scalability, which limits their use in Internet of Things (IoT) applications. Many devices on the Internet have the computational and communication capabilities to facilitate decision-making. These devices will soon be a 50 billion node network. Furthermore, new IoT business models such as Sensor-as-a-Service (SaaS) require a robust Trust and Reputation System (TRS). In this paper, we introduce an innovative distributed ledger combining Tangle and Blockchain as a TRS framework for IoT. The combination of Tangle and Blockchain provides maintainability of the former and scalability of the latter. The proposed ledger can handle large numbers of IoT device transactions and facilitates low power nodes joining and contributing. Employing a distributed ledger mitigates many threats, such as whitewashing attacks. Along with combining payments and rating protocols, the proposed approach provides cleaner data to the upper layer reputation algorithm.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 3

05/08/2018

Blockchain for the IoT: Opportunities and Challenges

Blockchain technology has been transforming the financial industry and h...
04/14/2020

Witness-based Approach for Scaling Distributed Ledgers to Massive IoT Scenarios

Distributed Ledger Technologies (DLTs) are playing a major role in build...
06/02/2020

Preventing Denial of Service Attacks in IoT Networks through Verifiable Delay Functions

Permissionless distributed ledgers provide a promising approach to deal ...
09/20/2021

Blockchain Security by Design Framework for Trust and Adoption in IoT Environment

With the recent advances of IoT (Internet of Things) new and more robust...
05/15/2020

On Congestion Control for Distributed Ledgers in Adversarial IoT Networks

Distributed Ledger Technologies (DLTs) (the agnostic term for blockchain...
06/29/2018

A Rolling Blockchain for a Dynamic WSNs in a Smart City

Blockchain is one of the most popular topics for discussion now. However...
03/11/2019

On the Convergence of Blockchain and Internet of Things (IoT) Technologies

The Internet of Things (IoT) technology will soon become an integral par...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

The Internet of Things (IoT) will transform the future and encompass almost everything we deal with on a daily basis [23]. It has not yet reached its full potential and there are serious concerns that must be addressed before full adoption [35]. There are now billions of nodes on the internet but their operation is hindered by the centralized infrastructure and vendor incompatibilities [25].

IoT nodes open up a new business model in which devices sell their data [28]. Each device can simultaneously be a buyer an seller. Consequently, the number of sellers is similar to the number of buyers. The number of devices connected to the internet in 2020 was approximately 26 billion [6] and this is projected to rise to 75.4 billion in 2025 [27].

The resulting economic impact is expected to be between $3.9 trillion to $11.1 trillion annually by 2025 [23], the maximum of which is equivalent to of the world economy. However, while the IoT will have a significant economic impact, it does not conform to traditional business models [45]. The success of IoT businesses depends on having honest service providers and online merchants, which may be challenging given the presence of fraudulent users [34]. As a result, we need to trust the nodes that we are going to interact with. The term trust refers to the subjective trustworthiness belief of an entity toward another; on the other hand, the reputation shows the system view of confidence toward a particular entity [10].

While centralized Trust and Reputation Systems (TRSs) may be adequate for the current environment, they are unsuitable for the IoT of the future [42]. These conventional TRSs have deficiencies such as a Single Point of Failure (SPOF). Current distributed TRSs have several drawbacks such as implementation complexity, susceptibility to attacks, and ineffectiveness [16]. A key issue with these systems is the separation of payment and evaluation systems.

Future online services can be divided into two categories [33], one of which requires stronger authentication methods or services that use more robust TRSs. The first category is more straightforward to implement, but it will threaten freedom of speech. Moreover, TRSs can be incorporated into a wide range of services such as electronic marketplaces, multi-agent marketplaces, cooperative applications, and file sharing [32].

The initial Internet concept was a decentralized network. From its inception, most decentralized services were successfully implemented while others such as digital currency seemed impossible to develop [7, 12]. The design of a distributed digital currency is a classic computational problem called the Byzantine Generals Problem [19]. The solution requires reaching consensus in an environment with nodes that are susceptible to arbitrary errors. The arrival of Bitcoin [26] and its underlying technology, Blockchain, probabilistically solves this consensus problem on a large scale in an asynchronous network. Bitcoin is the first truly distributed digital currency. It employs a distributed ledger to record who owns money. The ledger security and its records are guaranteed as long as of the network contributors are honest players [26].

Distributed ledger technology (DLT) can be employed in a TRS to provide standardized interfaces and merge payments and rating systems. Furthermore, DLT based solutions can handle IoT generated requests in a timely manner. Blockchain through accountability, immutability, and security can be used to exchange data between digital twin virtual copies of physical objects or processes [36]. Moreover, Blockchain self-management and secure Peer-to-Peer (P2P) communications can lower IoT operational costs [17]. Blockchain and distributed ledgers for IoT applications, e.g., healthcare, vehicular networks, and energy, were investigated in [40, 11].

The rest of the paper is organized as follows. Section 2 introduces Blockchain and Tangle technologies and challenges, and presents the related work. The proposed DLT and TRS are introduced in Section 3 and the system evaluation is presented in Section 4. Finally, some conclusions and suggestions for future work are given in Section 5.

2 Background and Related Work

In this section we present the background and review previous work regarding Blockchain and Tangle distributed ledgers.

2.1 Blockchain and Tangle

Blockchain [26] was proposed to provide consensus in a mutually untrusted environment for implementation of a digital currency. It can be defined as a Byzantine fault tolerant state machine replication. In a Blockchain network, some nodes (miners or validators), collect broadcast transactions and put them into blocks to facilitate batch processing. A consensus algorithm is used to manage agreement between nodes. While Blockchain is considered a disruptive technology, it has a scalability problem. To solve this issue, other DLTs have been considered as an alternative solution.

Furthermore, Blockchain consists of four subcategories, permissioned, permissionless, private and public, which can overlap with each other. The definition and use case of each has been provided by [41]. Examples of permissionless public and permissioned Blockchain targeting IoT are given in [21] and [31].

Tangle is a DLT solution that omits miners from the design [30]. Every transaction generator is a miner and validator. In Tangle, each new block has one transaction and a Proof-of-Work (PoW) problem must be solved to validate two other blocks. The roles of transaction generator and validator are combined so unlike Blockchain there is no transaction fee. By merging responsibilities, the load is distributed which results in better system scalability.

While Tangle can theoretically solve the scalability problem, in practice it has flaws that can be traced back to its design. Tangle PoW is generated per usage, so the number of requests indicates the resilience of the network to attacks, e.g., double-spend. As a result, request load fluctuations in the IoT (or any network based traffic), will increase the chance of a successful attack on the network. Although Tangle considers weak IoT device constraints, transaction generation is impractical for a typical IoT device even with lower PoW difficulty. Other drawbacks of Tangle include infeasibility of smart contract implementation, lack of timestamps, and the need for a centralized coordinator in the initial stage of the network.

2.2 Related Work

In general, Trust and Reputation Systems (TRSs) can be divided into three categories: centralized, semi-centralized, and distributed [15]. Centralized systems like eBay have a number of serious flaws such as a SPOF, need for a Trusted Third Party (TTP), a TTP bottleneck, infeasibility in data filtration before feedback aggregation, and an unalterable aggregation algorithm [15, 16].

In semi-centralized systems, a portion of the work is done on a centralized server [15]. This category inherits the flaws of a centralized architecture, but they are less severe. In [14], the first semi-centralized solution for P2P networks was proposed. This solution introduced debit-credit and credit-only reputation computations. However, the inability to mitigate Sybil attacks and collusion are two major defects in addition to the flaws of centralized systems.

In [18]

, a distributed system for file sharing applications was introduced. The reputation data is stored on multiple nodes and a torrent like approach is used to find swarms. A Markov chain based solution is employed in the feedback aggregation phase. However, there is no way to associate feedback with the corresponding transactions.

In [5] a distributed, adaptive and scalable TRS for applications of SOA-based IoT systems was proposed. In this system, nodes with constrained capabilities hold only a fraction of the trust information of the nodes. Moreover, the social relationship between IoT nodes is considered in the computations. As with other TRSs that do not employ DLT, this system has the drawback of separate rating and payment protocols.

A distributed TRS considering user privacy for IoT applications was proposed in [2]. This system has three entity types, devices, users, and a public bulletin board. A non-interactive zero-knowledge proof is employed to preserve user privacy. The public bulletin board is an append-only database that keeps encrypted versions of the feedback with the non-interactive zero-knowledge proofs for each transaction. In this solution, users cannot alter the aggregation algorithm or filter its input data, which severely limits the degree of personalization.

In [9], the approach in [14] was extended to be on top of a Bitcoin-like Blockchain. A single dimension feedback structure which provides a rating of 1 if the requester receives the file and 0 otherwise is used to eliminate biased ratings. In this system, once a miner receives the broadcast feedback it contacts both parties using the addresses included in the feedback in order to mitigate replay attacks. This requires that both entities stay online and have a valid public IP address, which is not realistic. Furthermore, this system is prone to IP spoofing attacks. It also does not consider the number of miners, which can put a heavy burden on the nodes in case of direct contact.

An extended version of the system in [1] that uses Blockchain to provide a privacy-preserving TRS was introduced in [37]. Both approaches use a token based system to send feedback. In [1], a centralized entity is responsible for issuing new tokens and this is replaced with a Bitcoin-like Blockchain in [37]. In this system, the feedback is held in the Blockchain and the miners are rewarded with tokens when they mine a new block. A blind signature scheme is used to preserve the privacy of the rater. While the scarcity of tokens prevents Sybil attacks, it may also limit merchants in initiating new transactions.

A TRS using two Blockchains was presented in [10] to connect islands of trust which are interoperable groups of IoT devices and protocols. This system assumes that every IoT node has a device that helps it interact with the Blockchains. IoT devices can only collaborate if the device owners have a valid contract which is deployed on the cloud. Each time an IoT device wants to use a service in conjunction with its helper, it creates a new obligation. The obligations are stored in one of the Blockchains and are addressed for settlement on the other Blockchain. However, it is unclear how the obligations and contracts can be used for automatic machine-to-machine interactions. The cloud that stores the contracts will be a bottleneck and SPOF in this system. Further, the need for helper devices is a significant drawback.

A new Sybil-resistant scalable Blockchain called TrustChain was proposed in [29]. In TrustChain, each node is only responsible for storing its transactions. Each block in the chain contains the transaction data along with two references, one to the previous block and the other to the last block in the counterpart Blockchain. This data structure will not prevent double-spending, but it can detect it. NetFlow is also introduced to calculate reputation using an interaction graph and max-flow algorithm. The interaction graph is a weighted graph in which the vertices represent nodes and the edges show the connections between them. As the nodes are responsible for keeping their transaction history, an attacker can perform an anonymous Denial of Service (DoS) attack against another party. Furthermore, the nodes need to be online to answer queries.

A new TRS based on Ethereum smart contracts was introduced in [22]. These contracts have 17 states in the process of a trade. The system employs an ERC-20 compatible token which can be used by the smart contracts. It inherits the drawbacks of Ethereum and cannot support the load of IoT networks.

A reputation system for vehicular networks was proposed in [43]. In this system, neighboring vehicles which are traveling together are clustered to form a public permissioned Blockchain. New vehicles that want to join the network must get permission from a trusted authority. In each round, a node is randomly selected as the miner. As there is a trusted authority in the system, it cannot be used for the open IoT network. Further, inter-cluster data exchange was not considered and no mechanism was given for the trusted authority to revoke a registration. The case of trusted authority key leakage was also not examined.

3 Proposed Method

In this section, the proposed method is introduced. The goal is to solve the problems with Blockchain and Tangle as well as previously developed TRSs. Fig. 1 shows the protocol relationships and dependencies with the dependents in the top layer. This shows that the Blockchain is independent of Tangle, but Tangle is partially reliant on Blockchain. Further, the Bundle, Initial, and Rep protocols only require Tangle.

The Bundle handles financial transactions in an Unspent Transaction Output (UTXO) like manner, similar to Bitcoin. Each transaction has unspent transactions as input and introduces new transactions as output to the network. A spent transaction cannot be used in future transactions. The Initial protocol manages new entities entering the network and facilitates service discovery. Rep is a precompiled smart contract that assumes the role of a TRS. The WeakReq protocol relies on both Blockchain and Tangle and helps weak IoT devices use the platform efficiently. In the bottom layer, Blockchain and Tangle hold the data required for the upper layers.

Fig. 1: The protocol stack of the proposed method.

The Initial message, which is part of the Initial protocol, has a description of the service provided with a pointer to the InterPlanetary File System (IPFS) [3] file that contains further information about the service and/or service provider. This message aids service discovery and future protocol additions, e.g., the messaging protocol over the platform. This protocol further secures the TRS by preventing whitewashing attacks as will be discussed in Section 4.

3.1 Underlying ledger

The implementation of Tangle in IOTA [30]

assumes that the transaction PoW guarantees the security of the ledger. As the generation of new transactions is on-demand, the Tangle load fluctuates during the day. For example, when the network passes peak time in San Francisco, it takes about seven hours to reach the next metropolis, Sydney. Thus, the network has a lower transaction load and consequently, less PoW. As the PoW algorithm guarantees the security of the ledger, this lower PoW increases the probability of the ledger being compromised.

As IOTA nodes have no interest in generating useless transactions, we introduce a Blockchain to incentivize them. Each Blockchain block contains hashes of dummy transactions generated by the nodes to increase the Tangle hash rate. The number and weight of dummy transactions indicates the priority of the block to be added to the Blockchain. The coinbase (award dedicated to block miners), along with the WeakReq fee, provide the necessary motivation for participation. Moreover, this entanglement of Blockchain and Tangle eliminates the threat of a liveness attack. This attack and corresponding countermeasures will be discussed in Section 4.

Mutual tethering is practiced with IOTA to prevent double-spending via network splitting. When a new full node wants to join the network, it must add 7 to 10 full nodes to its peer list. The counterparts should also add the address of this node. This requires that nodes trust each other, which contradicts the principle of distributed systems. Further, with IOTA, nodes can only see their statically added neighbor peers. By using Blockchain and dumb messages, we can eliminate mutual tethering and incentivize new full nodes to join the network.

Figs. 2 and 3 show how the Tangle can be targeted for a double-spend attack and how dumb messages can prevent it, respectively. Boxes with attack labels are attack messages to outweigh message D resulting in a double-spend transaction. In Fig. 2, the attacker can successfully launch an attack as the network load is low and consequently can overwrite the history stored in the ledger, i.e., previously confirmed transactions. On the other hand, the dumb messages in Fig. 3 added by the honest nodes will prevent the attack to achieve the desired result.

Fig. 2: The Tangle under attack without dumb messages.
Fig. 3: The Tangle under attack with dumb messages.

In the proposed method, IoT devices are grouped into three categories, devices with the capability to exploit the distributed ledger, devices that have a helping server, and devices with low capabilities and no helping server. The first two categories can use the ledger seamlessly. However, the third class does not have a server to aid in interacting with the DLT nor the ability to generate or store transactions. These devices can use the WeakReq protocol which facilitates transaction generation.

Fig. 4 illustrates the WeakReq protocol. First, the node sends a WeakReq request which does not need PoW or previous transaction verification (Fig. 4 step 1). This request contains the number of transactions that the node will generate in the future, the total fee the node is willing to pay, and a Proof-of-Burn bundle which mitigates DoS attacks. As the coins used in Proof-of-Burn are not transferable, the node cannot generate an arbitrary number of fake requests due to the associated cost. Once the request has propagated through the network, a Blockchain miner will place it into a block (Fig. 4 steps 2, 3). Then, the node can send new transactions which, like the request, have no PoW or verification and will be broadcast on the Tangle (Fig. 4 step 4). These transactions should be valid and have a bundle that contains a fee (a portion of the total fee in the WeakReq request), to incentivize the miner to connect them to the Tangle (Fig. 4 step 5).

Fig. 4: The WeakReq protocol.

Devices with low capabilities and no helping server may not trust a gateway to connect with the distributed ledger. Raw ledger data or Simplified Payment Verification (SPV) [26] cannot be used to receive and validate blocks delivered from gateways. The data passed to these devices should not be large and needs to be easy to verify. They can utilize the minimal verification client INcentivized Node Network (IN3) [4] or the method proposed in [20].

Algorithms 1 and 2 illustrate the WeakReq protocol for weak devices and miners, respectively. The parameters used in these algorithms are described in Table I.

Parameter Description
WeakReq request sent by a weak device
Fee the weak device will spend on
the current
Number of messages the weak device will
spend on the current
Proof-of-Burn transaction embedded inside
the
Address of the miner that adds
to the blockchain
Hash of the previous block
Hash of the current block header
Nonce used for calculating the hash
Aids the sender node in finding
the desired fee in the network
TABLE I: Algorithm Parameters
Connect to the gateway;
Choose , and ;
Set to an interval;
Broadcast ;
while  is not added to the Blockchain do
       Wait for a miner to pick the ;
       if  expires and node is willing to pay more then
             Choose higher ;
             Broadcast a new ;
            
      else if node is NOT willing to pay more then
             return -1;
            
      
end while
Stop ;
Receive ;
for  to  do
       Send a with to ;
      
end for
Algorithm 1 Weak Devices using WeakReq
while true do
       Listen to broadcast messages;
       Pick a profitable and check its validity;
       Add to a block;
       do
             Add dumb messages to the block and/or calculate with a new ;
            
      while Calculated hash is less than threshold;
end while
Broadcast the block;
for  to  do
       Validate ;
       if  is valid then
             Send a dumb or normal message with a reference to to add to the Tangle;
            
       else
             Ignore ;
            
      
end for
Algorithm 2 Miner Picking WeakReq Requests

3.2 Trust and reputation protocol

Every TRS has three phases, feedback generation, feedback propagation, and feedback aggregation [38]. As the third phase is subjective and varies based on the use cases, it is not considered, so the proposed model only implements the first two phases. The objective is to collect more accurate and reliable data to ease the last phase. In order to cover a wide range of aggregation algorithms, the trust and reputation preconditions are kept to a minimum while sacrificing some privacy concerns.

The proposed TRS (Rep protocol), can work with or without a mediator. The mediator can be a smart contract or human and is used to solve locked disputes. Figs. 5 and 6 show the Unified Modeling Language (UML) sequence diagrams of the trade procedure without and with a mediator, respectively. The buyer and seller can negotiate using a mediator in a Transport Layer Security (TLS) handshake-like approach. The buyer suggests a list of mediators in the request message and then the seller sends a list of preferred mediators considering the buyer’s list. Finally, the buyer chooses a mediator based on the received list. When a malicious user is detected, the combinations of buyer requests and seller acknowledgments prevent further damage to the seller’s reputation on future transactions. In the case of an agreement violation, either side can issue a complaint which will put the mediator in control of the whole process. In the case of a dispute, the mediator has the right to release the locked money. Otherwise, the buyer will release it as a normal transaction process. At the end, the buyer sends a review of the trade.

There is a NoFeedback flag that can be set by the seller in the acknowledgement of the buyer’s request. This can be used to opt out of the Rep protocol if the seller is not interested. In the validation phase, either party can use the ledger data along with their desired algorithm to assess the reputation of the other party. This validation process can be outsourced to another node as a service. The combination of service discovery and reputation validation as a separate service can be performed by nodes in the network, leading to an open-data search engine for IoT nodes.

Fig. 5: The trade procedure without a mediator.
Fig. 6: The trade procedure with a mediator.

4 System Evaluation

In this section, the performance of the proposed system is evaluated. In the experiments, we assume the Blockchain miners are far more powerful than typical IoT nodes. As a result, it is relatively easy for miners to do PoW in the Tangle. Then, the TRS is assessed against conventional attack models. All experiments are conducted using a PC with an Intel i7-2630QM processor and 8 GB of memory. A Proof-of-Concept (PoC) of the proposed method has been implemented and can be accessed from the Github111https://github.com/amidmm/myChain repository. For the PoC, we implemented the Tangle and Blockchain from scratch with a few simplifications. Furthermore, several important attacks from [13, 24, 15, 16] are considered for the proposed system.

4.1 Performance analysis

In this experiment, we analyze the system performance by evaluating standard messages using a target of 15 and 20 leading zeros for the PoW and WeakReq protocol. The SHA3-512 algorithm is used for the PoW. We compare our results with those in [29] for the same parameters. Fig. 7 presents the results of this experiment using a random dataset and one node. This shows that the number of Transactions Per Second (TPS) for the WeakReq protocol is relatively high as there is no need to calculate the PoW and find two reference transactions. The TPS for the standard message with PoW 15 or 20 in the proposed method is lower than with the approach in [29], and it has the benefit of double-spend prevention. We assumed the in the Bitcoin and Ethereum hypothetical cases, the network is private to our nodes. Therefore, it’s impossible to happen in the real world. On the other hand, the Bitcoin and Ink protocol (Ethereum) are measured against mocking real-world Blockchains.

Fig. 8 shows that the proposed method is linearly scalable compared to other methods. As the nodes in the TrustChain keep their data locally, the spread of nodes (non-neighbouring nodes), will impact the performance of the system.

Fig. 7: Performance of the proposed method and the approach in [29] for one node.
Fig. 8: Performance of the proposed method and the approaches in [29],[26] and [39] for 10 nodes.

4.2 Liveness Attack on the Ledger

In this attack, a malicious miner can control blocks recently proposed to the Blockchain. While rewriting the history needs a has rate of more than 50%, to perform this attack, an attacker only needs 20% of the network total hash power, which is not unrealistic given the events in recent years. The attacker can keep two competing forks in balance by holding and withdrawing blocks. The proposed ledger can mitigate this attack by changing the winner-take-all strategy [21], [44]. In a conventional blockchain, the winning miner gets the reward and the remainder abandon trying to find a block. As a result, no matter how much effort has been expended in trying to find a block, their computational effort is wasted.

A block does not have a single hash in our method, but rather contains a list of dumb message addresses. As mentioned previously, the dumb messages serve two purposes, keeping the hash rate of the Tangle high and connecting WeakReq messages to it. Instead of a single hash reaching a target, the next block has an accumulated number of hashes with a relaxed target. To change the winner-take-all strategy, we introduce the sliding block window shown in Fig. 9 for miners to put dumb messages into new blocks. The sliding window is indicated by the red box and the dumb messages corresponding to a block have the same border color. The miners collect dumb message addresses corresponding to the blocks in the sliding window to generate a new block (block ). The sliding window is one step behind the current block to overcome any problems that may arise due to the asynchronous nature of the Tangle.

If a miner fails to find the next block (block ), it only loses the computations for the dumb messages corresponding to block . This is because the window has moved one step forward, and computing block requires the dumb messages associated with blocks , , and .

In the Bitcoin network, the target is defined based on a fixed minimum difficulty (which is ), and the current network difficulty . To relax the problem and maintain the system security, we lower by a relaxation factor but increase the number of hashes required. Let be the pending transactions in the memory pool of the node, the hash of the previous block, the current nonce, and the total hash rate of the network.

As do not want to lower the security of the system by lowering the hash rate of the consensus algorithm, we adjust the number of hashes required and the difficulty while maintaining the probability of finding a block given the total hash rate. The probability of finding a hash lower than a target probability given and is

(1)

Let

be the random variable corresponding to finding the desired hash with unrelaxed parameters and

be the random variable corresponding to finding the desired hash with relaxed parameters. Then

where denotes expected value and is the probability with the new parameter. We have

and

where

Equating and gives

(2)

so the number of dumb messages required should be the same as the relaxation factor.

The mining algorithm now has a semi-progressive characteristic, so a miner with 20% of the network computational power cannot initiate a liveness attack. An attacker may be successful in proposing some blocks, but the cumulative hash power of the remaining nodes over the sliding window will ultimately surpass that of the attacker.

Fig. 9: Progressive block mining and correlation of Blockchain and Tangle.

4.3 Self-promoting attack

In this attack, an adversary wants to overvalue its reputation artificially. In its most straightforward form, the attacker continuously rates itself. This is easy to detect and prevent as the identities are fixed and the user interaction history is immutable. However, attacks based on collusion or fake identities are more difficult to handle. We consider this form later when Sybil attacks are discussed. Moreover, one can take the average of repeated ratings from the same user in the feedback aggregation phase to lower the impact of their opinion on the reputation calculation.

4.4 Whitewashing Attack

In this attack, an adversary attempts to remove the history of its misbehavior. This can be done by altering the history data or undermining the effectiveness of the system by excluding negative feedback from reputation calculations. As the data stored in the distributed ledger is immutable, it cannot be altered without conducting a 51% attack. Furthermore, as the reputation calculations are centralized with distributed data, an adversary cannot alter them. In systems where newcomers have a high score, an adversary may attempt to change his identity frequently. To prevent this form of attack, a newcomer should have no reputation unless it is obtained through PoB and PoW with their Initial message.

4.5 Slandering Attack

In a slandering attack, an adversary tries to reduce the reputation of another user by sending fake negative feedback. In its most obvious form, the attacker directly sends reviews of the victim. The proposed system prevents this form of attack by requiring permission from the seller before any trade happens. The attacker may blindly send negative reviews to other users. In this case, a seller may check the attacker history and deny their request for a trade. Furthermore, as financial transactions are necessary to send reviews, the attacker will lose money doing this.

4.6 Denial of Service

In a Denial of Service (DoS) attack, an adversary tries to make the system unavailable. In a network-level attack, the attacker floods the system with dummy messages. To carry out this attack, the adversary must attack the entire network or a specific node. As the proposed platform is a distributed system, it is intractable to attack the entire network, and there is no straightforward way to find a node address. Consequently, the platform is immune to network-level DoS attacks. In an application-level DoS attack, the adversary attempts to exploit vulnerabilities of the application. The attacker can target the WeakReq protocol by sending fake requests, but the request PoB prevents this attack. Other messages have a PoW which makes a DoS attack impossible.

4.7 Ballot Stuffing Attack

In a ballot stuffing attack, an attacker attempts to send more reviews than the number allowed per trade. Coupling reviews with financial transactions and seller trade approvals prevents this attack.

4.8 Sybil Attack

In a Sybil attack, an attacker creates numerous fake identities. This type of attack is the most difficult to mitigate at low-level. Preventing a Sybil attack by PoW will sacrifice system availability. Due to this, while we use PoW for mitigating Sybil attacks on the consensus level, we entrust the upper-layer feedback aggregation phase to provide a defense mechanism against these attacks. For example, the feedback aggregation phase can use a Markov chain or flow based algorithm which gives no credit to fake identities.

4.9 Replay Attack

In a replay attack, an attacker repeatedly sends valid data that was captured previously. Systems that are vulnerable to such an attack will accept the old data as legitimate messages. In [8], a replay attack against IOTA was proposed assuming address reuse, which is not recommended by the IOTA foundation. However, the proposed system employs sequence numbers and timestamps, and associates blocks with Tangle transactions, which prevents replay attacks.

4.10 WeakReq Attack

An attack scenario which may seem feasible is using the WeakReq protocol to carry out a DoS attack. In this attack, an adversary generates a WeakReq request with a high number of transactions but a low total fee. This attack will fail since miners will have no motivation to satisfy the request. If the requester picks this request as a miner, they must generate a message for each of their WeakReq messages, which leaves them with no gain.

4.11 Trust and Reputation System Evaluation

We evaluated the proposed TRS by emulating a network with a mixture of malicious and honest nodes and a majority of host nodes, approximately 200 and 300, respectively. The malicious nodes were divided into subgroups that randomly pick a target and perform the attacks listed in this section. In the experiments, we used two feedback aggregation methods to evaluate the reputation of each node. First, we used the average of the feedback with a trustworthiness threshold of 0.5 where the rating and reputation scores are in the range 0 to 1. A value of 1 indicates fully trusted while 0 denotes fully distrusted. If the node reputation exceeds the threshold, a trade is initiated, otherwise it is discarded. Second, we used the aggregation method NetFlow introduced in [29].

It is assumed that one person controls all malicious nodes. As a result, there can be inter-group and intra-group collusion between these nodes. The malicious nodes attack an arbitrary number of honest nodes. Then, 100 honest nodes were picked randomly and asked to assess the reputation of all nodes. The system F-Score is given by

(3)

where

and

Fig. 10 presents the F-Score for 10 repetitions of the experiment using a random dataset. These results show that the proposed method provides cleaner data for feedback aggregation compared to TrustChain.

Fig. 10: Reputation F-Score from the feedback aggregation phase using the average and NetFlow aggregation methods.

5 Conclusion and Future Work

In this paper, a new trust and reputation system was introduced which employs a distributed ledger combining Blockchain and Tangle in order to merge the payment and rating systems. The use of a distributed ledger helps eliminate false feedback and mitigates other attacks against the system. In the future, a virtual machine can be considered to implement smart contracts as a mediator for trades. Moreover, privacy preserving techniques can be applied at the ledger protocol level to lower the probability of user information leakage.

References

  • [1] E. Androulaki, S. G. Choi, S. Bellovin, and T. Malkin (2008) Reputation systems for anonymous networks. In Proceedings of the International Symposium on Privacy Enhancing Technologies Symposium, pp. 202–218. Cited by: §2.2.
  • [2] M. Azad, S. Bag, F. Hao, and K. Salah (2018-11) M2M-REP: reputation system for machines in the Internet of Things. Computers & Security 79, pp. 1–16. Cited by: §2.2.
  • [3] J. Benet (2014) Ipfs-content addressed, versioned, p2p file system. arXiv preprint arXiv:1407.3561. Cited by: §3.
  • [4] Blockchain N3 incentivized node network. Note: https://www.blockchains.com/our-products/incubed/,2020 Cited by: §3.1.
  • [5] R. Chen, J. Guo, and F. Bao (2014) Trust management for SOA-based IoT and its application to service composition. IEEE Transactions on Services Computing 9 (3), pp. 482–495. Cited by: §2.2.
  • [6] Cisco (2019) VNI forecast highlights tool. Note: https://www.cisco.com/c/m/en_us/solutions/service-provider/vni-forecast-highlights.html Cited by: §1.
  • [7] G. Coulouris, J. Dollimore, and T. Kindberg (2012) Distributed systems: concepts and design, 5th ed.. Pearson, Boston, MA. Cited by: §1.
  • [8] G. De Roode, I. Ullah, and P. J. M. Havinga (2018) How to break IOTA heart by replaying?. In IEEE Globecom Workshops, Cited by: §4.9.
  • [9] R. Dennis and G. Owen (2015) Rep on the block: A next generation reputation system based on the blockchain. In Proceedings of the International Conference for Internet Technology and Secured Transactions, pp. 131–138. Cited by: §2.2.
  • [10] R. Di Pietro, X. Salleras, M. Signorini, and E. Waisbard (2018) A blockchain-based trust system for the Internet of Things. In Proceedings of the ACM Symposium on Access Control Models and Technologies, pp. 77–83. Cited by: §1, §2.2.
  • [11] M. A. Ferrag, M. Derdour, M. Mukherjee, A. Derhab, L. Maglaras, and H. Janicke (2018) Blockchain technologies for the internet of things: research issues and challenges. IEEE Internet of Things Journal 6 (2), pp. 2188–2204. Cited by: §1.
  • [12] M. Fischer (1983) The consensus problem in unreliable distributed systems (a brief survey). In Proceedings of the International Conference on Fundamentals of Computation Theory, Lecture Notes in Computer Science, 158, pp. 127–140. Cited by: §1.
  • [13] J. Guo, R. Chen, and J. J. Tsai (2017) A survey of trust computation models for service management in Internet of Things systems. Computer Communications 97, pp. 1–14. Cited by: §4.
  • [14] M. Gupta, P. Judge, and M. Ammar (2003) A reputation system for peer-to-peer networks. In Proceedings of the International Workshop on Network and Operating Systems Support for Digital Audio and Video, pp. 144–152. Cited by: §2.2, §2.2.
  • [15] O. Hasan (2017-Nov.) A survey of privacy preserving reputation systems. Technical Report LIRIS UMR 5205 CNRS/INSA de Lyon/Université Claude Bernard Lyon 1/Université Lumière Lyon 2/École Centrale de Lyon. External Links: Link Cited by: §2.2, §2.2, §4.
  • [16] K. Hoffman, D. Zage, and C. Nita-Rotaru (2009-12) A survey of attack and defense techniques for reputation systems. ACM Computing Surveys 42 (1). Cited by: §1, §2.2, §4.
  • [17] ITU (2018) Measuring the information society. Technical report Vol. 1. Note: https://www.itu.int/en/ITU-D/Statistics/Documents/publications/misr2018/MISR-2018-Vol-1-E.pdf Cited by: §1.
  • [18] S. Kamvar, M. Schlosser, and H. Garcia-Molina (2003-05) The eigentrust algorithm for reputation management in P2P networks. In Proceedings of the International Conference on World Wide Web, pp. 640–651. Cited by: §2.2.
  • [19] L. Lamport, R. Shostak, and M. Pease (1982) The Byzantine Generals problem. ACM Transactions on Programming Languages and Systems 4 (3), pp. 382–401. Cited by: §1.
  • [20] T. Le and M. W. Mutka (2019) A lightweight block validation method for resource-constrained iot devices in blockchain-based applications. In IEEE International Symposium on A World of Wireless, Mobile and Multimedia Networks, Cited by: §3.1.
  • [21] C. Li, P. Li, D. Zhou, Z. Yang, M. Wu, G. Yang, W. Xu, F. Long, and A. C. Yao (2020) A decentralized blockchain with high throughput and fast confirmation. In USENIX Annual Technical Conference, pp. 515–528. Cited by: §2.1, §4.2.
  • [22] Listia (2018) Ink protocol: Decentralized reputation and payments for peer-to-peer marketplaces. https://paywithink.com/wp-content/uploads/2018/07/Ink_Protocol_Whitepaper_V9_Listia_Inc.pdf. Cited by: §2.2.
  • [23] J. Manyika, M. Chui, P. Bisson, J. Woetzel, R. Dobbs, J. Bughin, and D. Aharon (2015-Jun.) Unlocking the potential of the Internet of Things. McKinsey Global Institute. Cited by: §1, §1.
  • [24] F. G. Mármol and G. M. Pérez (2009) Security threats scenarios in trust and reputation models for distributed systems. Computers & Security 28 (7), pp. 545–556. Cited by: §4.
  • [25] J. Mocnej, W. K. Seah, A. Pekar, and I. Zolotova (2018) Decentralised IoT architecture for efficient resources utilisation. IFAC-PapersOnLine 51 (6), pp. 168–173. Cited by: §1.
  • [26] S. Nakamoto (2008) Bitcoin: a peer-to-peer electronic cash system. Cited by: §1, §2.1, §3.1, Fig. 8.
  • [27] A. Nordrum (2016-Oct.) The internet of fewer things [News]. IEEE Spectrum 53 (10), pp. 12–13. Cited by: §1.
  • [28] K. Noyen, D. Volland, D. Wörner, and E. Fleisch (2014) When money learns to fly: Towards sensing as a service applications using bitcoin. arXiv preprint arXiv:1409.5841. Cited by: §1.
  • [29] P. Otte, M. de Vos, and J. Pouwelse (2020-Jun.) TrustChain: a Sybil-resistant scalable blockchain. Future Generation Computer Systems 107, pp. 770–780. Cited by: §2.2, Fig. 7, Fig. 8, §4.1, §4.11.
  • [30] S. Popov (2018) The tangle. Cited by: §2.1, §3.1.
  • [31] C. Qiu, H. Yao, F. R. Yu, C. Jiang, and S. Guo (2019) A service-oriented permissioned blockchain for the internet of things. IEEE Transactions on Services Computing 13 (2), pp. 203–215. Cited by: §2.1.
  • [32] H. Rahimi and H. Bekkali (2017) State of the art of trust and reputation systems in e-commerce context. arXiv preprint arXiv:1710.10061. Cited by: §1.
  • [33] H. Rainie, J. Anderson, and J. Albright (2017-03) The future of free speech, trolls, anonymity and fake news online. Pew Research Center, Washington, DC. Cited by: §1.
  • [34] P. Resnick and R. Zeckhauser (2002-Oct.) Trust among strangers in Internet transactions: Empirical analysis of eBay’s reputation system. In The Economics of the Internet and E-commerce, Advances in Applied Microeconomics, Vol. 11, pp. 127–157. Cited by: §1.
  • [35] A. Reyna, C. Martín, J. Chen, E. Soler, and M. Díaz (2018-Nov.) On blockchain and its integration with IoT. Challenges and opportunities. Future Generation Computer Systems 88, pp. 173–190. Cited by: §1.
  • [36] M. Sallaba, D. Siegel, and S. Becker (2019) IoT powered by blockchain–How blockchains facilitate the application of digital twins in IoT. https://www2.deloitte.com/content/dam/Deloitte/de/Documents/Innovation/IoT-powered-by-Blockchain-Deloitte.pdf 19. Cited by: §1.
  • [37] A. Schaub, R. Bazin, O. Hasan, and L. Brunie (2016) A trustless privacy-preserving reputation system. In Proceedings of the IFIP International Conference on ICT Systems Security and Privacy Protection, pp. 398–411. Cited by: §2.2.
  • [38] D. Trc̆ek (2018) Trust and reputation management systems. Springer, Berlin. Cited by: §3.2.
  • [39] G. Wood et al. (2014) Ethereum: a secure decentralised generalised transaction ledger. Ethereum project yellow paper 151 (2014), pp. 1–32. Cited by: Fig. 8.
  • [40] M. Wu, K. Wang, X. Cai, S. Guo, M. Guo, and C. Rong (2019) A comprehensive survey of blockchain: from theory to iot applications and beyond. IEEE Internet of Things Journal 6 (5), pp. 8114–8154. Cited by: §1.
  • [41] K. Wüst and A. Gervais (2018) Do you need a blockchain?. In Crypto Valley Conference on Blockchain Technology, pp. 45–54. Cited by: §2.1.
  • [42] Z. Yan, P. Zhang, and A. Vasilakos (2014-Jun.) A survey on trust management for Internet of Things. Journal of Network and Computer Applications 42, pp. 120–134. Cited by: §1.
  • [43] Z. Yang, K. Zheng, K. Yang, and V. C. M. Leung (2017) A blockchain-based reputation system for data credibility assessment in vehicular networks. In IEEE International Symposium on Personal, Indoor, and Mobile Radio Communications, pp. 1–5. Cited by: §2.2.
  • [44] M. Zamani, M. Movahedi, and M. Raykova (2018) RapidChain: a fast blockchain protocol via full sharding.. IACR Cryptol. ePrint Arch. 2018, pp. 460. Cited by: §4.2.
  • [45] Y. Zhang and J. Wen (2017-Jul.) The IoT electric business model: Using blockchain technology for the Internet of Things. Peer-to-Peer Networking and Applications 10 (4), pp. 983–994. Cited by: §1.