The Attack of the Clones against Proof-of-Authority

02/26/2019 ∙ by Parinya Ekparinya, et al. ∙ 0

In this paper, we explore vulnerabilities and countermeasures of the recently proposed blockchain consensus based on proof-of-authority. The proof-of-work blockchains, like Bitcoin and Ethereum, have been shown both theoretically and empirically vulnerable to double spending attacks. This is why Byzantine fault tolerant consensus algorithms have gained popularity in the blockchain context for their ability to tolerate a limited number t of attackers among n participants. We formalize the recently proposed proof-of-authority consensus algorithms that are Byzantine fault tolerant by describing the Aura and Clique protocols present in the two mainstream implementations of Ethereum. We then introduce the Cloning Attack and show how to apply it to double spend in each of these protocols with a single malicious node. Our results show that the Cloning Attack against Aura is always successful while the same attack against Clique is about twice as fast and succeeds in most cases.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 7

page 11

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

Ethereum is one of the most popular open blockchain systems thanks to the large ecosystem of distributed applications that it executes. Unfortunately, the default Ethereum protocol, called proof-of-work (PoW), forks because it allows distinct blocks to be appended at the same index of the chain. This fork situation can lead to security vulnerabilities, like double spending, if it is not detected early enough. Alternative protocols, called proof–of-authority (PoA) protocols, that avoid forks have recently been integrated in the mostly deployed Ethereum clients, parity and geth and are used by industries. Yet, to our knowledge, the level of security offered by PoA protocols has not been assessed yet.

These Ethereum consensus algorithms, called Aura and Clique, are said to implement proof-of-authority (PoA) because they restrict the creation of a block to a fixed set of n authority nodes, called sealers, among which a maximum of can be Byzantine. They aim at solving the well-known Byzantine consensus problem [11], where a fixed set of nodes agree on a unique block despite the presence of Byzantine nodes. PoA gives the sealers the authority to seal a block, which consists of signing cryptographically the block. This set of sealers can possibly change over time if a subset of the participants allow it, similarly to what is known as a community blockchains [18]. This PoA is an appealing alternative to PoW for industries that are not interested in spending a large amount of CPU resources in exchange of a reward expressed in a cryptocurrency, but are more interested in avoiding forks to increase security.

For these reasons, PoA recently got traction in the industry. Amazon Web Services offers PoA through the Clique protocol built in geth to its customers.111https://aws.amazon.com/blogs/apn/launch-enterprise-ready-blockchain-networks-on-aws-in-
minutes-with-kaleido-a-consensys-solution/
.
Industrials, like Lavaa, propose a tracking service to prevent fraud counterfeiting, that was experimented on Ethereum/Aura [19]. They implemented a service that aims at maintaining data privacy and integrity in a multi-tenant scenario. Microsoft describes how to deploy Ethereum/Aura “in production”.222https://docs.microsoft.com/en-us/azure/blockchain/templates/ethereum-poa-deployment. They suggest Azure customers to deploy the Aura protocol across different regions to improve the availability of the service. De Angelis et al. [2] discuss that in theory the consistency of Aura can be limited, for example if the clocks are sufficiently far apart and that Clique offers eventual consistency. To the best of our knowledge, these algorithms have not been formalized and it is unclear whether an attacker could violate data integrity.

In this paper, we show that, under specific conditions, PoA is not secure. To this end, we design, implement and experiment an attack, called the Cloning Attack, against both Ethereum/Aura and the Ethereum/Clique protocols that allow to steal digital assets and propose ways to alleviate the vulnerability.

The Cloning Attack consists of a sealer attacker cloning a public-private key pair to convince half of the honest sealers that a transaction is correctly committed before erasing this transaction to double spend its coins. Thanks to the cloning, to convince half of the honest sealers that transactions are committed, the attacker simply needs to delay messages between two halves of honest sealers. The application of this attack to Aura consists of the attacker simply sealing more blocks in one branch for its transaction to disappear, allowing him to double spend. The application of the attack to Clique is faster but more subtle and consists of disordering the victim sealers so as to minimize the weight of the branch on which they mine blocks.

We deployed both versions of PoA Ethereum on our private testnet and performed the Cloning Attack on both protocols. Overall, we found that Aura required lesser topological knowledge for a malicious sealer to achieve double spending with 100% success rate when compared to Clique. In the other hand, the attack against Clique is about twice faster but its success rate ranges from 60% to 100% depending on the topology knowledge of malicious sealers. As, a result it appears that, despite its recently introduced Byzantine fault tolerance, Ethereum remains highly vulnerable to networking attacks when used in a consortium.

In order to remedy this vulnerability, we propose to modify these two consensus algorithms and preserve their safety guarantees. However, as a drawback, our counter-measures introduce some potential limitation to the liveness of the Clique algorithm.

Section 2 presents the related work. Section 3 describes the model we consider in this paper. Section 4 formalizes both Aura and Clique protocols as implemented in respectively and in at the time of writing. Section 5 describes the Cloning Attack against both consensus algorithms. Section 5 present the Cloning Attack, while Sections 6 and 7 explain how to exploit it to double spend in Aura and Clique, respectively. We then present in Section 8 our evaluation of the Cloning Attack on both protocols, while Section 9 discusses our results and potential counter-measures. Finally, Section 10 concludes the paper.

2 Background

Most of the known double spending attacks against blockchains exploit their inherent permissionless mechanism by including in the blockchain a transaction that transfers coins and then discarding this transaction, hence allowing to re-spend the previously spent coins in a subsequent transaction. Below we list some of these attacks to explain the recent raise of alternative protocols based on proof-of-authority.

Perhaps the most conventional way to double spend in permissionless blockchains is for an attacker to exploit more than half of the mining power of the system to create a heavier or longer branch that can overwrite transactions that were expected to be sufficiently confirmed or committed [16]. In some blockchains, a quarter of the mining power appears enough in theory to attract participants into a coalition whose cumulative mining power reaches strictly more than half of the total mining power [7]. SmartPool [12] copes with the centralisation of mining power into these blockchains and the risk of mining pools to join a coalition of strictly more than half of the total mining power.

To attack permissionless blockchains without a significant mining power, researchers attacked the network. The Eclipse attack against Bitcoin [9] consists of isolating at the IP layer a miner victim from the rest of the network to exploit its resources. The Blockchain Anomaly [14] exploits message reordering in Ethereum to abort transactions that seemed sufficiently confirmed. The Balance Attack [15] partitions the network into groups of similar mining power to influence the selection of the canonical chain. Recently, actual man-in-the-middle attacks were run to demonstrate the feasibility of stealing assets in Ethereum without a significant mining power [6].

A natural way of coping with these attacks is to restrict the right to create blocks to permissioned participants. Given the large literature on Byzantine fault tolerance [11], we know that leveraging authentication, upper-bounding the number of failures to participants and delivering messages in bounded time allow participants to reach a consensus on a unique block at a given index of the chain, hence avoiding double spending. Recent blockchains have offered to reach Byzantine consensus using proof-of-stake sometimes probabilistically [13, 8], sometimes deterministically [1, 17]. Although they may not always be available, in case of network partitioning for example, these algorithms are typically safe.

Proof-of-Authority (PoA) was recently proposed as a Byzantine fault tolerant consensus mechanism that integrates with the Ethereum protocol [10]. It is available in the two major Ethereum implementations, called geth and parity, under the name of the Clique and Aura protocols, respectively. The concept is similar to traditional Byzantine fault tolerant consensus in that only sealers are permissioned to create new blocks but requires authentication and strictly less than Byzantine participants. Although it does not necessarily improve the protocol performance for the sake of compatibility with the Ethereum participants using proof-of-work, its lack of double spending raised interest from the industry [19]. Some recent study [2] of PoA revealed that unsynchronized clocks could affect Aura’s consistency whereas Clique was only eventually consistent, however, to our knowledge no attacks have been proposed against Aura or Clique until now.

3 Model

We consider a distributed system of permissioned sealers whose identifiers are . As the blockchain is open, it accepts the requests issued by nodes that are not necessarily sealers, hence the overall number of participants can be larger than , but only participants can propose blocks and seal (or sign) them. We assume authentication through a public-key cryptosystem that allows participants to easily identify that a block is correctly signed by a sealer so that incorrectly signed blocks are simply ignored. We assume that keys cannot be forged or stolen by Byzantine participants and that appropriate private keys are correctly distributed to the sealers initially. As in the Dolev-Yao model [4], we assume the attacker, who has the control over the Byzantine participants, can intercept messages.

It is claimed that the Aura algorithm is designed to “tolerate up to 50% of malicious nodes” [10], however, in general a participant cannot decide if half of the nodes pretend that a block is decided while the other half of the nodes pretend that the same block is not decided. This is the reason why we assume in this paper that no more than participants can be Byzantine and can act in an arbitrary way, hence a majority of participants always remain correct.

As it is well known that consensus cannot be reached in an environment where communication is asynchronous in the presence of faults, it appears natural to assume additional synchrony. It is unclear whether PoA protocols work under partial synchrony, where message gets delivered in a bounded amount of time that is not known from the algorithm [5] or how long communication can take for these protocols to work. As an example, a preliminary version of Aura was mentioned to require synchrony in a web document333https://wiki.parity.io/Aura., however, this information appears outdated as the implementation is closer to another documentation [10] that does not mention this, as we explain in Section 4.1.

The questions we investigate is whether PoA protocols work under partial synchrony, and if not, whether the risk of unexpected message delays is benign (termination of the consensus is not guaranteed) or can have dramatic consequences (disagreement can occur), letting an attacker double spend. Interestingly, we actually demonstrate that the worse can happen in case of unexpected message delays.

4 PoA Consensus Algorithms

In this section we describe the two main variants of PoA algorithms, called Aura and Clique, popularized by the predominant Ethereum software, called and , respectively. We first formalize two distinct versions of the Aura algorithm that are both publicly available online. We then formalize the Clique algorithm.

4.1 The Aura consensus algorithms

There exist two distinct versions of the Aura algorithm as documented online, one that corresponds to the current implementation of the Ethereum protocol and another [10] that uses rounds to decide whether a consensus decision is reached.

4.1.1 The Aura algorithm

Algorithm 1 depicts the way Ethereum/Aura guarantees that participating nodes reach consensus on the uniqueness of the block at a given index of the blockchain as implemented in (v2.0.8 was the latest version at the time we performed our experiments). Every participating node maintains a state comprising a set of , its current view of the blockchain as a directed acyclic graph and a block with fields that links to the parent block, a signature and a indicating the time at which the block is added to the blockchain, as explained below.

State
1:, the set of sealers
2:, the local blockchain at node is a directed
3:acyclic graph of blocks and pointers
4:, a block record with fields:
5:, the block preceding in the chain, initially
6:, the signature of the sealer that created block
7:, the step of the blockchain when the block gets added
8:, the duration of each step as configured
9:
10:while  do
11:       discretize time
12:      if  then my turn
13:             link a block
14:             seal the block
15:             send the block
16:      end if
17:       wait before looping
18:end while
19:      
20:      if  then
21:            
22:      end if
23:             return
24:            
25:             sealers in blocks since return more than majority of sealers signed
Algorithm 1 The Aura algorithm at process

The function is invoked in order to propose a block for a particular index of the blockchain. The consensus is reached once the block is decided which can happen much later as we will explain in the function (Line 24) below. The algorithm discretises time into steps that corresponds to consecutive periods of time, as specified in a configuration file. Each sealer executes an infinite loop that periodically checks whether the indicates that this is its turn to propose a block (Line 11). When it is its turn (Line 12), a sealer sets the parent of the block to the last block of its view and signs it with a (Line 26).

Each invoked by the function sends messages that get delivered at all other participating nodes that are correct. The function (Line 19) is thus invoked at each participating node, regardless if they are sealer, upon reception of the broadcast message. Once a blockchain view is delivered to participant , the node compares the score of the blockchain view it maintains to the blockchain view it receives. The (Line 23) allows to compare multiple blockchains. The blockchains that is highest has the greatest score, however, if two blockchains share the same height, then the one that is denser in terms of its number of non-empty slot will have an higher score. This is indicated by the two functions and that represents the height of the blockchain and the number of slots for which there exists a block in the blockchain.

4.1.2 Round-based variant of the Aura algorithm

The Aura algorithm implemented in is not the only algorithm called, Aura. Another variant is presented in the PoA Network white paper available online [10]. Algorithm 2 presents the different decision process of this variant, the rest of the pseudocode being identical to Algorithm 1.

In order to know whether a block is decided at the end of a successful consensus (Algo 2 – Line 2), a participant simply has to check whether there exist two consecutive rounds following block , in each of which the blocks are sealed by a majority of the sealers.

1:. number of validators
2: steps in next round
3: steps in the 2nd next round
4: majority in round 1
5: majority in round 1 return decided if majority in both rounds
Algorithm 2 The round-based variant of Aura at process

Note that while presented in some documentation, the alternative definition is not the one used by the mainstream implementation of the protocol. The current definition of the Aura algorithm disregards the rounds and simply requires enough blocks to be sealed. Although the version of Aura we experiment in this paper is the mainstream, the attack we present in Section 6 could also be applied to this more restrictive definition presented in Algorithm 2.

4.2 The Clique consensus algorithm

Algorithm 3 depicts the pseudocode of the Ethereum/Clique consensus algorithm. This solution is the one used currently in .

Every participating node shares the same initial block, the genesis block, which also contains the , the period between consecutive block creations. Similarly to the Aura protocol, each node maintains its own view of the growing blockchain as a directed acyclic graph . A block contains a as an index of the block in the blockchain, a as a weight of the block, a field that links to its parent block and a , which is a signature.

State
1:, the set of sealers
2:, the local blockchain at node is a directed
3:acyclic graph of blocks and pointers
4:, a block record with fields:
5:, the block preceding in the chain, initially
6:, the signature of the signer that created block
7:, the index of the block in the chain
8:, the weight of a block
9:, minimum duration in second between timestamps of
10:two consecutive blocks, initially seconds
11:, the number of
12:, number of consecutive blocks out of which a signer can
13:sign at most one block, set to the
14:
15:while  do
16:       last block index not sign recently
17:       last block timestamp wait block-period
18:      if  then in-turn
19:             block weight 2
20:      else out-of-turn
21:             random delay in millisec.
22:             block weight 1
23:      end if
24:       increment block index
25:       link a block
26:       seal the block
27:       send the block
28:end while
29:      
30:      if  then heavier
31:            
32:      end if
33:            
34:            
35:            
36:            for  do loop through last blocks
37:                 if  then
38:                       
39:                 end if
40:            end forreturn
41:                 
42:                  sealers in blocks since return more than majority of sealers signed
43:                  total weight return
Algorithm 3 The Clique PoA blockchain consensus algorithm at process

The function runs an infinite loop in order to propose blocks to the blockchain when certain conditions are satisfied. The first condition (Line 16) requires the process to wait for blocks from other sealers until none of the last blocks contain its signature in order to proceed. In the current implementation the must be , which is the smallest . As a result of this first condition, sealers need to take turn to sign blocks. The second condition (Line 17) is to wait for .444The default is 15 seconds as developers suggest the same duration to remain analogous to the proof-of-work blockchain Ethereum. When both conditions are met, the process checks if it is its turn to sign the block (Line 18). The process may sign a block right away with equal to 2; otherwise, it may sign a block with equal to 1 after a random delay between 0 and milliseconds (Line 21). The consensus is reached once the block is decided later as we will describe in the function (Line 41). The last step in the loop, , sends messages to other processes.

Upon reception of the broadcast message, the function (Line 29) is invoked at each participating node regardless of whether it is a signer. The function (Line 43) used by the process compares the weight between two blockchain views, a current blockchain that it maintains locally and the other one from the received message. The process updates its local view if the blockchain received from the message is heavier; it keeps the same local blockchain view otherwise.

To consider whether a block is decided (Line 41), a process has to check a set of sealers who sign subsequent blocks. Only when the majority of sealers have appended their blocks to the chain, a block will be considered a decided block.

5 The Cloning Attack

In this section, we present the cloning attack to double spend in PoA blockchains. In particular, we present the commonalities between the attacks against Aura and Clique, namely the cloning process that allows an attacker to play different roles in the blockchain, the majority that allows two groups of sealers to make progress without the other, and the way transactions should conflict to double spend. The difference in how these attacks are applied to Aura and Clique are deferred to Sections 6 and 7, respectively.

By assumption, only a minority of the sealers can be malicious, this is the reason why PoA algorithms require a majority of sealed blocks to consider whether a block and its transactions appear to be committed. Intuitively, this should prevent the malicious sealers to form a coalition that can double spend. In reality, as we explain below, attacker(s) cloning their own instance into two clones are sufficient to double spend.

5.1 Cloning instances by duplicating keys

The first step necessary in both attacks is for some attacker to duplicate its Ethereum instance into two clones. Cloning consists for a single user, the attacker, of running two instances of the Ethereum protocol with the same address or public-private key pair. Note that these two instances could run either on the same machine, using the same IP address, or on distinct machines with distinct IP addresses. We call these two instances clones because one has the same information as the other before messages get intercepted. In addition, during the whole duration of the attack, both clones use the same public-private key pair. Interestingly, we noted that Ethereum allow these two distinct instances to mine blocks, however, as they use the same private key to seal blocks, they are considered to act as a unique sealer.

At some point, the attacker starts intercepting messages between two groups of a minority of sealers, hence creating a partition

. At this moment, the two clones may not share exactly the same database content, as they may not be aware of the exact same blocks that are present in the blockchain. To maintain the cloning at the start of the partition, the attacker copies the content of the blockchain database of one of the sealer to the database of the other sealer and connects each sealer to a different partition. During the message interception, the Ethereum protocol readjusts the peering so that sealers within the same group keep communicating.

Note that they are various ways of obtaining a partition in the Ethereum network either by misconfiguring routes, leveraging natural disasters or maliciously attacking the network. One example of a network attack that allows to partition the Internet is the BGP hijacking attack. It works by having an attacker advertising to one group wrong routes that reach the other group in order to intercept all traffic between the two groups. Once the traffic is rerouted, the attacker can simply delay the propagation of messages. We refer the interested reader to previous work [6] that focuses on man-in-the-middle attacks against Ethereum permissioned networks.

5.2 Majority groups to guarantee progress

Clones are exploited in the attack to give the illusion to correct sealers that each group contains a majority of sealers. In order to progress towards a double spending situation, each group must commit transactions and thus decide blocks, this is why we need attackers that clone instances.

  • Case is odd. The correct sealers can be split into two groups of sealers that each represent a minority. In order to guarantee progress of the protocol on both sides of the partition, a single attacker can simply add one clone in each minority, hence reaching a majority of sealers on each side. This is the reason why attacker is sufficient when

    is odd.

  • Case is even. The attacker will end up splitting the correct sealers into two groups of different sizes, one that contains sealers and another that contains sealers. While it is sufficient to include a clone in the former group to guarantee their progress, one must add at least two clones to the latter group to guarantee their progress. This is the reason why attackers are necessary when is even.

To conclude, the attacker(s) thus partition a network of sealers into two halves to which they add clones so that each group contains a majority of at least sealers. This guarantees the progress of the protocol on each group so as to obtain the commit of a transaction on one group and the canonical chain containing in the other group. For example, there must be at least 5 sealers in each subgroup for a network of sealers. Such a condition is required to ensure termination of the consensus algorithm, so that blocks will be decided, or appear to be final, from the viewpoint of both subgroups.

Note that we consider here the necessary time for a partition. In a realistic scenario, the attacker may want the effect of its transaction to take effect before stopping the partition. For example, an attacker buying a good in transaction may want to receive the good before the transaction gets discarded from the blockchain.

5.3 Conflicting transactions

The most common way of executing a double spending is to make sure a transaction ends up being included in one branch of a fork, then convincing the recipient that is committed, before resolving the fork by discarding the branch of this transaction . Later on, the sender of the transaction can simply reuse the coins he initially spent in in another transaction . Interestingly in Ethereum, if the conflicting transaction is not issued early enough, then could be re-included in a mempool and re-committed later on.

The goal is for the clones to leverage the partition to issue two conflicting transactions. As soon as the blockchain network is divided into two subgroups, the attacker issues a minimum of two conflicting transactions, at least one transaction to each subgroup. A typical example to illustrate the double spending attack is two conflicting transactions:

  1. [leftmargin=.4in]

  2. where Alice gives all her coins to Bob in the first transaction sent to one group and

  3. where Alice gives all her coins to Carol on the other transaction sent to the other group.

It is clear that committing both transactions would violate the integrity of Alice’s account and allowing this would result in a double spending. Once the first transaction appears committed, ending the partition will have the effect of discarding one of the two transactions.

We explain below how the majority of sealers in Aura and the order of the seals in Clique allows to select the transaction to be discarded by the system.

6 Applying the Cloning Attack to Aura

We now present a simple way to apply the Cloning attack to double spend in Aura. To discard the branch, say the victim branch, that contains and double spend, the attacker must influence Aura to select the branch containing , say the attacker branch as the canonical chain.

As explained earlier in Algorithm 1, the current implementation of Aura simply chooses the longest chain as the canonical chain whenever a fork is detected. So, to influence the selection of the attacker branch as the canonical chain, the attacker simply has to contribute to the attacker branch by sealing more blocks in the group maintaining this branch than the other group.

Figure 1: Applying the cloning attack to double spend in Aura requires the attacker, “Sealer 1”, to partition the network during seconds for transaction to be committed on the upper branch and for the attacker to seal more blocks on the lower branch than the upper branch.

To seal more blocks in one branch than another, the attacker maintain the partition during seconds, where is the number of sealers and is the step duration in seconds that separates consecutive blocks. The reason is twofold.

  • First, as mentioned earlier in Algorithm 1, Aura requires delay after a block is created to ensure that it is decided. Deciding a block on the victim side is necessary to make sure that gets committed. Given that both the size of the group on each size is and that each sealer seal one after another, the attacker clone must also seal at least one block.

  • Second, the attacker must ensure that the attacker branch is longer than the victim branch so that the attacker branch gets selected by Aura as the canonical branch. This can only be done if the attacker seal two blocks on the attacker branch, i.e., one extra block compared to the number of block it sealed on the victim side. As a result, the attacker needs to maintain the network partition for at least seconds to get at least two turns in which it can seal a block.

Example with 9 sealers.

For the sake of simplicity, Figure 1 depicts the cloning attack with a network partition where there are sealers and where sealer is malicious, namely “Sealer 1”. This attacker is thus present in both groups through its two cloned instances and gives the illusion that each group contains a majority of sealers while one of the sealers in each group is actually a clone. As we can see, this attack translates into having Sealer 1 creating the last block (depicted in red in the figure) only on the lower partition before merging the two partitions. Doing so, Sealer 1 is sure that this branch will be the canonical branch whereas the upper branch will simply disappear. The attackers is thus guaranteed to double spend successfully.

7 Applying the Cloning Attack to Clique

In this section, we apply the cloning attack against Clique. In Clique, the Cloning Attack does not require to take as long as in Aura. Unlike in Aura, the sealers of Clique can seal blocks even when it is not their turn. Depending on their turn, some sealers may have to wait while others do not. These differences impact the way the attacker can influence the selection of one branch of a fork as the canonical chain and allow an attacker to double spend faster than in Aura.

7.1 In-order and out-of-order sealers

The cloning attack against Clique differs from the one against Aura in the moment at which it starts intercepting messages. Because the order of sealing is important in Clique, the attacker carefully decides to start partitioning the network based on the sealer’s turn to seal a block.

In Clique, when a sealer seals a block while it is his turn, we call this sealer an in-order sealer and the block an in-order block. There is at most one in-order sealer to seal the current block in each partition of Clique. When a sealer seals a block while it is not his turn, we call this sealer an out-of-order sealer and this block an out-of-order block. As a sealer must wait for blocks between two blocks it seals, there are at most potential out-of-order sealers to seal a block. The in-order block contributes to a weight of 2 in the weight of their branch whereas the out-of-order blocks contribute to 1 to the weight of their branch, hence sealing in-order or out-of-order impacts the decision regarding the branch selection process.

In addition, an in-order sealer can append a block to the chain without waiting for any delay as shown in Line 18 of Alg. 3. By contrast, an out-of-order sealer has to wait for a random period as indicated at Line 21 of Alg. 3. This mechanism gives the in-order sealer some time to be the first to seal a block in their turn, but allows out-of-order sealers to seal a block if the in-order sealer is lagging.

As the canonical chain is chosen among the branches of a fork by comparing their difficulty as the sum of their block weights, the attacker must have a maximum number of in-order sealers at the time of the partition to maximize the overall weight. Hence, to influence the selection of the branch as the canonical chain, the attacker must choose the proper turn to start intercepting the messages. If not done properly, the attackers risks to maximizing the weight of the branch where its transaction was included, preventing the double spending attempt to be successful.

Figure 2: An execution of the in-order cloning attack against Clique where sealers mine the blue blocks in-turn before the partition occurs, after which each group seals five blocks, 3 in-order blocks on the left group and 1 in-order block on the right group.

7.2 Disordering sealers to select a branch

We illustrate the attack with sealers and one attacker. Figure 2 depicts the execution of the attack as time increases from top to bottom. At the top the blockchain starts with block 5, representing that the first block is sealed by Sealer 5. As times goes on, Sealers 6, 7, 8 and 9, seal one after the other the subsequent blocks of the blockchain. As there is no partition yet, the in-order sealers are the first to sign these blocks during their respective turn, hence all blocks are in-order blocks represented in blue in the figure. Next to each created block is a list of sealers that are either unable to seal (grey), in-order sealer (green) or out-of-order sealer (yellow).

Sealer 1 represents once again the attacker performing both the cloning and the network partition. Right after Sealer 9 sealed his block, Sealer 1 starts intercepting the messages between the group of sealers 2, 3, 4 and 5 on the left side and the group of sealers 6, 7, 8 and 9 on the right side. Note that Sealer 1 is represented on both sides because of the presence of one of its clones on each side. This partition is indicated in Figure 2 by a fork of the blockchain into two branches. Right after the partition, Sealer 1 issues two conflicting transactions and on each side of the partition that will double spend. The two clones of Sealer 1 allow him to seal one block in each group. Note that these blocks are labelled 1 and represented in blue because Sealer 1 is the in-order sealer at this point in time. After sealing, Sealer 1 is no longer able to seal any block due to the , hence Sealer 1 is depicted in grey in both groups.

On the right side of the partition, we can see that Sealer 6 seals the following block, even though it is not the in-order sealer at this moment. This is because the in-order sealer, Sealer 2, cannot communicate with this group as the network is partitioned. For some reason it might also be the case on the left side of the partition that Sealer 2 is not fast enough to seal the next block and that another sealer, say Sealer 3, manages to seal it before. Note that this can happen as the delay Sealer 3 has to wait before sealing is a random number that can be null (cf. Alg. 3, Line 21). However, this last seal from Sealer 3 prevents it from sealing the next block in-order as it has to wait for the , hence the next block is again out-of-order. The process continues where sealers on the left side seal in-order whereas sealers on the right side seal out-of-order.

Finally, the attacker does no longer need to intercept the messages and can stop the partition as both transactions and are now successfully committed. In fact, the transactions are both now in the first block of a series of consecutive blocks which is sufficient for all Clique users to consider these transactions as committed because their block is decided as indicated at Line 42 of Alorighm 3. We can conclude that the weight gained by the branch on the left side during the partition is because it contains 3 in-order blocks and 2 out-of-order blocks. By contrast, the weight gained by the branch on the right side during the partition is because it contains 1 in-order block and 4 out-of-order blocks. It follows from the difference in weight of the two branches that the heaviest branch on the left side is chosen as the canonical branch whereas the lightest branch on the right side is simply discarded by the protocol (cf. Alg. 3, Line 30).

7.3 Attack regardless of the order of sealers

Note that even if the attacker does not know the topology, there is a way to attack Clique. The attack is slightly different from the previous one as it relies on the possibility for the attacker to become the only sealer able to seal a block on both sides of the partition. The attacker can simply seals a single block on the victim branch, and keep sealing blocks on the attacker branch. In the worst case scenario for the attacker, all the upcoming in-order sealers end up on the victim side, which will maximize the weight of the branch on the victim side gained during the partition. Note that the is always in Clique (Alg. 3, Line 13). Now, if the attacker stops sealing a second block on the victim side, then the maximum weight gained on this side during the partition will be . The attacker simply needs to keep sealing on the other branch until the gained weight on this branch reaches . In this case, the attacker successfully double spends regardless of the sealer turn in each group.

8 Experiments

In this section, we present the double spending results using the Cloning Attack in both Aura and Clique. We first present our experimental setup then detail the risk for an attacker to perform double spending in both Aura and Clique.

8.1 Testnet setup

To practically observe the chance of successful double spending using the approaches described in the previous sections we have created our own PoA blockchain networks, experimented the attacks and measured their success rate.

Our testnet consists of 10 Ubuntu 16.04 Virtual Machines (VMs) on our OpenStack private cloud; each VM is provided with 1 virtual CPU core and 2 GB of memory. These VMs are placed into two subnets, 5 VMs each; they are connected through 5 linux virtual routers and a physical Ethernet switch with dedicated VLAN. Running on each VM is an instance of either Parity-Ethereum 2.0.8 stable version with Aura or go-ethereum 1.8.21 stable version with Clique configured as a consensus algorithm.

All of these instances are peering with each others to form the blockchain network. While we have 10 Ethereum instances in total, our PoA blockchain employed only 9 unique private keys for sealers; the last instance instead uses the same key as the first one as explained in Section 5 where one instance is seen as a clone of the other one.

In our experiments, the attacker is a Byzantine (or malicious) sealer with the intention to achieve double spending. The attacker is provided the capability to partition the network to two sealer groups: attacker and victim group. Based on our attacker intention, the attacker group is simply a group of sealers whose sealed blocks during the network partition are intended to adopted as a part of canonical chain, while the victim group is a group of sealers whose sealed blocks are intended to be discarded after the fork is resolved.

To grant network partition capability, we allow our attacker to cut the network connectivity between two subnets using a firewall feature on the linux routers. The attacker is also provided the controllability over 2 Ethereum instances (2 VMs) that share the same private key used to seal the blocks.

The attacker aims to partition the network right before their turn to seal the block, where each sealer group must contain one VM that is under the control of the attacker. To begin the attack, our attacker actively checks current turn every 10 ms in order to partition the network close to the right timing. Suddenly right after the network partition, the attacker issues one transaction to each sealer group; these two transactions are conflicting, such as a user Alice is giving all of her coins to Bob in one transaction but giving all the same coins to Carol in another.

After issuing the transactions, the network partition is maintained during a period that depend on which PoA algorithm is in use. When the fork is resolved at the end of network partition, we look at the resulting branch of the fork which has been adopted as a canonical chain as well as the status of transactions.

A double spending is considered successful only if:

  1. A transaction issued to the victim group is committed before the end of the network partition.

  2. The blocks sealed by the attacker group during the fork have been adopted as a part of the canonical chain after the end of the partition.

  3. The resulting canonical chain does not contain a transaction issued to the victim group.

8.2 Running the Cloning Attack against Aura

We experiment the Cloning Attack in Aura by varying the step duration and network partition duration. Step durations 3, 5, and 7 seconds are chosen in order to observe the practical impact of required network partition duration with different step durations.

We maintain the network partition to match the step duration in use, such that for example a 24, 27, and 30 second partition duration corresponds respectively to the 8th, 9th and 10th step for a 3 second step duration, respectively. We divide the sealers into two groups, such that apart from the two attacker instances, the placement of the reminder sealers is equally placed at random between the two partitions. We do ensure, however, that both groups have equal number of instances, which is 5, and each group must contain one of two instances under the control of the attacker. The values for each combination of step duration and network partition duration are the averaged over 30 runs.

Figure 3: The success rate of double spending with the Cloning Attack in Aura

Figure 3 presents the double spending success rate of 3, 5 and 7 second step durations. In all three cases, the obtained results show similar trend. As expected, achieving a successful double spending is impossible in all step durations at the 8th step or any previous step before, namely 24, 40 and 56 seconds for 3, 5, and 7 second step durations, respectively.

Indeed, for these failed attempts, the explanation is straight forward as any attack attempt among these runs could neither commit the transaction in the victim group nor force the block sealed by the attacker group to be adopted as a canonical chain when the network partition ends. However, we can observe that as expected, the chances of successful double spending at the step 9th fall within the range between 50-60%.

Although both groups are provided enough time to seal 5 blocks in order to commit the transactions at this point, the attacker still cannot force a particular branch of the fork to be adopted. The variation at this point is due to the randomness of Ethereum instance placement during our experiment.

For all three step durations, at the step 10th and any step hereafter, the attacker reaches 100% chance of successful attack. This is due to the attack technique in use that allows the attacker to force which branch of the fork to be adopted. Overall, we can see that the long step duration requires a long period of network partition in order to achieve a successful double spending.

8.3 Running the Cloning Attack against Clique

Hereafter, we experiment the Cloning Attack on Clique by varying the group selection when we divide sealers between two partitions and by varying the partition duration.

The variations of sealers grouping are included in the experiments in order to capture the change of the difficulty or simply the weight each branch may gain during network partitioning as a result of the possible difference of the sealing sequences.

In fact, we experiment with these 4 sealer grouping variations with different number of consecutive sealers in the attacker group that may seal blocks in-order at the beginning of the partition:

  • 5 consecutive sealers: 1, 2, 3, 4, 5 in the attacker group and 1, 6, 7, 8, 9 in the victim group;

  • 4 consecutive sealers: 1, 2, 3, 4, 6 in the attacker group and 1, 5, 7, 8, 9 in the victim group;

  • 3 consecutive sealers: 1, 2, 3, 6, 7 in the attacker group and 1, 4, 5, 8, 9 in the victim group;

  • 2 consecutive sealers: 1, 2, 4, 6, 8 in the attacker group and 1, 3, 5, 7, 9 in the victim group.

The partition duration is based on the block duration in use, which is fixed to 5 seconds in all our Clique experiments. Since our testnet setup consists of 9 sealers in total, to commit a transaction during a partitioning, at least 5 blocks must be sealed in such a period. In the best case where 5 sealers could seal 5 blocks in the correct order based on the their turns, the minimum duration required is equal to or seconds. In other cases where at least 1 out of 5 blocks is sealed out-of-order, however, the required duration is more than 25 seconds.

Based on our knowledge of the time necessary for the algorithm to seal 5 blocks, we vary the duration from 24.8 to 28.0 seconds in an incremental step of 200 milliseconds. The range of duration allows to capture the behavior of the system from the point where only 4 blocks can be sealed to the point where extra time is needed to seal 5 blocks because of the additional random delay for out-of-order sealers as shown in Algorithm 3.

For each run we keep a record of whether the double spending was successful, which block was sealed by which sealer, the weight gain during the partition for each fork, and the number of block created during the network partition. The values averaged over 50 runs are depicted in the charts for each partition duration.

Figure 4: The success rate of double spending by network partition duration and number of consecutive possible in-order sealers at the beginning of network partition
Figure 5: The average number of blocks created during network partition by duration of two sealer groups
Figure 6: The average weight gained during network partition by duration of two sealer groups

Figure 4 reveals the double spending success rate for the four sealer grouping variations previously introduced while Figure 5 and Figure 6 show the number of sealed block and the weight gain during network partition respectively. From the success rate in Figure 4, we can clearly see a similar trend for all of 4 grouping variations; the longer the partition duration, the higher the chance of successful double spending.

The shortest partition duration value in the chart, 24.8 second, gives the lowest success rate regardless of grouping variation. This low success rate for short duration could be explained by the number of blocks sealed during network partition. Indeed, due to the limited partition time, the victim group is rarely be able to seal five blocks during the network partition as shown in Figure 5, thus a transaction issued to the victim group could not be committed and the attack fails as a result. When the partition duration is increased, we can see that the victim group is able to seal five blocks.

When comparing the four different grouping selection, there is no noticeable difference between them when the partition duration is less or equal to 26 seconds. In the case of two consecutive possible in-order sealers, however, the success rate is lower than the other three grouping variations when the partition duration is greater than 26 seconds. This phenomenon could be explained by the weight gain during the network partition as shown in Figure 6. In case of 2 consecutive possible in-order sealers, the difference in weight gain between attacker and victim branches becomes relatively low; this gap narrows with the increase in partition duration.

9 Discussion and Countermeasures

In this section, we compare the vulnerabilities of Aura and Clique to the Cloning Attack resulting from our experiments in Section 8. We then present potential countermeasures against the Cloning Attacks and discuss their implication to the blockchain safety and liveness.

9.1 Comparison between Aura and Clique

In this section, we explain why the Cloning Attack against Aura can always be successful whereas the Cloning attack against Clique is much faster but not always successful.

As detailed in Section 4, one of the main differences between Aura and Clique resides in the predictability of the sequence of sealers. In fact, in Aura the sequence is strictly enforced whereas in Clique this sequence may change depending on the difference between a random number and the network communication delay. This slight algorithmic difference has however significant consequences on consensus algorithms resilience to double spending attacks using our proposed Cloning Attacks.

On the one hand and as we have demonstrated in Section 8, due to its strict enforcement of sealing order, Aura is vulnerable to the Cloning attack in case of network partition. Performing the Cloning attack against Aura, the attacker does not need to know anything about the identity of the sealers nor does it need to know their order. Thus, a malicious sealer only needs to partition the overlay network using classical network attacks such as BGP hijacking to succeed in double spending with a 100% chance of success.

On the other hand, double spending without topology information on Clique is possible, but the attack against Clique is about twice as fast as against Aura when the topology is known. Indeed, as we have presented in Section 8, the knowledge of potential next in-order sealer greatly influences the chance of double spending. When the attacker is capable of isolating the next sealers, it is able to perform the double spending attack with 100% success rate. On the opposite, the knowledge of only the next two in-order sealers only guarantees a success rate of 60% maximum.

Interestingly, when considering the attacks against both Aura and Clique without the knowledge of the topology, it appears that attacking Clique can be even slower than attacking Aura. The reason is that in the worst case scenario where all in-order sealers are on the victim side, the attacker will have to obtain a branch that is twice as large as the victim branch before it can double spend. Growing this branch would take more time than executing the Cloning attack on Aura. But overall, even without knowledge of the topology both Aura and Clique consensus algorithms are vulnerable to a malicious sealer aiming at double spending.

9.2 Countermeasures to the Cloning Attack

In this section, we introduce the countermeasures that could be employed to totally prevent the attack or mitigate its risk.

9.2.1 Partially synchronous consensus algorithms

Instead of relying on the PoA consensus that suffers from unexpected message delays, one could use a deterministic consensus algorithm that is partially synchronous in that it tolerates arbitrary delays. PBFT [CL99] is one example as it relies on a leader and was not designed to scale outside a small network. DBFT[3] is another deterministic partially synchronous consensus algorithm but was especially designed for blockchain systems. DBFT does not rely on a correct leader to make progress, and was designed to scale to large number of participants. In addition, DBFT is time optimal and resilience optimal. It has been shown that DBFT is resilient to double spending attacks, as it is not possible for a blockchain building upon it, like the Red Belly Blockchain [17], to fork.

9.2.2 Requiring two-thirds of sealers

Based on our understanding of how the two attacks against PoA work, we believe that the two PoA algorithms can sacrifice blockchain liveness during network partition in exchange for safety if they consider block finality only when strictly more than two-thirds of sealers have sealed blocks on the chain. As long as the number of malicious sealers is less than one-third of the total sealers, the modified algorithms will be able to guarantee safety, and the liveness will still be preserved whenever the network is not partitioned.

Figure 7: Modified Aura using two-thirds consensus with 7 well-behave and 2 malicious sealers
Figure 8: Modified Aura using two-thirds consensus with 7 well-behave and 2 malicious sealers during a network partition

Figure 7 and Figure 8 demonstrate how a modified version of Aura with two-thirds sealers works both with and without a partition in case of a blockchain network with 9 sealers: S1 to S9. Since the maximum number of tolerable malicious sealers must be less than one-third of the total 9 sealers, we include 2 malicious sealers in the setup: S4 and S7; these two sealers are allowed to be silent or even seal the blocks on all the partitions whenever a network partition occurs. To finalize a block that contains a transaction, the blockchain network needs strictly more than two-thirds of 9 sealers to seal the blocks on the chain; in other words, at least 7 sealers are necessary in order to decide a block and commit a transaction.

As indicated with a green dash frame in Figure 7, this version of Aura can commit even though S4 and S7 do not contribute any block to the chain in their turns. The S4 turn can be left empty and S5 may simply continue sealing a block after that; the same goes for S8 after the end of S7 turn. In this case, the other 7 honest sealers alone are sufficient to finalize a block that contains , because 7 is greater than two-thirds of .

The Figure 8 illustrates a case where the network partition occurs and the two malicious sealers S4 and S7 are capable of sealing the blocks in both groups simultaneously. Although it is possible to partition in such a way that one group has at least 7 sealers, it is impossible to have at least 7 sealers on both sides at the same time. Therefore, it is impossible to commit the transactions issued to both partitions concurrently, even though Aura allows their sealers to continue sealing more blocks during the network partition.

Figure 9: Modified Clique using two-thirds consensus with 7 well-behave and 2 malicious sealers
Figure 10: Modified Clique using two-thirds consensus with 7 well-behave and 2 malicious sealers during a network partition

The same condition also applies to Clique in a similar manner. To illustrate how a modified Clique with two-thirds consensus works, let us use the same setup with a blockchain network of sealers: S1 to S9 with two malicious sealers S4 and S7. As indicated with green dash frame in Figure 9, the blockchain network can still commit . Instead of S4 and S7, Clique allows other sealers to continue sealing the blocks in an out-of-order fashion without any gap and eventually reaches the 7 blocks requirement. In another case where the network partition occurs, if the number of sealers in a partition is not greater than two-thirds of all sealers, such a partition will be stuck even before sealing enough blocks to commit a transaction. Figure 10 shows a concrete example where both partitions get stuck due to the lack of sealers; one partitions contains only 6 sealers where there are only 5 sealers in the other.

9.2.3 Adopting a longer step duration in Aura or a longer block period in Clique

Adopting a longer required time to create one block forces the attacker to maintain the network partition for a longer period. In general, a long duration of network partition attack is more difficult to achieve than a short one for two reasons. First, there might be a regular change in the network. Second such an attack might be detected and an action can be taken as a response to remedy the lack of connectivity.

On the downside, adopting this countermeasure lowers the throughput of the blockchain. As blocks would require a longer duration to be decided, this approach increases the time needed for transactions to be committed or final.

10 Conclusion

Blockchains based on proof-of-work protocols typically allow distinct blocks to be appended to the same index of the chain and these forks lead to security vulnerabilities when growing without being noticed. As a result, Byzantine fault tolerance has been proposed as a new class of protocols called proof-of-authority in the most popular implementations of the Ethereum protocol. As the industry is building upon these protocols to use Ethereum in a consortium of institutions, it has become crucial to assess their vulnerability.

In this paper, we have presented the Cloning Attack against these protocols that leads to double spending. To this end, we proposed a formalization of the PoA algorithms deployed in Ethereum, namely the Aura and Clique algorithms.

We attacked both algorithms on a private testnet with the Cloning Attack. On the one hand, the attacker of Aura requires lesser topological knowledge to achieve double spending with 100% success rate when compared to Clique. On the other hand, equipped with the knowledge of the topology, the attacker of Clique needs half the time to double spend with from 60% to 100% success rate. Finally, we presented possible countermeasures to this attack but found that the simplest ones would break the liveness property of the Clique algorithm.

Acknowledgements

This research is in part supported under Australian Research Council Discovery Projects funding scheme (project number 180104030) entitled “Taipan: A Blockchain with Democratic Consensus and Validated Contracts”. Vincent Gramoli is a Future Fellow of the Australian Research Council.

References

  • [1] Tendermint, consensus without mining, 2015. Unpublished manuscript.
  • [2] Stefano De Angelis, Leonardo Aniello, Roberto Baldoni, Federico Lombardi, Andrea Margheri, and Vladimiro Sassone. PBFT vs proof-of-authority: Applying the CAP theorem to permissioned blockchain. In Proceedings of the Second Italian Conference on Cyber Security, 2018, 2018.
  • [3] Tyler Crain, Vincent Gramoli, Mikel Larrea, and Michel Raynal. DBFT: efficient leaderless byzantine consensus and its application to blockchains. In Proceedings of the 17th IEEE International Symposium on Network Computing and Applications, NCA 2018, Cambridge, MA, USA, November 1-3, 2018, pages 1–8, 2018.
  • [4] D. Dolev and A. C. Yao. On the security of public key protocols. IEEE Transactions on Information Theory, pages 198–208, 1983.
  • [5] C. Dwork, N. Lynch, and L. Stockmeyer. Consensus in the presence of partial synchrony. Journal of the Association for Computing Machinery, Vol. 35, No. 2, pp.288-323, 1988.
  • [6] Parinya Ekparinya, Vincent Gramoli, and Guillaume Jourjon. Impact of man-in-the-middle attacks on ethereum. In Proceedings of the 37th IEEE International Symposium on Reliable Distributed Systems (SRDS), Oct. 2018.
  • [7] Ittay Eyal and Emin Gün Sirer. Majority is not enough: Bitcoin mining is vulnerable. In Proc. of FC 2014, pages 436–454, 2014.
  • [8] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP ’17, pages 51–68, New York, NY, USA, 2017. ACM.
  • [9] Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg. Eclipse attacks on bitcoin’s peer-to-peer network. In USENIX Security, pages 129–144, 2015.
  • [10] Pavel Khahulin Igor Barinov, Viktor Baranov. POA network white paper, Sept. 2018. https://github.com/poanetwork/wiki/wiki/POA-Network-Whitepaper.
  • [11] Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantine generals problem. ACM Trans. Program. Lang. Syst., 4(3):382–401, July 1982.
  • [12] Loi Luu, Yaron Velner, Jason Teutsch, and Prateek Saxena. Smartpool: Practical decentralized pooled mining. In 26th USENIX Security Symposium, USENIX Security 2017, pages 1409–1426, 2017.
  • [13] Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. The honey badger of bft protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, pages 31–42, New York, NY, USA, 2016. ACM.
  • [14] C. Natoli and V. Gramoli. The Blockchain Anomaly. In 2016 IEEE NCA, pages 310–317, October 2016.
  • [15] Christopher Natoli and Vincent Gramoli. The balance attack or why forkable blockchains are ill-suited for consortium. In IEEE/IFIP DSN’17, Jun 2017.
  • [16] Meni Rosenfeld. Analysis of hashrate-based double-spending, 2012.
  • [17] Vincent Gramoli Tyler Crain, Christopher Natoli. Evaluating the red belly blockchain. Technical Report 1812.11747, arXiv, 2018.
  • [18] Guillaume Vizier and Vincent Gramoli. Comchain: Bridging the gap between public and consortium blockchains. In IEEE Blockchain’18, Jul 2018.
  • [19] Ingo Weber, Qinghua Lu, An Binh Tran, Amit Deshmukh, Marek Gorski, and Markus Strazds. A platform architecture for multi-tenant blockchain-based systems. In IEEE International Conference on Software Architecture (ICSA), 2019.