Table of Links Abstract and I. Introduction Abstract and I. Introduction II. A Lightning Tour II. A Lightning Tour III. Systematization Methodology III. Systematization Methodology IV. Layer-One Solution IV. Layer-One Solution V. Layer-Two Solution V. Layer-Two Solution VI. Discussion VI. Discussion VII. Research Challenges VII. Research Challenges VIII. Concluding Remarks and References VIII. Concluding Remarks and References Appendix A. Key Managements Appendix A. Appendix A. Key Managements Appendix B. Anonymity and Confidentiality Appendix B. Appendix B. Anonymity and Confidentiality Appendix C. Background Appendix C. Appendix C. Background Appendix D. A TCSC-Based Voting Protocol Appendix D. Appendix D. A TCSC-Based Voting Protocol VI. DISCUSSION This section compares layer-one and layer-two solutions, and discusses the hardware’s options and impacts. A. L1 and L2 Comparison A. L1 and L2 Comparison Which solution is more secure? Even if we have built clear security metrics based on threat models and give concise security analyses in the context of layered architectures, it is still inadequate for answering this question: Which solution is more secure, layer-one solution or layer-two solution? This is because system security is a multidimensional topic, and measuring all security aspects is impractical. The security flaws may happen in any phase in a system [87]. Despite some projects performing well in our evaluation, we cannot roughly say that they are more secure. As hybrid technologies, both layer-one and layer-two systems have unsatisfactory security vulnerabilities in existing systems, and they must be carefully treated when applying them to real applications. Frankly speaking, there is a long road to achieving such a practically secure and confidential system. Our aim is not to argue which solution is more secure. Instead, we focus on helping developers and communities to establish a security measurement and avoid potential pitfalls in designing TCSC. Which solution is more secure? Which solution is more secure, layer-one solution or layer-two solution? Which solution is more efficient? The layer-one solutions require the contract to be confidentially executed in a distributed TEE network, which is time-consuming and hard to scale out. In contrast, layer-two systems only upload final calculated results from offline TEEs to online blockchains. Local TEE hosts can execute complicated computations with high scalability and short execution time. Assuming that the on-chain processing time remains stable, the overall performance gets improved by enabling parallel off-chain executions. Thus, from the view of performance and scalability, the layer-two solution is our recommendation. Which solution is more efficient? Which solution is more adoptable? From the aforementioned discussion, we can observe that the layer-one and layertwo solutions fit different scenarios. The layer-one solution is more adoptable in consortium blockchain systems, while the layer-two solution well fits the existing public blockchain systems. Layer-one systems require each blockchain node to equip a TEE, which is difficult to be fulfilled in a public blockchain while already in use. In a consortium blockchain, the nodes are controllable and manageable, and the committee can require each node to equip a TEE when joining the network. On the flip side, the layer-two solution does not change the original blockchain trust assumption. Instead, it creates an independent layer for executing the smart contract, and thus allows developers to seamlessly integrate the TEE into existing public blockchains without significant modifications. Which solution is more adoptable? B. Hardware-anchored TEE Options B. Hardware-anchored TEE Options Securing smart contracts with TEEs is challenging because we have to assume a strong attacker model, in which the attacker has physical possession of the hardware running the smart contract and can interfere with it in powerful ways. This part discusses the security impact of choosing different TEE architectures. In particular, we select Intel SGX [88], Arm TrustZone [89] and dedicated chip [90] as examples. Intel SGX Arm TrustZone dedicated chip Intel SGX is a system allowing one to set up protected enclaves running on an Intel processor. Such enclaves are protected from malware running outside the enclave, including in the operating system. Enclaves can attest their software and computations using a signing key ultimately certified by Intel. Intel SGX has been marketed for desktop machines and servers alike; Microsoft Azure [91] is a commercial cloud offering that allows cloud customers to set up SGX enclaves in the cloud. Many attacks on SGX have been published in the eight years since its release. They may be categorised as side-channel attacks [92], fault attacks [93], [94] and software attacks [95]. While some of these attacks can be solved by improvements of SGX, it is unclear that it will ever be possible to have a completely secure version, because the attack surface is large, in the case of smart contracts, one has to assume that attackers have physical possession of the hardware. ARM TrustZone [89] is a technology widely used in mobile phones to protect secrets, such as secrets used in banking apps. Its ubiquity makes it an attractive option. However, it has been attacked even more than Intel SGX, and doesn’t offer a suitable attestation framework. Future hardware-anchored security products from ARM may address this problem. Dedicated chips such as the Open Titan [90] family of chips offer a better solution. Open Titan is an open-source design inspired by Google Titan, a chip used on Google servers and in Google mobile phones. The fact that the smart contract runs on a dedicated chip not shared with attacker code means that the attack surface is much smaller. Attestation frameworks exist for such chips, and the attestation keys can be rooted in a manufacturer’s certificate. The kind of attacks mentioned for SGX become much harder to mount. Nevertheless, even dedicated chips may succumb to a dedicated and resourceful attacker. Researchers have succeeded in mounting attacks based on power side-channels and electromagnetic (EM) radiation side channels. Defences against such attacks include masking, which consists of randomly splitting every sensitive intermediate variable into multiple shares. Even if the adversary is able to learn a share of the secret via side-channel, it would need all of them in order to recover the secret. Fault attacks such as EM and voltage glitching are also possible, but again, there are known defences [96] at both a software and hardware level. Software defences include making secret-dependent computations twice (in general n times) and then comparing results before producing any output. Countermeasures in hardware involve having internal voltage monitoring circuitry, which makes sure that the input voltage remains within a safe operation range and resets the device otherwise. n Authors:
(1) Rujia Li, Southern University of Science and Technology, China, University of Birmingham, United Kingdom and this author contributed equally to this work;
(2) Qin Wang, CSIRO Data61, Australia and this author contributed equally to this work;
(3) Qi Wang, Southern University of Science and Technology, China;
(4) David Galindo, University of Birmingham, United Kingdom;
(5) Mark Ryan, University of Birmingham, United Kingdom. Authors: Authors: (1) Rujia Li, Southern University of Science and Technology, China, University of Birmingham, United Kingdom and this author contributed equally to this work; (2) Qin Wang, CSIRO Data61, Australia and this author contributed equally to this work; (3) Qi Wang, Southern University of Science and Technology, China; (4) David Galindo, University of Birmingham, United Kingdom; (5) Mark Ryan, University of Birmingham, United Kingdom. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Southern

Blockchain Security Layers: Tradeoffs Between L1, L2, and Hardware TEEs

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

The Metaverse - Opportunities and Challenges

Exploring Blockchain Use Cases in Solving Agricultural Distress

Win Your Share of 15,000 USDT in the Spacecoin Writing Contest by Spacecoin and HackerNoon

Why the Blockchain Struggles to Grow and How to Fix It

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

The Metaverse - Opportunities and Challenges

Exploring Blockchain Use Cases in Solving Agricultural Distress

Win Your Share of 15,000 USDT in the Spacecoin Writing Contest by Spacecoin and HackerNoon

Why the Blockchain Struggles to Grow and How to Fix It

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps