2019 IEEE International Conference on Blockchain (Blockchain)

A Security Reference Architecture for Blockchains

Ivan Homoliak Sarad Venugopalan Qingze Hum Pawel Szalachowski
Singapore University of Technology and Design

Abstract—Due to their specific features, blockchains have number of transactions that concern them, while they rely on
become popular in recent years. Blockchains are layered systems consensus and validating nodes for ensuring correctness of the
where security is a critical factor for their success. The main blockchain. They can detect only a limited set of attacks.
focus of this work is to systematize knowledge about security
Features of Blockchains. Blockchains were initially proposed
and privacy issues of blockchains. To this end, we propose a
security reference architecture based on models that demonstrate as open cryptocurrencies, but due to their features, they
the stacked hierarchy of various threats as well as threat-risk became appealing for other applications as well. Blockchains
assessment using ISO/IEC 15408. In contrast to the previous achieve decentralization via a distributed consensus protocol,
surveys [23], [88], [11], we focus on the categorization of security which provides resilience to failures. Usually, participants are
vulnerabilities based on their origins and using the proposed
equal and no single entity pose an authority. Another important
architecture we present existing prevention and mitigation tech-
niques. The scope of our work mainly covers aspects related to result of decentralization is censorship resistance. Blockchains
the nature of blockchains, while we mention operational security are immutable, requiring a significant quorum of colluding
issues and countermeasures only tangentially. nodes to change its entries retrospectively. Usually, immutabil-
ity is achieved thanks to a cryptographic one-way function that
I. B LOCKCHAINS AT A G LANCE creates integrity preserving links between blocks. Although
The blockchain is a data structure representing an append- blockchains are highly redundant in a storage of the data, the
only distributed ledger consisting of entries (transactions) main advantage of such redundancy is high availability. This
aggregated within ordered blocks. The order of the blocks is feature is of special interest to applications that cannot tolerate
agreed by untrusting participants running a consensus protocol. outages. Blockchain transactions, as well as actions of protocol
A transaction is an elementary data entry that may contain participants, are usually transparent to other participants and
arbitrary data, e.g., an order to transfer native cryptocurrency in most cases even to the public. This can be a benefit for
(crypto-tokens), a piece of application code (i.e., smart con- multiple applications, but it can also be seen as a disadvantage
tract), the execution orders of such application code, etc. from the anonymity and privacy perspective. Beside common
Transactions sent to a blockchain are validated by all nodes features, some blockchains may focus on additional features,
that maintain a replicated state of the blockchain. such as energy efficiency [33], [7], [47], scalability [62],
Involved Parties. Blockchains usually involve the following throughput [13], [49], [92], privacy [78], etc.
parties. (1) Consensus nodes actively participate in the under- Types of Blockchains. Based on how a new node enters a
lying consensus protocol. These nodes can read the blockchain consensus protocol, we distinguish the following blockchain
and write to it by appending new transactions (which they types. (1) Permissionless blockchains allow anyone to join
also disseminate). Besides, they can validate the blockchain the consensus protocol without permission. Such participation
and thus check whether writes of other consensus nodes are can be anonymous, and these protocols are designed to run
correct and respect a specified logic. Consensus nodes can over the Internet. To prevent Sybil attacks [27], these schemes
prevent malicious behavior (e.g., by not appending invalid usually require consensus nodes to establish their identities
transactions, or not following an incorrect blockchain view). by running a Proof-of-Resource scheme, while the consensus
In the context of Proof-of-Resource protocols (see Sec. IV-B), power of a node is proportional to its resources invested into
these nodes are often referred to as miners. (2) Validating running the protocol. (2) Permissioned blockchains require a
nodes read the entire blockchain, validate it, and disseminate consensus node to obtain permission (and identity) to join the
transactions. Unlike consensus nodes, validating nodes cannot consensus protocol. The permission is given by a centralized
write to the blockchain. Hence, they cannot prevent malicious or federated authority(ies), while nodes usually have equal
behavior. However, since they possess the entire blockchain, consensus power (i.e., one vote per node). These schemes
they can detect malicious behavior. (3) Lightweight nodes (i.e., can be public if they are accessible over the Internet or
clients) benefit from most of the blockchain functionalities, private when they are deployed over a restricted network.
but they are equipped only with limited information about (3) Semi-Permissionless blockchains require each new-coming
the blockchain. These nodes read only a fragment of the consensus node to obtain a permission (i.e., cryptocurrency
blockchain (usually block headers) and validate only a small “stake”); however, such permission can be given by any stake-
holder (i.e., consensus node). These blockchains are similar to
This work was supported by the NRF, Prime Minister’s Office, Sin- permissionless blockchains, except a consensus is based on a
gapore, under its National Cybersecurity R&D Programme (Award No.
NRF2016NCR-NCR002-028) and administered by the National Cybersecurity
stake rather than on resources spent. The node’s consensus
R&D Directorate. power is proportional to the stake it has. Similar to permis-

978-1-7281-4693-5/19/$31.00 ©2019 IEEE 390

DOI 10.1109/Blockchain.2019.00060
Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:41:58 UTC from IEEE Xplore. Restrictions apply.
 Owners Countermeasures

 
Layer:
 
 !


Authentication,
+ Blockchain users Application
'*  ) reputation approaches
Safe languages, audits,
RSM
Threats
  !
verification tools, mixers,
Layer:
"# )  NIZKs, ring signatures



  Application False data feeds

Consensus Economic incentives,
Privacy¬threats, smart strong consistency, de-
RSM
contract-specific¬bugs, centralization
 Consensus Network Redundancy, protection
        Protocol deviations


of naming, availability,

 
          Man in the middle attack, routing, anonymity, data
  
 Network availability, network to reduce
wish to minimize
partitioning, de-
anonymization Risk
increase
  $ give rise to
Loss of crypto-tokens,
  $
'"() Threat Agents broken functionalities,
Layer:
 

disrupted services


 Application Unspecified

  to
RSM Developers & users
to
Assets
% & Consensus Consensus nodes
wish to abuse Crypto-tokens,
Network Service providers or damage
functionalities, services

Fig. 1: Stacked model of reference architecture. Fig. 2: Threat-risk assessment model of reference architecture.

sionless blockchains, these systems are usually intended to be protocol assumptions, or application-specific dependencies.
run over the Internet. Novel aspects of (semi-)permissionless Threats facilitate various attacks on assets and services. Coun-
blockchains are incentives and network effects that are de- termeasures are provided by the security, safety, incentives,
signed to increase the protocol’s security and adoption. and reputation techniques that protect owners from threats.
Risks caused by threats and their agents may lead to losses of
II. S ECURITY R EFERENCE A RCHITECTURE monetary assets or service malfunctions and disruptions.
Stacked Model. To classify security aspects related to The owners wish to minimize the risk caused by threats that
blockchains, we introduce a simplified stacked model [88] arise from threat agents. With the stacked model, different
consisting of four layers (see Fig. 1). In contrast to previous threat agents appear at each layer. At the network layer,
work [88], we keep only such granularity level that enables there are service providers including parties managing IP
us to isolate various nature of security threats in blockchains. addresses and DNS names. The threats at this layer come
(1) The network layer (see Sec. III) consists of the data from man-in-the-middle (MITM) attacks, network partitioning,
representation and network services planes. The data represen- de-anonymization, and availability attacks. Countermeasures
tation plane deals with storing and encoding of data, while the contain protection of availability, naming, routing, anonymity,
network service plane contains discovery and communication and data. At the consensus layer, nodes may be malicious
with protocol peers, addressing, routing, and naming services. and wish to alter the outcome of the consensus protocol
(2) The consensus layer (see Sec. IV) deals with ordering by deviating from it. The countermeasures include economic
of transactions and we divide it according to a type of the incentives, strong consistency, and decentralization. At the
protocol used to Byzantine Fault Tolerant (e.g., [19], [9], RSM layer, the threat agents may stand for developers who
[60]), Proof-of-Resource (e.g., [62], [28], [66], [58], [72]), (un)intentionally introduce semantic bugs in smart contracts
and Proof-of-Stake (e.g., [7], [47]) protocols. (3) The repli- (intentional bugs represent backdoors). Mitigating counter-
cated state machine (RSM) layer (see Sec. V) deals with the measures are safe languages, static/dynamic verification, and
interpretation of transactions, according to which, the state audits. Other threats are related to privacy of data and identity
of the blockchain is updated. Smart contracts involve two of users with mitigation techniques using mixers, cryptogra-
special types of transactions, which represent a programming phy constructs (e.g., non-interactive zero-knowledge proofs
code itself and invocations of this code. (4) In the application (NIZKs), ring signatures). At the application layer, threat
layer (see Sec. VI) we present the most common end-user agents are unspecified, since any user on the network who uses
functionalities such as crypto-tokens with wallets, oracles/data a blockchain application may pose a threat. The threats on this
feeds, and decentralized file systems. Throughout the paper, layer arise from false data feeds and examples of mitigation
we summarize components of particular layers with their techniques are authentication or reputation systems.
respective security threats and protection techniques.
III. N ETWORK L AYER
Threat-Risk Assessment Model. To better capture security-
A. Private Networks
related aspects of blockchain systems, we introduce a threat-
risk model based on the template of ISO/IEC 15408 [21]. A private network ensures low latency, a centralized ad-
The model includes the following components and actors (see ministration, privacy, and meeting regulatory obligations (e.g.,
Fig. 2). Owners are blockchain users who run any node type. HIPAA). The organization owning the network provides access
Owners posses crypto-tokens and/or use blockchain-based to local participants as well as to external ones; hence systems
applications or services. Assets consist of monetary value (i.e., deploying private networks belong to the group of permis-
crypto-tokens), blockchain functionalities, as well as services sioned private blockchains. The inherent feature of private
built on top of them (e.g., exchanges, secure logging, supply networks is that authentication and access control can be
chains). Threat agents are malicious users whose intention provided at the network layer.
is to steal assets, break functionalities, or disrupt services. 1) Pros: Access control is achieved by centralized
Threats arise from vulnerabilities at the network, in smart authentication of users and assigning them roles. A private
contracts, from consensus protocol deviations, violations of network has full control over routing paths and physical

391

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:41:58 UTC from IEEE Xplore. Restrictions apply.
 resources used, which enables regulation of the network topol- latency of the network is increased – this, in turn, may result
ogy and transmission medium best suited for requirements. to loss of created blocks and thus wasting of consensus power.
Data privacy is ensured by permissioned settings. User identity 3) Security Threats and Countermeasures:
is revealed only within a private group of nodes; they are DNS attacks usually arise from cache poisoning that mainly
immune to external attacks in contrast to public networks. affects nodes employing DNS bootstrapping to retrieve online
Fine-grained authorization controls are applied by the operator peers but also users of online blockchain explorers. One coun-
of the network to implement the security principle of minimal termeasure is a security extension of DNS, called DNSSEC,
exposure and thus mitigate insider threat attacks [41]. Resource which provides authentication and data integrity. In addition,
availability is easier to manage, as all network participants and name resolution can also be made using alternate DNS servers.
the deployment scenario are known ahead of time. Routing attacks are traffic route diversions, hijacking, or
2) Cons: Virtual Private Network (VPN) connectivity is DoS attacks. Beside simple data eavesdropping or modifica-
required to communicate between private networks spread over tion, these attacks may lead to network partitioning, which
different geographical locations. While VPNs are in general in turn raises the risks of 51% attacks or selfish mining
secure, they inherit the disadvantages of running service over attacks (see Sec. IV). Countermeasures suggest nodes to be
the Internet. Applicability of private networks is suitable only multi-homed (or using VPN) for route diversity, choosing
for permissioned and private blockchains. extra peers whose connections do not pass through the same
3) Security Threats and Countermeasures: Insiders may ASes, preference of peers hosted on the same AS within the
pose a serious threat to security [4]. A compromised node same /24 prefix (to reduce risk of partitions), and fetching
may already have administrative privileges or obtain them by the same block from multiple peers [1]. Another mitigation is
exploiting security vulnerabilities. Countermeasures include SABRE [2], a secure relay network that runs alongside with
regular software updates, user monitoring (e.g., SIEM), pre- the Bitcoin network. The BGPsec [52] is an extension for BGP
vention techniques that minimize trust and maximize trustwor- used between neighboring ASes, and it provides assurance of
thiness, as well as respecting best practices [41]. route origin and propagation.
Eclipse attacks hijack all connections of a node to the
B. Public Networks / the Internet blockchain network. Hence, all traffic received by the node
is under the full control of the attacker. Eclipse attacks arise
Public networks provide high decentralization, openness, from threats on DNS and routing in the network as well as they
and low entry barrier, while network latency, privacy, and may be a result of vulnerabilities in p2p protocols [37], [91],
network control are put aside. These networks are naturally [56]). Eclipse attack increase chances of selfish mining and
required by all public (permissionless) blockchain systems. double spending attacks (see Sec. IV) – the eclipsed victims
1) Pros: High availability is attractive to multi- may vote for an attacker’s chain. Countermeasures: Improving
homed nodes since they have alternate routes to send/receive randomness in choosing peers was proposed in work [37] by
messages. Multi-homed nodes may find useful to disseminate several rules that manage the peer table. Another mitigation
blocks across multiple channels, thereby increasing a chance of strategy against eclipse attacks is to use redundant network
blocks being appended to the blockchain. Decentralization is links or out-of-band connections to verify transactions (e.g.,
achieved through geographical dispersion of nodes. Public by a blockchain explorer). Also, note that countermeasures for
peer-to-peer (p2p) networks are harder to shut down [74]. DNS and routing attacks are applicable here as well.
Openness and low entry barrier on the Internet are achieved DoS Attacks on connectivity may result in a loss of con-
through wide adoption, technology interoperability (e.g., using sensus power, thus preventing consensus nodes from being re-
TCP/IP), economic (e.g., low cost of broadband connection) warded. For validating nodes, this attack leads to disruption of
and societal (e.g., resistance to regulations) factors. some blockchain dependent services. Countermeasures: One
2) Cons: Single-point-of-failure – DNS with its hier- mitigation is to peer only with white-listed nodes. Methods
archy, IP addresses, and ASes are managed by centralized to prevent volumetric DDoS include on-premise filtering (i.e.,
parties like IANA of ICANN. External adversaries pose a with an extra network device), cloud filtering (i.e., redirection
threat to public networks. These adversaries can be classified of traffic through a cloud when DDoS is detected), or hybrid
based on their capabilities to which the blockchain network filtering [3] (i.e., combinations of the previous two).
may be exposed [75]: (1) resources under attacker control DoS attacks on local resources, such as memory and stor-
(e.g., botnets, DNS and BGP servers), (2) identities are stolen age, may reduce the peering and consensus capabilities of
or masqueraded (e.g., IP addresses participating in an eclipse nodes [53]. An example is flooding the network with low
attack or route manipulation), (3) MITM attacker (i.e., eaves- fee transactions (a.k.a., penny-flooding), which may cause
dropping and spoofing), (4) common vulnerabilities leading memory pool depletion, resulting in a system crash. Possible
to exploits, e.g., observed in DNS BIND [44], (5) revealing mitigation is raising the minimum transaction fee and rate-
secrets (e.g., de-anonymizing peers). Efficiency – although an limit the number of transactions.
average Internet bandwidth has improved in recent years, a
IV. C ONSENSUS L AYER
distribution of powerful infrastructure is not uniform, which
results in a different latency among peers, and the overall A. Generic Attacks

392

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:41:58 UTC from IEEE Xplore. Restrictions apply.
 1) Violations of Protocol Assumptions: This is in contrast to principles of PoS protocols, where a big
Adversarial Centralization of Consensus Power. In these enough coalition may override the history with almost no cost.
attacks, a design assumption about the decentralized distribu- 2) Cons: stand mainly for a high operational cost.
tion of consensus power is violated. Examples of this category Moreover, these protocols provide only probabilistic finality,
are 51% attacks for PoR and PoS protocols as well as 13 of which enables attacks forking the last few blocks of the chain.
Byzantine nodes for BFT protocols (and their combinations). 3) Security Threats and Mitigations:
In a 51% attack, the majority of the consensus power is held by Selfish Mining: In selfish mining [30], an adversary attempts
the adversary. In Byzantine attacks, a quorum of 13 adversarial to privately build a secret chain and reveal it to the public
consensus nodes might cause the protocol being disrupted or only when an honest chain is “catching up” with the secret
even halted. As a design-oriented countermeasure, it is im- one. The longest chain rule causes honest miners to adopt the
portant to promote decentralization by incentive schemes that attacker’s chain and invalidate the honest chain, thus wasting
reward honest participation and discourage [59] or punish [15], their consensus power. This attack is more efficient when
[24] protocol violations. consensus power of a selfish miner reaches some threshold
Time-Validation Attacks. Usually, besides system time, (e.g., 30%). The selfish mining strategy was later general-
nodes in PoW and PoS maintain network time that is computed ized [77] and extended to other variants that increase the
as the median value of the time obtained from the peers. profit of the attacker [63]. Countermeasures: (1) For the case
Such a time is often put into the block header, while nodes, of the longest chain rule, the first introduced mitigation is
upon receiving a block, validate whether it fits freshness uniform tie breaking [30], which tells consensus nodes to
constraints. An attacker can exploit this approach by connect- choose the chain to extend uniformly at random, regardless
ing a significant number of nodes and propagate inaccurate of which one they received first. However, this technique is
timestamps, which can slow down or speed up the victim less effective when assuming network delays [77]. (2) It is
node’s network time [12]. When such a desynchronized node recommended to use fork choice rules that also account for
creates a block, this block can be discarded by a network due the quality of solutions and make the decision deterministic,
to freshness constraints. To avoid de-synchronization attacks, as opposed to a uniform tie breaking. An example of such a
a node can build a reputation list of trusted peers or employ rule is to select the block based on the smallest hash value.
a timestamping authority [83]. Another example is to include partial solutions [93], [70],
2) Double Spending: This attack is possible due to [84] or full (orphaned) blocks [82], [96] for computation of
the creation of two or more conflicting blocks with the same block’s quality. (3) Another option is using a pseudo-random
height, resulting in inconsistencies called forks. Therefore, function [48], which moreover provides unpredictability, hence
some crypto-tokens might be temporarily spent in both con- the attacker cannot determine his chances to win a tie. (4) PoW
flicting blocks, while only a single block is later included protocols can be combined with BFT protocols, where PoW
in the honest chain. To prevent this attack in permissionless is used only for joining the protocol and BFT for consensus
blockchains, it is recommended to wait a certain amount of itself (e.g., [49], [92], [48]).
time (i.e., a few next blocks) until a block “is settled.” Feather Forking: In this attack [57], the adversary creates
incentives for rational miners to collectively censor certain
B. Proof-of-Resource Protocols (PoR) transactions. Before a mining round begins, an adversary
announces that he will not extend the block containing black-
Protocols from this category require nodes to prove a spend- listed transactions, and thus will attempt to extend a forked
ing of a scarce resource in a lottery-based fashion [43]. Scarce chain. Although this strategy is not profitable for the adversary
resources may stand for: (1) Computation that is represented and the success rate is dependent on his consensus power,
by Proof-of-Work (PoW) protocols (e.g., Bitcoin, Ethereum). rational honest nodes prefer to join on the censorship to
(2) Storage used in the setting of Proof-of-Space protocols [28] avoid the potential loss. Countermeasures: design-oriented
(e.g., Spacecoin [69], SpaceMint [42]). (3) Crypto-tokens protection is to minimize the chance of the attacker being
spent for Proof-of-Burn protocols (e.g., Slimcoin [66]). (4) successful, which can be done by including (and rewarding)
Combinations and modification of the previous types, such as partial solutions [93], [70], [84] or full orphaned blocks [82],
storage and computation, called Proof-of-Retrievability (e.g., [96] into branch difficulty computation.
Permacoin [58]) and storage over time, which is represented
by Proof-of-Space protocols (e.g., Filecoin [72]). C. Byzantine Fault Tolerant (BFT) Voting Protocols
PoR protocols belong to the first generation of consensus BFT protocols represent voting-based [43] consensus pro-
protocols, and they are mostly based on Nakamoto Con- tocols that utilize Byzantine agreement and a state machine
sensus [62] that utilize PoW, inheriting its pros (e.g., high replication [79]. These protocols assume a fully connected
scalability) and cons (e.g., low throughput). For the detailed topology, broadcasting messages, and a master-replicas hier-
analysis of several PoW designs, we refer the reader to [97]. archy. Synchronous examples of this category are PBFT [19],
1) Pros: In PoR protocols, malicious overriding of the RBFT, eventually synchronous examples are BFT-SMaRt [9],
history of blockchain (or its part) requires spending at least Tendermint [13], BChain, and asynchronous examples are
the same amount of resources as was spent for its creation. SINTRA [17] and HoneyBadgerBFT [60]. For more details,

393

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:41:58 UTC from IEEE Xplore. Restrictions apply.
we refer the reader to review of BFT protocols in [18]. chance to be rewarded. Such behavior increases the number
1) Pros: BFT protocols provide high throughput and a of forks and thus time to finality. Countermeasures: Deposit-
low latency finality. To face their scalability limitation, BFT based solutions [15] require nodes to make a deposit during
protocols are often combined with PoS or PoW. This is in some fixed period/round and checkpoint-based solutions [15],
line with a lottery approach [43] for selecting a portion of [24]) employ “state freezing” at periodic snapshots, while
all nodes, referred to as committee, which further runs BFT the blockchain can be reversed maximally up to the recent
consensus (e.g., Algorand [33], DFINITY [36]). checkpoint. Next option is to use cryptographic solutions [55]
2) Cons: The main con of traditional BFT protocols [19] for revealing identity and a private key of a node that signs two
is a low scalability caused by a high communication complex- conflicting blocks. Another countermeasure is to use backward
ity (i.e., Θ(n2 )). Since these protocols can work efficiently only penalization of nodes that produced two or more conflicting
with a limited number of consensus nodes, they can be used chains [24], [15]. Finally, PoS protocols can be combined with
in their pure form only in permissioned blockchains. BFT approaches, and thus forks can hardly occur [33].
3) Security Threats and Mitigations: Many BFT pro- Grinding Attack: If the leader or committee producing a
tocols assume synchronous delivery of messages. However, block is determined before the round starts, then the attacker
this assumption can be violated by unpredictable network can bias this process to increase his chances of being selected
scheduler, as demonstrated in [60]. This fact motivates asyn- in future. For example, if a PoS protocol takes only a hash
chronous BFT protocols that can be based on threshold- of the previous block for the election process, the leader of a
based cryptography, which enables reliable and consistent block may bias a hash value by suitably adjusting the content
broadcast [17], [60]. Issues with scalability and throughput of the block in a few attempts. Countermeasures: A grinding
can be dealt with by applying cryptographic constructs [16], attack can be prevented by performing a fresh leader election
[80] and partitioning consensus nodes into shards that process by an interaction of nodes (e.g., the secure multiparty coin
transactions in parallel [49], [92]. Another option is to prune flipping protocol [47]) or by private checking whether the
the number of nodes into committees [33]; however, this output of a verifiable random function (VRF) is below a certain
reduces security level of BFT and provides only probabilistic stake-specific threshold (e.g., [33]).
security guarantees depending on the committee size. Denial of Service on a Leader/Committee: If a leader or a
committee are publicly determined before the round starts [47],
D. Proof-of-Stake Protocols (PoS) then the adversary may conduct a DoS attack against them
Similar to the PoR category, PoS protocols are based on the and thus cause a restart of the round – this might be repeated
lottery approach [43]. However, in contrast to PoR, no scarce until adversary’s desired nodes are elected. Countermeasures:
resource is spent; instead, the nodes are required “to prove in- A prevention technique was proposed in Algorand [33] –
vestment” of crypto-tokens in order to participate in a protocol, a node privately determines whether it is a potential leader
and thus potentially earn interest from the invested amount. (or committee member), and immediately releases a block
The concept of PoS was first time proposed in Peercoin [76] candidate (or a vote) – hence, after publishing this data, it
as a combination with PoW – each node has its particular is too late for a DoS attack. The concept of VRF approach
difficulty for PoW, which is based on the age of the coins a was also utilized in other protocols [25], [36].
node owns. Although there exist a few pure PoS protocols Long-Range Attack: In this attack [14] (a.k.a., posterior
(e.g., [7], [47]), the trend is to combine them in a hybrid corruption [24]), an adversary can bribe previously influential
setting with PoR (e.g., Proof-of-Activity [6], Peercoin [76], consensus nodes to sell their private keys or steal the private
Snow White [8]) or BFT protocols (e.g., Algorand [33]). keys by other means. Since consensus nodes may exchange
In particular, a combination of PoS with BFT represents a their crypto-tokens for fiat money, selling their keys impose
promising approach taking advantages of both lottery and no expenses and risk. If the attacker accumulates keys with
voting, while no resources are wasted. enough stake in the past, he may rerun the consensus protocol
1) Pros: The main feature of PoS protocols, as and rewrite the history of the blockchain. A variant of long-
compared to PoR, is their energy efficiency. Although some range attack that considers transaction fee-based rewarding and
PoS protocols are often combined with a PoR technique (e.g., infrequent or no check-points is denoted as a stake-bleeding
[8], [76]), the overall energy spent is much less than in the attack [32]. Countermeasures: One mitigation is to lock the
case of pure PoR protocols. deposit for a longer time than the period of participation
2) Cons: Introduction of PoS protocols has brought PoS in the consensus. The next mitigation technique is frequent
specific issues and attacks, while these protocols are still not periodic check-pointing, which causes the irreversibility of
formally proven to be secure. Next, PoS protocols are semi- the blockchain with respect to the last checkpoint. Another
permissionless – a node needs to first obtain a stake from any option is to apply key-evolving cryptography and forward-
of existing nodes to join the protocol. secure digital signatures, which require users to evolve their
3) Security Threats and Mitigations: private keys, while already used keys are erased (e.g., [25]).
Nothing-at-Stake: Since generating a block in PoS does not The third mitigation technique is enforcing a chain density
cost any energy, a node can extend two or more conflict- in a time-domain [32] for the protocols where the expected
ing blocks without risking its stake, and hence increase a number of participants in each round is known (e.g., [47]).

394

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:41:58 UTC from IEEE Xplore. Restrictions apply.
The last option is context-sensitive transactions, which put the which opened the door for plenty of vulnerabilities. Hence,
hash of a recent valid block into a transaction itself [32]. Serpent showed to be as an unsuccessful attempt to simplify
the coding phase. Solidity is an object-oriented statically-
V. R EPLICATED S TATE M ACHINE L AYER typed language that is primarily used by Ethereum platform.
A. Transaction Protection Contracts written in Solidity can contain various types of
Mostly, transactions containing plain-text data are digitally vulnerabilities [5]. Mitigations of such vulnerabilities can
signed by private keys of users, enabling anybody to verify be done by code analysis tools [68], [85], respecting best
the validity of transactions by corresponding public keys. practices [81], utilizing known design patterns [90], audits,
However, such an approach provides only pseudonymous and testing. Various approaches are used for source code anal-
identities that can be traced to real identities, and moreover, ysis, such as linters (e.g., SmartCheck [85], Solhint, Solium),
it does not ensure confidentiality of data [31]. fuzzers [45], semantic-based program verifiers [39], and other
1) Security Threats and Countermeasures: symbolic code analyzers [86] often using control flow-graph
Privacy Threats to User Identity. In many blockchains, techniques. Note that source code of contracts is often not
user identities can be linked with their transactions by public in contrast to their bytecode. For this reason, bytecode
various deanonymization techniques, such as network flow decompilers (e.g., Erays [98], Porosity), analyzers [64], and
analysis, address clustering, transaction fingerprinting [31], automated exploit generators [51] can be utilized.
[10], [73]. Moreover, blockchains designed with anonymity Turing-Incomplete Languages. The main pro of this cate-
and privacy features (e.g., Zcash, Monero) are also vulnerable gory is its design-oriented goal of small attack surface and
to a few attack strategies [46]. Countermeasures: Various emphasis on safety but at the cost of limited expressiveness.
means are used for obfuscation of user identities, including Examples of this category are Pact, Scilla, Vyper. Pact is
centralized (e.g., CoinJoin, Mixcoin) and decentralized a declarative language intended for Kadena blockchain and
(e.g., CoinShuffle) mixing services, ring signatures [65], provides type inference and module-guarded tables to prevent
and non-interactive zero-knowledge proofs (NIZKs) [78]. direct access to modules. Pact is equipped with the ability to
Some mixers enable internal linkability by involved parties express and check properties of its programs, also leveraging
(e.g., CoinJoin) or linkability by the mixers (e.g., Mixcoin), SMT solvers. Scilla is designed to achieve expressiveness and
which are also potential threats. Unlinkability for all parties tractability while enabling formal reasoning about contract be-
can be achieved by multi-party computation [99], blinding havior. Every computation utilizes the automata-based model,
signatures [87], or layered encryption (e.g., CoinShuffle). and computations are realized as standalone atomic transitions
Ring signatures provide unlinkability to users in a signing that strictly terminate. Scilla enables external calls only as
group [65], enabling only verification of correctness of a the last instruction of a contract, which simplifies proving
signature, without revealing an identity of a signer. safety and thus mitigates a few vulnerabilities. Vyper is an
Privacy of data. NIZKs [78] and blind signatures [38], [87] experimental language designed to ease the audit of smart
can be used for preservation of data privacy. Another method contracts and increase security – it contains strong typing and
is homomorphic encryption [67], which enables to compute bounds/overflows checks.
some operations over encrypted messages. Privacy and confi-
dentiality for smart contract platforms can be achieved through VI. A PPLICATION L AYER
trusted transaction managers [50], trusted hardware [20], and A. Crypto-Tokens and Wallets
secure multi-party computations [100].
Besides cryptocurrencies that provide native crypto-tokens,
B. Smart Contracts there are other blockchain applications using crypto-tokens
Smart contracts, introduced to automate legal contracts, for the purpose of providing owners with rights against the
now serve as a method for building decentralized applications third party (i.e., counterparty tokens) or with a possibility
on blockchains. They are usually written in a blockchain- of transferring asset ownership (i.e., ownership tokens) [61].
specific programming language that may be Turing-complete All types of tokens require the protection of private keys and
and contain arbitrary programming logic or only serve for secrets linked with user identities. For this purpose, two main
limited purposes. In the following, we describe these two categories of wallets have emerged – self-sovereign wallets
contrasting types of smart contract languages. and hosted wallets [29], [11], [40]. Beside technical risks, all
1) Security Threats and Countermeasures: crypto-tokens are exposed to regulatory risk, while non-native
Turing-Complete Languages. This language category has a tokens are in addition exposed to legal risks [61].
large attack surface due to the possibility of arbitrary pro- Self-Sovereign Wallets. Users of self-sovereign wallets lo-
gramming logic. Examples are Serpent and Solidity, while cally store their private keys. These wallets differ in several
Solidity is the most popular and widely-used one. Serpent aspects, e.g., isolation of the keys – there are software wallets
is a high-level language that was designed to be simple that store the keys within the PC (e.g., Bitcoin Core, Electrum
and similar to the Python language. However, Serpent was Wallet, MyEtherWallet) as well as hardware wallets that store
designed in untyped fashion, lacking out-of-bound access keys in a sealed storage, while they expose only signing func-
checks of arrays and accepting invalid code by compilers [94], tionality (e.g., Trezor, Ledger, KeepKey, BitLox). Another type

395

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:41:58 UTC from IEEE Xplore. Restrictions apply.
of wallets enables to customize functionality and security by a of integration with existing blockchains. Beside naı̈ve storage
smart contract (e.g., Eth. MultiSigWallet, TrezorMultisig2of3). of integrity proofs to off-chain data, cloud services (e.g.,
Hosted Wallets. Hosted wallets require a centralized party for Amazon Web Services, Google Cloud, IBM), and distributed
interaction with the wallet and thus blockchain. If a hosted hash tables (DHT) [54] are promising approaches.
wallet has full control over private keys, it is referred to 1) Security Threats and Mitigations: While native DFs
as a server-side wallet (e.g., Coinbase, Circle Pay Wallet, handle availability and decentralization using consensus layer
Luno Wallet), while in the case of keys stored in the users’ mechanisms, cloud services and DHT solutions rely on a
browsers, the wallets are referred to as client-side wallets (e.g., provider’s infrastructure and dedicated file sharing networks,
Blockchain Wallet, BTC Wallet, Mycelium Wallet, Carbon- respectively. Sybil attacks claiming redundant storage of the
Wallet, Citowise Wallet). We refer the reader to works [40], same piece of data can be prevented by unique encryption of
[29] for a security overview of miscellaneous wallet solutions. each data copy [89]. Another attack might target the reputation
1) Security Threats and Mitigations: Since server- of the network by dropping data and its redundant copies. A
side wallets accounted for several compromises in the past, simple mitigation technique is to use multiple consensus nodes
their popularity have attenuated in favor of client-side wallets. for a file upload, which diminishes chances of the attack being
Although client-side wallets do not expose private keys to successful. Next mitigation is to hide the number of redundant
a 3rd party, they are dependent on the availability of the copies using erasure encoding [89].
online interface provided by such a party. Contrary, self- VII. C ONCLUSION
sovereign wallets do not trust in a 3rd party nor rely on its
availability. However, these wallets are susceptible to key theft In this paper, we focused on the systematization of knowl-
(i.e., malware [26], keyloggers [11], [71]). Possible mitigation edge about security aspects of blockchain systems. We pro-
of these attacks are hardware wallets displaying transactions posed security reference architecture as a stacked model,
to the user, while the user confirms signing by a button (e.g., which we further projected into a threat-risk assessment model
Trezor, Ledger, KeepKey). Another option is to protect self- that presents various threats and countermeasures. The stacked
sovereign wallets by multi-factor authentication using multi- model consists of four layers. At each of the layers, we
signatures (e.g., TrezorMultisig2of3, Eth. MultiSigWallet), surveyed specific security issues and mitigation techniques.
threshold-based cryptography [34], or air-gapped OTPs [40]. In future work, we plan to amend the security issues of each
layer by details and evidence about real-world incidents.
B. Oracles
R EFERENCES
Oracles are trusted entities that provide data reflecting the
state of the world beyond the blockchain. Prediction markets [1] M. Apostolaki et al. Hijacking bitcoin: Routing attacks on cryptocur-
rencies. In IEEE SP, 2017.
(e.g., Augur, Gnosis) were created for the purpose of trading [2] M. Apostolaki et al. SABRE: protecting bitcoin against routing attacks.
the outcome of events – individuals are incentivized to accu- arXiv preprint arXiv:1808.06254, 2018.
rately wager on these outcomes, which serve as data feeds. [3] E. Arazi. Choosing the Right DDoS Solution (Part 4): Hybrid
Protection. http://bit.ly/2XoB8V9, 2018.
Dedicated data feeds [35], [22] build on existing blockchain [4] W. Ashford. Corporate networks vulnerable to insider attacks, report
platforms or create dedicated oracle networks (e.g., ChainLink, finds. http://bit.ly/2WdPGFE, 2018.
Witnet) that internally run consensus protocol. [5] N. Atzei et al. A survey of attacks on ethereum smart contracts (SoK).
In POST, 2017.
1) Security Threats: The provision time of prediction [6] I. Bentov et al. Proof of Activity: Extending Bitcoin’s Proof of Work
markets may be long for many applications and the provided via Proof of Stake. 2014.
set of data events may be also limited. In contrast, dedicated [7] I. Bentov et al. Cryptocurrencies without proof of work. In FC, 2016.
[8] I. Bentov et al. Snow white: Provably secure proofs of stake. 2016.
data feeds enrich a data domain and significantly shorten a [9] A. Bessani et al. State Machine Replication for the Masses with BFT-
provision time; however, they often rely on a trusted party [35], SMART. In IEEE/IFIP DSN, 2014.
[22], which may misbehave or accidentally produce wrong [10] A. Biryukov et al. Deanonymisation of clients in bitcoin p2p network.
In ACM CCS, 2014.
data. Oracle networks eliminate trust in a single party by a [11] J. Bonneau et al. Sok: Research perspectives and challenges for bitcoin
consensus of the group; however, threats related to the con- and cryptocurrencies. In IEEE SP, 2015.
sensus layer of this functionality also needs to be considered. [12] A. Boverman. Timejacking & Bitcoin. http://bit.ly/2WKAnbM, 2011.
[13] E. Buchman et al. The latest gossip on BFT consensus. 2018.
Moreover, for providers that offer authenticated data feeds [14] V. Buterin. Long-range attacks: The serious problem with adaptive
using trusted hardware [22], [95], a vulnerability in trusted proof of work. http://bit.ly/2JUYNJE, 2014.
hardware may result in a compromise of the entire data feed. [15] V. Buterin and V. Griffith. Casper the friendly finality gadget. 2017.
[16] C. Cachin et al. Random oracles in constantinople: Practical asyn-
chronous byzantine agreement using cryptography. JoC, 18(3), 2005.
C. Decentralized Filesystems (DFs) [17] C. Cachin and J. A. Poritz. Secure intrusion-tolerant replication on the
DFs serve as a data storage infrastructure running native internet. In DSN, 2002.
[18] C. Cachin and M. Vukolić. Blockchain consensus protocols in the wild.
blockchains (e.g., Storj [89], Filecoin [72], Permacoin [58]). arXiv preprint arXiv:1707.01873, 2017.
DFs borrow ideas from peer-to-peer file storage systems, [19] M. Castro and B. Liskov. Practical byzantine fault tolerance. In OSDI,
but they additionally incentivize data preservation by crypto- pages 173–186, 1999.
[20] R. Cheng et al. Ekiden: A platform for confidentiality-preserving,
tokens. Alternatively to native DFs, decoupling of the stored trustworthy, and performant smart contract execution. arXiv preprint
data from the blockchain data is also possible in a few forms arXiv:1804.05141, 2018.

396

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:41:58 UTC from IEEE Xplore. Restrictions apply.
 [21] Common Criteria. Common criteria for information technology secu- [61] MME. Conceptual framework for legal and risk assessment of crypto
rity evaluation. Tech. report, 2017. tokens. http://bit.ly/2WlLed2, 2018.
[22] Concur Technologies, Inc. Oraclize documentation. http://bit.ly/ [62] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.
2wAR3UK, 2008. [63] K. Nayak et al. Stubborn mining: Generalizing selfish mining and
[23] M. Conti et al. A survey on security and privacy issues of bitcoin. combining with an eclipse attack. In IEEE EuroSP, 2016.
IEEE Communications Surveys & Tutorials, 20(4), 2018. [64] I. Nikolić et al. Finding the greedy, prodigal, and suicidal contracts at
[24] P. Daian et al. Snow white: Robustly reconfigurable consensus and scale. In ACM ACSAC, 2018.
applications to provably secure proofs of stake. In Iacr. 2017. [65] S. Noether. Ring signature confidential transactions for Monero. IACR
[25] B. David et al. Ouroboros Praos: An adaptively-secure, semi- Cryptology ePrint Archive, 2015:1098, 2015.
synchronous proof-of-stake blockchain. In EUROCRYPT, 2018. [66] P4Titan. Slimcoin: A peer-to-peer crypto-currency with proof-of-burn.
[26] Dell SecureWorks. Cryptocurrency-stealing malware landscape, 2015. Tech. report, 2014.
[27] J. R. Douceur. The sybil attack. In IPTPS, 2002. [67] P. Paillier. Public-key cryptosystems based on composite degree
[28] S. Dziembowski et al. Proofs of space. In CRYPTO’15, 2015. residuosity classes. In J. Stern, editor, EUROCRYPT’99, 1999.
[29] S. Eskandari et al. A first look at the usability of bitcoin key [68] R. M. Parizi et al. Empirical vulnerability analysis of automated smart
management. arXiv preprint arXiv:1802.04351, 2018. contracts security testing on blockchains. In CASCON, 2018.
[30] I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin mining is [69] S. Park et al. Spacecoin: A cryptocurrency based on proofs of space.
vulnerable. Communications of the ACM, 61(7), 2018. Tech. report, 2015.
[31] Q. Feng et al. A survey on privacy protection in blockchain system. [70] R. Pass and E. Shi. Fruitchains: A fair blockchain. In PODC, 2017.
Journal of Network and Computer Applications, 126, 2019. [71] A. Peyton. Cyren sounds siren over bitcoin siphon scam, 2017.
[32] P. Gaži et al. Stake-bleeding attacks on proof-of-stake blockchains. In [72] Protocol Labs. Filecoin: A decentralized storage network. Tech. report,
IEEE CVCBT, 2018. 2017.
[33] Y. Gilad et al. Algorand: Scaling byzantine agreements for cryptocur- [73] I. Pustogarov. Deanonymisation techniques for Tor and Bitcoin. PhD
rencies. In SOSP, 2017. thesis, University of Luxembourg, 2015.
[34] S. Goldfeder et al. Securing bitcoin wallets via a new dsa/ecdsa [74] R. Rodrigues and P. Druschel. Peer-to-peer systems. Commun. ACM,
threshold signature scheme, 2015. 53(10), 2010.
[75] D. S. H. Rosenthal et al. Notes on the design of an internet adversary.
[35] J. Guarnizo and P. Szalachowski. PDFS: practical data feed service for
CoRR, cs.DL/0411078, 2004.
smart contracts. arXiv preprint arXiv:1808.06641, 2018.
[76] S. King and S. Nadal. Ppcoin: Peer-to-peer crypto-currency with proof-
[36] T. Hanke et al. Dfinity technology overview series, consensus system.
of-stake. Tech. report, 2012.
arXiv preprint arXiv:1805.04548, 2018.
[77] A. Sapirshtein et al. Optimal selfish mining strategies in Bitcoin. In
[37] E. Heilman et al. Eclipse attacks on bitcoin’s peer-to-peer network. In
FC, 2016.
USENIX Security, 2015.
[78] E. B. Sasson et al. Zerocash: Decentralized anonymous payments from
[38] E. Heilman et al. Blindly signed contracts: Anonymous on-blockchain bitcoin. In IEEE SP, 2014.
and off-blockchain bitcoin transactions. In FC, 2016. [79] F. B. Schneider. Implementing fault-tolerant services using the state
[39] E. Hildenbrandt et al. Kevm: A complete semantics of the ethereum machine approach: A tutorial. ACM CSUR, 22(4), 1990.
virtual machine. Tech. report, 2017. [80] V. Shoup. Practical threshold signatures. In EUROCRYPT, 2000.
[40] I. Homoliak et al. An air-gapped 2-factor authentication for smart- [81] SmartContractSecurity. Smart contract weakness classification registry.
contract wallets. arXiv preprint arXiv:1812.03598, 2018. https://github.com/SmartContractSecurity/SWC-registry/, 2019.
[41] I. Homoliak et al. Insight into insiders and IT: A survey of insider threat [82] Y. Sompolinsky and A. Zohar. Accelerating Bitcoin’s transaction
taxonomies, analysis, modeling, and countermeasures. ACM CSUR, processing. Fast money grows on trees, not chains. 2013(881), 2013.
52(2), 2019. [83] P. Szalachowski. (short paper) towards more reliable bitcoin times-
[42] T. Hønsi. SpaceMint: A Cryptocurrency Based on Proofs of Space. tamps. In IEEE CVCBT, 2018.
Master’s thesis, NTNU, 2017. [84] P. Szalachowski et al. Strongchain: Transparent and collaborative
[43] Hyperledger team. Hyperledger architecture, vol. 1: Consensus, 2017. proof-of-work consensus. In USENIX Security, 2019.
[44] ISC. BIND 9 security vulnerability matrix. http://bit.ly/2Z1PiMj, 2019. [85] S. Tikhomirov et al. Smartcheck: Static analysis of ethereum smart
[45] B. Jiang et al. Contractfuzzer: Fuzzing smart contracts for vulnerability contracts. In WETSEB, 2018.
detection. In ASE, 2018. [86] P. Tsankov et al. Securify: Practical security analysis of smart contracts.
[46] G. Kappos et al. An empirical analysis of anonymity in zcash. In In ACM CCS, 2018.
USENIX Security, 2018. [87] L. Valenta et al. Blindcoin: Blinded, accountable mixes for Bitcoin. In
[47] A. Kiayias et al. Ouroboros: A provably secure proof-of-stake FC, 2015.
blockchain protocol. In CRYPTO’17, 2017. [88] W. Wang et al. A survey on consensus mechanisms and mining
[48] E. K. Kogias et al. Enhancing bitcoin security and performance with management in blockchain networks. 2018.
strong consistency via collective signing. In USENIX Security, 2016. [89] S. Wilkinson et al. Storj a peer-to-peer cloud storage network. 2014.
[49] E. Kokoris-Kogias et al. Omniledger: A secure, scale-out, decentralized [90] M. Wohrer and U. Zdun. Smart contracts: Security patterns in the
ledger via sharding. In IEEE S&P, 2018. ethereum ecosystem and solidity. In IWBOSE, 2018.
[50] A. Kosba et al. Hawk: The blockchain model of cryptography and [91] K. Wüst and A. Gervais. Ethereum eclipse attacks. Tech. report, 2016.
privacy-preserving smart contracts. In IEEE S&P, 2016. [92] M. Zamani et al. Rapidchain: Scaling blockchain via full sharding. In
[51] J. Krupp and C. Rossow. teether: Gnawing at ethereum to automatically ACM CCS, 2018.
exploit smart contracts. In USENIX Security, 2018. [93] A. Zamyatin et al. Flux: Revisiting Near Blocks for Proof-of-Work
[52] M. Lepinski and K. Sriram. BGPSEC protocol specification. Tech. Blockchains, 2018. https://eprint.iacr.org/2018/415/20180529:172206.
report, 2017. [94] Zeppelin Sollutions. Serpent compiler audit. bit.ly/2MrHQbX, 2017.
[53] S. D. Lerner. New DoS vuln by forcing continuous hard disk seek/read [95] F. Zhang et al. Town crier: An authenticated data feed for smart
activity. http://bit.ly/2KnCA6u, 2019. contracts. In ACM CCS, 2016.
[54] R. Li et al. Blockchain for large-scale internet of things data storage [96] R. Zhang and B. Preneel. Publish or perish: A backward-compatible
and protection. IEEE Transactions on Services Computing, 2018. defense against selfish mining in bitcoin. In CT-RSA, 2017.
[55] W. Li et al. Securing PoS blockchain protocols. In DPM. 2017. [97] R. Zhang and B. Preneel. Lay down the common metrics: Evaluating
[56] Y. Marcus et al. Low-resource eclipse attacks on ethereum’s peer-to- proof-of-work consensus protocols’ security. In IEEE S&P, 2019.
peer network. 2018, 2018. [98] Y. Zhou et al. Erays: reverse engineering ethereum’s opaque smart
[57] A. Miller. Feather-forks. http://bit.ly/2JVqsKG, 2013. contracts. In USENIX Security, 2018.
[58] A. Miller et al. Permacoin: Repurposing bitcoin work for data [99] J. H. Ziegeldorf et al. Secure and anonymous decentralized bitcoin
preservation. In IEEE S&P, 2014. mixing. Future Generation Computer Systems, 80, 2018.
[59] A. Miller et al. Nonoutsourceable scratch-off puzzles to discourage [100] G. Zyskind et al. Enigma: Decentralized computation platform with
bitcoin mining coalitions. In ACM CCS, 2015. guaranteed privacy. 2015.
[60] A. Miller et al. The honeybadger of bft protocols. In ACM CCS, 2016.

397

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:41:58 UTC from IEEE Xplore. Restrictions apply.