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

Table of Links

Abstract and I. Introduction

II. A Lightning Tour

III. Systematization Methodology

IV. Layer-One Solution

V. Layer-Two Solution

VI. Discussion

VII. Research Challenges

VIII. Concluding Remarks and References

Appendix A. Key Managements

Appendix B. Anonymity and Confidentiality

Appendix C. Background

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

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 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 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.

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 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.