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 III. SYSTEMATIZATION METHODOLOGY To find common aspects (e.g., offered functionality, design model, adversary model), we extract recurring design patterns from publicly available publications and projects, focusing on systematization and evaluation of desirable properties (the main target of TCSC) and potential pitfalls of underlying systems. Our systematization methodology follows the idea in [52]: classification and evaluation. We firstly make a classification for the current systems and then define a framework to evaluate them. Details are presented as below. A. System Classification A. System Classification We classify the existing systems into two main categories: layer-one solution (L1) and layer-two solution (L2). The layer-one solution executes the contract inside a TEE in the blockchain, requiring every blockchain node to equip a TEE. Instead, the layer-two solution decouples contract computations from the blockchain. It performs most of the smart contract computations off-chain. For a clear understanding, we make a comparison of the original blockchain (e.g., Ethereum), L1 solution, L2 solution. As in Tab.II, Ethereum runs smart contracts (in EVM) and consensus procedures in the same machine of distributed nodes. All the contract and transaction operations are publicly verifiable due to their total transparency. The layer-one solution performs such operations (contract execution and consensus) in the same machine, but contract operations are separate from consensus procedures. In contrast, the layer-two solution makes both of them operate independently. Contracts are executed outside the blockchain network, while the consensus happens inside each node. B. Desirable Property B. Desirable Property Ideally, moving smart contract executions into TEEs brings additional privacy as well as maintaining the original benefits of blockchain systems. Therefore, we have identified the desirable properties in two main categories: privacy-preserving property and blockchain intrinsic feature. privacy-preserving property blockchain intrinsic feature Privacy-preserving property. The property of confidentiality is the most distinguished feature in TCSC. Privacy-preserving property. A1. Specification hidden. The source code of a smart contract is hidden during the deployment and the subsequent synchronization and execution. A1. Specification hidden. A2. Input privacy. The inputs fed into a confidential smart contract are hidden from the public. A2. Input privacy. A3. Output privacy. The outputs returned from a confidential smart contract should be kept private. A3. Output privacy. A4. Procedure privacy. The execution procedure is hidden from unauthorized parties. An adversary cannot learn the operation knowledge inside a TEE. A4. Procedure privacy. A5. Address unlinkability. The address pseudonymity does not entail strong privacy guarantees [53], [54]. This property prevents an adversary to learn the address linkability by observing users’ activities. A5. Address unlinkability. A6. Address anonymity. The contract caller’s identity (a user who invokes a smart contract) is hidden from an anonymity set [24] (see Appendix B). A6. Address anonymity. Blockchain intrinsic feature. TEE-assisted smart contracts inherit features given by original blockchain systems. We summarize these features as follows. Blockchain intrinsic feature. A7. Code immutability. Once a contract is successfully deployed, its source code cannot be altered. A7. Code immutability. A8. (Confidential) state consistency. Executions happening at a certain blockchain height will output the same result across different nodes. A8. (Confidential) state consistency. A9. Contract interoperability. A smart contract can call another contract and be called by others. A9. Contract interoperability. A10. High availability. A smart contract is continuously accessible without the single point of failure. A10. High availability. A11. Decentralized execution. A smart contract runs over the decentralized network. A11. Decentralized execution. A12. Automatic execution. A smart contract can be automatically executed once conditions are satisfied. A12. Automatic execution. A13. Gas mechanism. Operations running on the smart contract will be charged with gas fees [2]. A13. Gas mechanism. A14. Explicit invocation. Each invocation will be formatted as a transaction and stored on blockchain. A14. Explicit invocation. A15. Public verifiability. The procedure of contract execution and result are publicly verifiable. A15. Public verifiability. A16. Consensus verifiability. The consensus procedure on the (confidential) state is publicly verifiable. A16. Consensus verifiability. C. System Evaluation C. System Evaluation Essentially, all TCSC systems share the same principle: a TEE will handle the data from users. After that, encrypted data flows from the TEE to blockchain. The TEE plays a crucial role. Thus, this part defines a framework for evaluating underlying blockchain systems from four aspects: TEE host, TEE security, TEE program, and TEE key management. This framework aims to identify potential design flaws and pitfalls based on the threat model and data workflow. TEE will handle the data from users. TEE to blockchain. TEE plays a crucial role. TEE host, TEE security, TEE program TEE key management. Threat model. Our threat model mainly captures three types of attackers, which are stated as follows. Threat model. T1. User adversary (active/passive). An attacker may control network between users and TEE host nodes. T1. User adversary (active/passive). T2. TEE adversary (active/passive). An adversary may control TEE hosts or control the network between TEE and blockchain platforms. T2. TEE adversary (active/passive). T3. Blockchain adversary (active/passive). An adversary may drop, modify and delay the blockchain messages. But the majority (or two-thirds) of the blockchain nodes are assumed to be honest. T3. Blockchain adversary (active/passive). Note that adversaries are not necessarily exclusive. In some cases, adversaries in different types may collude. Security considerations. This section defines four metrics regarding system security according to the data workflow: approaches to enhance the security of a TEE host, countermeasures to mitigate intrinsic TEE issues, methods to prevent program flaws or bugs inside TEEs, and solutions to clear up the TEE key security dilemma. Security considerations. TEE host security. A TEE and its interaction with the external environment (e.g., with users or the blockchain) are operated and controlled by a host (such as a L1 blockchain node). A malicious host has abilities to abort the executions of a TEE, delay and modify inputs, or even drop any ingoing or outgoing messages. The following metrics discuss the approaches to improve the TEE host’s security. TEE host security. P1. Host punishment mechanism. Penalty mechanisms to reduce the risk of doing evil by a TEE host. P1. Host punishment mechanism. P2. Host incentive mechanism. Incentive mechanisms to promote a TEE host to behave honestly. P2. Host incentive mechanism. P3. Host fault tolerance. Solutions to make systems continually operate despite malfunctions or failures. P3. Host fault tolerance. P4. Host authentication. Methods to check the identity and the capability of a TEE host. P4. Host authentication. TEE security. A TEE has inevitable weaknesses. For example, a TEE is vulnerable to side-channel attacks [55], [56]. These innate weaknesses directly pose severe challenges to the design and implementation of TEE-assisted contract systems. This part defines the defence approaches against these threats. TEE security. P5. TEE attestation security. Methods to prevent TEE attestation service from being abnormally broken. P5. TEE attestation security. P6. TEE memory limitation. Methods to optimize the memory size to prevent confidential data overflow. P6. TEE memory limitation. P7. TEE physical attacks. Approaches to prevent physical attacks, such as the Spectre vulnerability or the Meltdown vulnerability [57]. P7. TEE physical attacks. P8. TEE trusted timer. Approaches to provide a trusted timer when running a TEE. P8. TEE trusted timer. TEE program security. Even a TEE is secure as assumed, a program bug may destroy the contract’s confidentiality in the real world. This part focuses on the measurements to prevent TEE programs from flaws or bugs. TEE program security. P9. Workload measurement. The workload measurement approach to prevent an infinite loop attack. P9. Workload measurement. P10. Flaws detection. Formal techniques used for the modelling and verification of the source code of smart contracts to reduce the vulnerabilities. P10. Flaws detection. P11. User query restriction. The restriction on users’ queries, aiming to avoid data leakage resulting from differentialprivacy analysis [58]. P11. User query restriction. P12. Blockchain data confirmation. Methods for a TEE to check whether input data from blockchain has been confirmed to prevent the rollback attack [59]. P12. Blockchain data confirmation. P13. TEE output conflicts. Methods to avoid multiple TEEs to produce a conflict result. P13. TEE output conflicts. TEE key security. Various keys (cf. Appendix A) are involved in the contract execution, including TEE internal keys such as the attestation key and TEE service keys for state encryption/decryption. Since service keys directly affect the protection of contract states, the key security evaluation in this SoK mainly focuses on the generation, exchange, and storage of the TEE service key. TEE key security. P14. Distributed key protocol. The keys of confidential contracts are managed by a distributed protocol. P14. Distributed key protocol. P15. Key rotation protocol. The TEE replaces an old key with a fresh key for future contract encryption. P15. Key rotation protocol. P16. Independent contract key. Each contract is associated with a unique key, independent from the TEE. P16. Independent contract key. P17. Independent TEE key. Each TEE has a unique key, and different contracts share the same key. P17. Independent TEE key. Systematization summary. The system classification shows a general view of the TCSC systems. Desirable property focuses on evaluating contract service provided by a TEE-assisted blockchain system. Threat model describes the potential threats and system assumptions. Security considerations show the evaluating indicator for current TEE-assisted systems. In the following section IV-B and V-B, we attempt to answer the following questions: (i) What are the potential pitfalls in each security aspect; (ii) Do these pitfalls have significant security impacts; (iii) Do the designers/developers consider these pitfalls and accordingly come up with feasible remedies in their systems; (iv) What are the remedies and do they address above problems. Note that hundreds of TCSC systems have been proposed in both industry and academia. An exhaustive analysis is undesirable and infeasible. We only selected the projects that provide publicly accessible technical reports or academic papers. Systematization summary. system classification Threat model Security considerations 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.

Ethereum

What Most Blockchain Devs Get Wrong About TEE Security and Smart Contract Privacy

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

A Necessary Evolution of Privacy and Data Protection on Blockchain Networks

How Ola Recognizes the Urgent Need for Robust Privacy Across the Blockchain Space

My Take on Decentralized Government on the Aleo Blockchain

Remaining Anonymous on the Blockchain

This Startup Wants to Build a High Performance, Privacy-First Blockchain Platform

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

A Necessary Evolution of Privacy and Data Protection on Blockchain Networks

How Ola Recognizes the Urgent Need for Robust Privacy Across the Blockchain Space

My Take on Decentralized Government on the Aleo Blockchain

Remaining Anonymous on the Blockchain

This Startup Wants to Build a High Performance, Privacy-First Blockchain Platform

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps