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

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

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

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

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. The property of confidentiality is the most distinguished feature in TCSC.

A1. Specification hidden. The source code of a smart contract is hidden during the deployment and the subsequent synchronization and execution.

A2. Input privacy. The inputs fed into a confidential smart contract are hidden from the public.

A3. Output privacy. The outputs returned from a confidential smart contract should be kept private.

A4. Procedure privacy. The execution procedure is hidden from unauthorized parties. An adversary cannot learn the operation knowledge inside a TEE.

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.

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

Blockchain intrinsic feature. TEE-assisted smart contracts inherit features given by original blockchain systems. We summarize these features as follows.

A7. Code immutability. Once a contract is successfully deployed, its source code cannot be altered.

A8. (Confidential) state consistency. Executions happening at a certain blockchain height will output the same result across different nodes.

A9. Contract interoperability. A smart contract can call another contract and be called by others.

A10. High availability. A smart contract is continuously accessible without the single point of failure.

A11. Decentralized execution. A smart contract runs over the decentralized network.

A12. Automatic execution. A smart contract can be automatically executed once conditions are satisfied.

A13. Gas mechanism. Operations running on the smart contract will be charged with gas fees [2].

A14. Explicit invocation. Each invocation will be formatted as a transaction and stored on blockchain.

A15. Public verifiability. The procedure of contract execution and result are publicly verifiable.

A16. Consensus verifiability. The consensus procedure on the (confidential) state is publicly verifiable.

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.

Threat model. Our threat model mainly captures three types of attackers, which are stated as follows.

T1. User adversary (active/passive). An attacker may control network between users and TEE host nodes.

T2. TEE adversary (active/passive). An adversary may control TEE hosts or control the network between TEE and blockchain platforms.

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.

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.

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.

P1. Host punishment mechanism. Penalty mechanisms to reduce the risk of doing evil by a TEE host.

P2. Host incentive mechanism. Incentive mechanisms to promote a TEE host to behave honestly.

P3. Host fault tolerance. Solutions to make systems continually operate despite malfunctions or failures.

P4. Host authentication. Methods to check the identity and the capability of a TEE host.

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.

P5. TEE attestation security. Methods to prevent TEE attestation service from being abnormally broken.

P6. TEE memory limitation. Methods to optimize the memory size to prevent confidential data overflow.

P7. TEE physical attacks. Approaches to prevent physical attacks, such as the Spectre vulnerability or the Meltdown vulnerability [57].

P8. TEE trusted timer. Approaches to provide a trusted timer when running a TEE.

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.

P9. Workload measurement. The workload measurement approach to prevent an infinite loop attack.

P10. Flaws detection. Formal techniques used for the modelling and verification of the source code of smart contracts to reduce the vulnerabilities.

P11. User query restriction. The restriction on users’ queries, aiming to avoid data leakage resulting from differentialprivacy analysis [58].

P12. Blockchain data confirmation. Methods for a TEE to check whether input data from blockchain has been confirmed to prevent the rollback attack [59].

P13. TEE output conflicts. Methods to avoid multiple TEEs to produce a conflict result.

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.

P14. Distributed key protocol. The keys of confidential contracts are managed by a distributed protocol.

P15. Key rotation protocol. The TEE replaces an old key with a fresh key for future contract encryption.

P16. Independent contract key. Each contract is associated with a unique key, independent from the TEE.

P17. Independent TEE key. Each TEE has a unique key, and different contracts share the same 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.