Abstract We report our experience in the formal verification of the reference implementation of the Beacon Chain. The Beacon Chain is the backbone component of the new Proof-of-Stake Ethereum 2.0 network: it is in charge of tracking information about the validators , their stakes , their attestations (votes) and if some validators are found to be dishonest, to slash them (they lose some of their stakes). The Beacon Chain is mission-critical and any bug in it could compromise the whole network. The Beacon Chain reference implementation developed by the Ethereum Foundation is written in Python, and provides a detailed operational description of the state machine each Beacon Chain’s network participant (node) must implement. We have formally specified and verified the absence of runtime errors in (a large and critical part of) the Beacon Chain reference implementation using the verification-friendly language Dafny. During the course of this work, we have uncovered several issues, proposed verified fixes. We have also synthesised functional correctness specifications that enable us to provide guarantees beyond runtime errors. Our software artefact with the code and proofs in Dafny is available at https://github.com/ConsenSys/eth2.0-dafny .
Recently, two attacks were presented against Proof-of-Stake (PoS) Ethereum: one where short-range reorganizations of the underlying consensus chain are used to increase individual validators' profits and delay consensus decisions, and one where adversarial network delay is leveraged to stall consensus decisions indefinitely. We provide refined variants of these attacks, considerably relaxing the requirements on adversarial stake and network timing, and thus rendering the attacks more severe. Combining techniques from both refined attacks, we obtain a third attack which allows an adversary with vanishingly small fraction of stake and no control over network message propagation (assuming instead probabilistic message propagation) to cause even long-range consensus chain reorganizations. Honest-but-rational or ideologically motivated validators could use this attack to increase their profits or stall the protocol, threatening incentive alignment and security of PoS Ethereum. The attack can also lead to destabilization of consensus from congestion in vote processing.
Rabimba Karanjai, Lei Xu, Lin Chen, Fengwei Zhang · 6 authors
Modern computer systems tend to rely on large trusted computing bases (TCBs) for operations. To address the TCB bloating problem, hardware vendors have developed mechanisms to enable or facilitate the creation of a trusted execution environment (TEE) in which critical software applications can execute securely in an isolated environment. Even under the circumstance that a host OS is compromised by an adversary, key security properties such as confidentiality and integrity of the software inside the TEEs can be guaranteed. The promise of integrity and security has driven developers to adopt it for use cases involving access control, PKS, IoT among other things. Among these applications include blockchain-related use cases. The usage of the TEEs doesn't come without its own implementation challenges and potential pitfalls. In this paper, we examine the assumptions, security models, and operational environments of the proposed TEE use cases of blockchain-based applications. The exercise and analysis help the hardware TEE research community to identify some open challenges and opportunities for research and rethink the design of hardware TEEs in general.
David L. Dill, Wolfgang Grieskamp, Junkil Park, Shaz Qadeer · 6 authors
The Move Prover (MVP) is a formal verifier for smart contracts written in the Move programming language. MVP has an expressive specification language, and is fast and reliable enough that it can be run routinely by developers and in integration testing in a few minutes. Besides the simplicity of smart contracts and the Move language, three transformations are responsible for the practicality of MVP: (1) an alias-free memory model, (2) fine-grained invariant checking, and (3) monomorphization. The entirety of the Move code for the Diem blockchain has been extensively specified and can be completely verified by MVP in a few minutes. Changes in the Diem framework must be successfully verified before being integrated into the open source repository on GitHub.
We present a static analysis approach that combines concrete values and symbolic expressions. This symbolic value-flow (“symvalic”) analysis models program behavior with high precision, e.g., full path sensitivity. To achieve deep modeling of program semantics, the analysis relies on a symbiotic relationship between a traditional static analysis fixpoint computation and a symbolic solver: the solver does not merely receive a complex “path condition” to solve, but is instead invoked repeatedly (often tens or hundreds of thousands of times), in close cooperation with the flow computation of the analysis. The result of the symvalic analysis architecture is a static modeling of program behavior that is much more complete than symbolic execution, much more precise than conventional static analysis, and domain-agnostic: no special-purpose definition of anti-patterns is necessary in order to compute violations of safety conditions with high precision. We apply the analysis to the domain of Ethereum smart contracts. This domain represents a fundamental challenge for program analysis approaches: despite numerous publications, research work has not been effective at uncovering vulnerabilities of high real-world value. In systematic comparison of symvalic analysis with past tools, we find significantly increased completeness (shown as 83-96% statement coverage and more true error reports) combined with much higher precision, as measured by rate of true positive reports. In terms of real-world impact, since the beginning of 2021, the analysis has resulted in the discovery and disclosure of several critical vulnerabilities, over funds in the many millions of dollars. Six separate bug bounties totaling over $350K have been awarded for these disclosures.
In this paper, we create a single-use and full syntax zero-knowledge proof system, a.k.a zk-Fabric. Comparing with zk-SNARKS and another variant zero-knowledge proofing system, zkBOO and it's variant zkBOO++. We present multiple new approaches on how to use partitioned garbled circuits to achieve a joint zero-knowledge proof system, with the benefits of less overhead and full syntax verification. zk-Fabric based on partitioned garbled circuits has the advantage of being versatile and single-use, meaning it can be applied to arbitrary circuits with more comprehensive statements, and it can achieve the non-interactivity among all participants. One of the protocols proposed within is used for creating a new kind of partitioned garbled circuits to match the comprehensive Boolean logical expression with multiple variables, we use the term "polythitic syntax" to refer to the context-based multiple variables in a comprehensive statement. We also designed a joint zero knowledge proof protocol that uses partitioned garbled circuits
Bryan Tan, Benjamin Mariano, Shuvendu K. Lahiri, Işıl Dillig · 5 authors
As smart contracts gain adoption in financial transactions, it becomes increasingly important to ensure that they are free of bugs and security vulnerabilities. Of particular relevance in this context are arithmetic overflow bugs, as integers are often used to represent financial assets like account balances. Motivated by this observation, this paper presents SolType, a refinement type system for Solidity that can be used to prevent arithmetic over- and under-flows in smart contracts. SolType allows developers to add refinement type annotations and uses them to prove that arithmetic operations do not lead to over- and under-flows. SolType incorporates a rich vocabulary of refinement terms that allow expressing relationships between integer values and aggregate properties of complex data structures. Furthermore, our implementation, called Solid, incorporates a type inference engine and can automatically infer useful type annotations, including non-trivial contract invariants. To evaluate the usefulness of our type system, we use Solid to prove arithmetic safety of a total of 120 smart contracts. When used in its fully automated mode (i.e., using Solid's type inference capabilities), Solid is able to eliminate 86.3% of redundant runtime checks used to guard against overflows. We also compare Solid against a state-of-the-art arithmetic safety verifier called VeriSmart and show that Solid has a significantly lower false positive rate, while being significantly faster in terms of verification time.
Binary Attestation (BA) ist ein Sicherheitsmechanismus, der schon lange zur Sicherstellung der Integrität der auszuführenden Software auf einem Computerssystem verwendet wird. Dies wird durch die Anwendung der Konzepte von Trusted Computing Technologie erreicht. Die Konzepte der Trusted Computing Technologie sind: Trusted Platform Module (TPM), measured/trusted boot und Linux Integrity Measurement Architecture (IMA). Damit die Vertrauenswürdigkeit des Betriebszustandes des Systems überprüft werden kann, wird eine Logdatei erstellt. Diese enthält den Dateinamen und die Hash-Summe der Softwarekomponenten, welche an das TPM gebunden wird. Zu einem späteren Zeitpunkt kann eine entfernte Partei (Verifier) die Evidenz verifizieren, um zu sehen, ob der Betriebszustand des Systems vertrauenswürdig ist. Dies wird als Remote Attestation (RA) bezeichnet.Auf den Systemen im Bereich der Cyber-physische Systeme (z. B.: Energie Netze und Kernkraftwerke) und im Bereich der Verkehrsmittel (z. B.: Züge und Automobil Fahrzeuge) laufen mehrere Anwendungen von verschiedenen Herstellern. Bei bisherigen Ansätzen der BA, werden alle Einträge der Logdatei von allen laufenden Anwendungen aller Hersteller während der RA an die entfernte Partei preisgegeben. Daher gewährleistet die Binary Remote Attestation keine Privatheit. Diese Masterarbeit adressiert die genannte Schwäche von der Binary Remote Attestation indem es eine Privacy-Preserving Remote Attestation Ansatz erstellt. Im Kern der Arbeitsteht die Konzeptionierung eines Ansatzes, welches den Trusted Computing Sektor mit Privacy-Enhancing Technologie verknüpft. Der Ansatz bewahrt die Privatheit, indem alle Logeinträge verschleiert werden. Dabei werden dem Verifier nur die jeweilig zugehörigen Einträge offengelegt. Dadurch kann der Attester dem Verifier durch die Anwendung des Schnorr Non-Interactive Zero-Knowledge Proofs über eine elliptische Kurve (Schnorr-Signatur) beweisen, dass es sich bei den ausgeblendeten Einträgen um die tatsächlich laufende Anwendung auf dem System des Attesters handelt, ohne die anderen Einträge preiszugeben. Dieser Ansatz wird in dieser Arbeit als Proof-of-Concept umgesetzt. Die Leistung und die Privatheit des Proof-of-Concepts wurden in dieser Arbeit analysiert. Hierdruch wird gezeigt, dass die Privatheit gegenüber der entfernten Partei gewährleistet wird, während die Integrität und Authentizität des Betriebszustands des Systems vom Attester sichergestellt wird. Die Gewährleistung der Privatheit geht allerdings mit einem Anstieg der benötigten Ressourcen einher.
Sebastian Friebe, Oliver Stengele, Hannes Hartenstein, Martina Zitterbart
When software systems become more complex, it can be advantageous to partition their code into multiple, separate components. In this work, we examine how multiple smart contracts can be coupled to work together. When coupling smart contracts, different design approaches are possible with their own advantages and disadvantages. As an example, we couple two smart contract applications on the Ethereum blockchain: Palinodia and DecentID. Palinodia can be used to ensure the integrity of downloaded executable binaries by checking their hashes against the hashes stored in the blockchain. To make sure that not everyone can modify the data stored on the blockchain, an identity management system is required. This task is fulfilled by DecentID, which provides decentralized identities stored as smart contracts on the blockchain. We evaluate approaches of coupling these two applications and discuss their benefits and drawbacks for this use case.
The beacon chain is the backbone of the Ethereum's evolution towards a proof-of-stake-based scalable network. Beacon clients are the applications implementing the services required to operate the beacon chain, namely validators, beacon nodes, and slashers. Security defects in beacon clients could lead to loss of funds, consensus rules violation, network congestion, and other inconveniences. We reported more than 35 issues to the beacon client developers, including various security improvements, specification inconsistencies, missing security checks, exposure to known vulnerabilities. None of our findings appears to be high-severity. We covered the four main beacon clients, namely Lighthouse (Rust), Nimbus (Nim), Prysm (Go), and Teku (Java). We looked for bugs in the logic and implementation of the new security-critical components (BLS signatures, slashing, networking protocols, and API) over a 3-month project that followed a preliminary analysis of BLS signatures code. We focused on Lighthouse and Prysm, the most popular clients, and thus the highest-value targets. Furthermore, we identify protocol-level issues, including replay attacks and incomplete forward secrecy. In addition, we reviewed the network fingerprints of beacon clients, discussing the information obtainable from passive and active searches, and we analyzed the supply chain risk related to third-party dependencies, providing indicators and recommendations to reduce the risk of backdoors and unpatchable vulnerabilities. Our results suggest that despite intense scrutiny by security auditors and independent researchers, the complexity and constant evolution of a platform like Ethereum requires regular expert review and thorough SSDLC practices.
Ethereum smart contracts have been gaining popularity toward the automation of so many domains, i.e., FinTech, IoT, and supply chain, which are based on blockchain technology. The most critical domain, e.g., FinTech, has been targeted by so many successful attacks due to its financial worth of billions of dollars. In all attacks, the vulnerability in the source code of smart contracts is being exploited and causes the steal of millions of dollars. To find the vulnerability in the source code of smart contracts written in Solidity language, a state-of-the-art work provides a lot of solutions based on dynamic or static analysis. However, these tools have shown a lot of false positives/negatives against the smart contracts having complex logic. Furthermore, the output of these tools is not reported in a standard way with their actual vulnerability names as per standards defined by the Ethereum community. To solve these problems, we have introduced a static analysis tool, SESCon (secure Ethereum smart contract), applying the taint analysis techniques with XPath queries. Our tool outperforms other analyzers and detected up to 90% of the known vulnerability patterns. SESCon also reports the detected vulnerabilities with their titles, descriptions, and remediations as per defined standards by the Ethereum community. SESCon will serve as a foundation for the standardization of vulnerability detection.
Blockchain technology has developed significantly over the last decade. One of the reasons for this is its sustainability architecture, which does not allow modification of the history of committed transactions. That means that developers should consider blockchain vulnerabilities and eliminate them before the deployment of the system. In this paper, we demonstrate a statistical model checking approach for the verification of blockchain systems on three real-world attack scenarios. We build and verify models of DNS attack, double-spending with memory pool flooding, and consensus delay scenario. After that, we analyze experimental results and propose solutions to avoid these kinds of attacks.
Hardware wallets are designed to withstand malware attacks by isolating their private keys from the cyberspace, but they are vulnerable to the attacks that fake an address stored in a clipboard. To prevent such attacks, a hardware wallet asks the user to verify the recipient address shown on the wallet display. Since crypto addresses are long sequences of random symbols, their manual verification becomes a difficult task. Consequently, many users of hardware wallets elect to verify only a few symbols in the address, and this can be exploited by an attacker. In this work, we introduce EthClipper, an attack that targets owners of hardware wallets on the Ethereum platform. EthClipper malware queries a distributed database of pre-mined accounts in order to select the address with maximum visual similarity to the original one. We design and implement a EthClipper malware, which we test on Trezor, Ledger, and KeepKey wallets. To deliver computation and storage resources for the attack, we implement a distributed service, ClipperCloud, and test it on different deployment environments. Our evaluation shows that with off-the-shelf PCs and NAS storage, an attacker would be able to mine a database capable of matching 25% of the digits in an address to achieve a 50% chance of finding a fitting fake address. For responsible disclosure, we have contacted the manufactures of the hardware wallets used in the attack evaluation, and they all confirm the danger of EthClipper.
Lu Liu, Lili Wei, Wuqi Zhang, Ming Wen · 6 authors
Smart contracts are programs stored on blockchains to execute transactions. When input constraints or security properties are violated at runtime, the transaction being executed by a smart contract needs to be reverted to avoid undesirable consequences. On Ethereum, the most popular blockchain that supports smart contracts, developers can choose among three transaction-reverting statements (i.e., require, if…revert, and if…throw) to handle anomalous transactions. While these transaction-reverting statements are vital for preventing smart contracts from exhibiting abnormal behaviors or suffering malicious attacks, there is limited understanding of how they are used in practice. In this work, we perform the first empirical study to characterize transaction-reverting statements in Ethereum smart contracts. We measured the prevalence of these statements in 3,866 verified smart contracts from popular dapps and built a taxonomy of their purposes via manually analyzing 557 transaction-reverting statements. We also compared template contracts and their corresponding custom contracts to understand how developers customize the use of transaction-reverting statements. Finally, we analyzed the security impact of transaction-reverting statements by removing them from smart contracts and comparing the mutated contracts against the original ones. Our study led to important findings. For example, we found that transaction-reverting statements are commonly used to perform seven types of authority verifications or validity checks, and missing such statements may compromise the security of smart contracts. We also found that current smart contract security analyzers cannot effectively handle transaction-reverting statements when detecting security vulnerabilities. Our findings can shed light on further research in the broad area of smart contract quality assurance and provide practical guidance to smart contract developers on the appropriate use of transaction-reverting statements.
Smart contracts are programs that are deployed and executed on the blockchain. Typically, smart contracts govern assets; popular smart contracts can govern assets worth millions. Just like traditional programs, smart contracts are subject to programming mistakes. However, a major difference is that smart contracts cannot be patched once deployed. Several approaches have been studied to improve smart contract security, by detecting bugs prior to deployment, allowing contracts to be updated, or modifying clients to prevent attacking transactions. The most elegant solution would be to automatically eliminate bugs prior to deployment. Merely identifying bugs is not enough. This became evident when the Parity wallet was hacked a second time after being manually patched following a security audit. Automatic pre-deployment patching offers a powerful promise to strengthen smart contract defenses. Current approaches are limited in the types of vulnerabilities that can be patched, in the flexibility of the patching process, and in scalability. In this paper we propose Elysium, a scalable approach towards automatic smart contract repair, that combines template-based patching with semantic patching by inferring context information from the bytecode. Elysium can currently automatically patch 7 known vulnerabilities in smart contracts using external bug-finding tools, and it can easily be extended with new templates and new bug-finding tools. We evaluate effectiveness and correctness of Elysium using 3 different datasets by replaying more than 500K transactions against patched contracts. We find that Elysium outperforms existing tools by patching at least 30% more contracts. Finally, we compare the overhead in terms of deployment and transaction cost increase. In comparison to other tools, Elysium minimizes transaction cost (up to a factor of 1.9), for only a marginally higher deployment cost.
Fixing bugs is easiest by patching source code. However, source code is not always available: only 0.3% of the ~49M smart contracts that are currently deployed on Ethereum have their source code publicly available. Moreover, since contracts may call functions from other contracts, security flaws in closed-source contracts may affect open-source contracts as well. However, current state-of-the-art approaches that operate on closed-source contracts (i.e., EVM bytecode), such as EVMPatch and SmartShield, make use of purely hard-coded templates that leverage fix patching patterns. As a result, they cannot dynamically adapt to the bytecode that is being patched, which severely limits their flexibility and scalability. For instance, when patching integer overflows using hard-coded templates, a particular patch template needs to be employed as the bounds to be checked are different for each integer size. In this paper, we propose Elysium, a scalable approach towards automatic smart contract repair at the bytecode level. Elysium combines template-based and semantic-based patching by inferring context information from bytecode. Elysium is currently able to patch 7 different types of vulnerabilities in smart contracts automatically and can easily be extended with new templates and new bug-finding tools. We evaluate its effectiveness and correctness using 3 different datasets by replaying more than 500K transactions on patched contracts. We find that Elysium outperforms existing tools by patching at least 30% more contracts correctly. Finally, we also compare the overhead of Elysium in terms of deployment and transaction cost. In comparison to other tools, we find that generally Elysium minimizes the runtime cost (i.e., transaction cost) up to a factor of 1.7, for only a marginally higher deployment cost, where deployment cost is a one-time cost as compared to the runtime cost.
Verifiable delay functions have found a lot of applications in blockchain technology in recent times. Continuous verifiable delay functions are an improvement over the basic notion of VDFs with recursive capabilities. We are proposing the application of VDF for constructing more space time-efficient provers and simulators required for the iterative non-interactive zero-knowledge systems.
Santiago Figueroa-Lorenzo, Javier Añorga, Saioa Arrizabalaga
Security is the main challenge of the Modbus IIoT protocol. The systems designed to provide security involve solutions that manage identity based on a centralized approach by introducing a single point of failure and with an ad hoc model for an organization, which handicaps the solution scalability. Our manuscript proposes a solution based on self-sovereign identity over hyperledger fabric blockchain, promoting a decentralized identity from which both authentication and authorization are performed on-chain. The implementation of the system promotes not only Modbus security, but also aims to ensure the simplicity, compatibility and interoperability claimed by Modbus.
Afonso Falcão, Andreia Mordido, Vasco T. Vasconcelos
The popularity of smart contracts is on the rise, yet breaches in reliability and security linger. Among the many facets of smart contract reliability, we concentrate on faults rooted in out-of-order interactions with contract endpoints. We propose SmartScribble, a protocol language to describe valid patterns of interaction between users and endpoints. SmartScribble not only ensures correct interactive behaviour but also simplifies smart contract coding. From a protocol description, our compiler generates a smart contract that can then be completed by the programmer with the relevant business logic. The generated contracts rely on finite state machines to control endpoint invocations. As a proof of concept, we target Plutus, the contract programming language for the Cardano blockchain. Preliminary evaluation points to a 75% decrease in the size of the code that developers must write, coupled with an increase of reliability by enforcing the specified patterns of interaction.
Abstract This paper presents HashWires, a hash-based range proof protocol that is applicable in settings for which there is a trusted third party (typically a credential issuer) that can generate commitments. We refer to these as “credential-based” range proofs (CBRPs). HashWires improves upon hashchain solutions that are typically restricted to micro-payments for small interval ranges, achieving an exponential speedup in proof generation and verification time. Under reasonable assumptions and performance considerations, a Hash-Wires proof can be as small as 305 bytes for 64-bit integers. Although CBRPs are not zero-knowledge and are inherently less flexible than general zero-knowledge range proofs, we provide a number of applications in which a credential issuer can leverage HashWires to provide range proofs for private values, without having to rely on heavyweight cryptographic tools and assumptions.
Lianna Zhao, Luigi Vigneri, Andrew Cullen, William H. Sanders · 6 authors
Access control is a fundamental component of the design of distributed ledgers, influencing many aspects of their design, such as fairness, efficiency, traditional notions of network security, and adversarial attacks such as Denial-of-Service (DoS) attacks. In this work, we consider the security of a recently proposed access control protocol for Directed Acyclic Graph-based distributed ledgers. We present a number of attack scenarios and potential vulnerabilities of the protocol and introduce a number of additional features which enhance its resilience. Specifically, a blacklisting algorithm, which is based on a reputation-weighted threshold, is introduced to handle both spamming and multi-rate malicious attackers. The introduction of a solidification request component is also introduced to ensure the fairness and consistency of network in the presence of attacks. Finally, a timestamp component is also introduced to maintain the consistency of the network in the presence of multi-rate attackers. Simulations to illustrate the efficacy and robustness of the revised protocol are also described.
Scott Wesley, Maria Christakis, Jorge A. Navas, Richard Trefler · 6 authors
Solidity smart contracts are programs that manage up to 2^160 users on a\nblockchain. Verifying a smart contract relative to all users is intractable due\nto state explosion. Existing solutions either restrict the number of users to\nunder-approximate behaviour, or rely on manual proofs. In this paper, we\npresent local bundles that reduce contracts with arbitrarily many users to\nsequential programs with a few representative users. Each representative user\nabstracts concrete users that are locally symmetric to each other relative to\nthe contract and the property. Our abstraction is semi-automated. The\nrepresentatives depend on communication patterns, and are computed via static\nanalysis. A summary for the behaviour of each representative is provided\nmanually, but a default summary is often sufficient. Once obtained, a local\nbundle is amenable to sequential static analysis. We show that local bundles\nare relatively complete for parameterized safety verification, under moderate\nassumptions. We implement local bundle abstraction in SmartACE, and show\norder-of-magnitude speedups compared to a state-of-the-art verifier.\n
We define a technique for analyzing updates of smart contracts balances due to transfers of digital assets. The analysis addresses a lightweight smart contract language and consists of a two-step translation. First, we define the input-output behaviors of smart contract functions by means of a simple functional language with static dispatch. Then we associate the terms of this intermediate language with cost equations that compute the loss or gain of digital assets. The resulting equations can be fed to an off-the-shelf cost analyzer to provide upper bounds to the loss or gain. Our analysis has been prototyped and we report its assessments and discuss extensions with additional features.
Blockchain creates a secure environment on top of strict cryptographic assumptions and rigorous security proofs. It permits on-chain interactions to achieve trustworthy properties such as traceability, transparency, and accountability. However, current blockchain trustworthiness is only confined to on-chain, creating a “trust gap” to the physical, off-chain environment. This is due to the lack of a scheme that can truthfully reflect the physical world in a real-time and consistent manner. Such an absence hinders further blockchain applications in the physical world, especially for the security-sensitive ones. In this paper, we propose a framework to extend blockchain trust from on-chain to off-chain, and take trustworthy vaccine tracing as an example scheme. Our scheme consists of 1) a Trusted Execution Environment (TEE)-enabled trusted environment monitoring system built with the Arm Cortex-M33 microcontroller that continuously senses the inside of a vaccine box through trusted sensors and generates anti-forgery data; and 2) a consistency protocol to upload the environment status data from the TEE system to blockchain in a truthful, real-time consistent, continuous and fault-tolerant fashion. Our security analysis indicates that no adversary can tamper with the vaccine in any way without being captured. We carry out an experiment to record the internal status of a vaccine shipping box during transportation, and the results indicate that the proposed system incurs an average latency of 84 ms in local sensing and processing followed by an average latency of 130 ms to have the sensed data transmitted to and been available in the blockchain.