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
APPENDIX C. BACKGROUND
Blockchain Technology. Blockchain, conceptualized by Nakamoto [100], was proposed as a distributed and appendonly ledger, in which all committed transactions are stored in a chain of data records (named as blocks). According to the initial idea of Bitcoin [1], when the blockchain maintainers reach an agreement on the newest block, related transactions appearing in that time will be packaged in this block and further stored in a distributed network to maintain a continuously growing list. By providing a secure solution to distribute the information and allowing all participants to audit the shared records, blockchain obtains many key characteristics such as decentralization, auditability and nonrepudiation, transparency, and non-equivocation.
Smart Contract Proposed by Szabo [1], the smart contract are widely applied in blockchain systems by Ethereum [2]. Blockchain-based smart contracts adopt Turing-complete scripting languages to achieve complicated functionalities [6] and execute thorough state transition/replication over consensus algorithms to realize final consistency. By the design, a blockchain-based smart contract includes multiple functions, methods, and a few parameters that can run on the blockchain when specific conditions or events are met and encompass business logic and transactions between two or more parties. To be specific, the source code of a contract forming as part of a transaction is first sent to the blockchain. Once the transaction is included in a new block and confirmed by the majority of the participants, the contract code becomes immutable and executable. When an external user invokes the contract, the state will be updated under the instruction of the preloaded source code. The neutrality of the execution
environment among all blockchain nodes facilitates the same execution result of the program code. Smart contracts thus enable unfamiliar and distributed participants to fairly exchange without trusted third parties and present a uniform approach to improve applications across a wide range of industries.
Trusted Execution Environments. Trusted Execution Environment (TEE) [29] provides a protected processing area in the main processor that runs on a separation kernel to ensure confidentiality and integrity of inside data and computations. State-of-the-art implementations include Intel Software Guard Extensions (SGX) [80], ARM TrustZone [89], Keystone [28], etc. For a TEE, three main TEE features are highlighted, including runtime isolation, sealing technologies and attestation technologies. For simplicity, we use Intel SGX as an example to explain these features in the following paragraphs. It has to be mentioned that the Intel SGX design used in our paper can also be implemented on other trusted hardware platforms such as Keystone [28].
Runtime Isolation. The secure and isolated regions of memory are called enclaves. Sensitive data and intermediate computations run inside enclaves to provide protection against outside programs. Besides, all the runtime enclave memories are stored in Enclave Page Cache (EPC) [101] and encrypted by Memory Encryption Engine (MEE). These protective mechanisms enforced in SGX protect memories against the access of any process outside the enclave itself, including the operating system, hypervisors, etc.
Sealing. Sealing [88] is a process of loading enclave internal secret state to persistent storage. Roughly speaking, using the Sealing, the secrets can be encrypted and stored in the untrusted memory or disk. Further, it allows such encrypted secrets to be retrieved once the enclave is torn down (either due to the host’s power or the application itself). Sealing is achieved by using a private seal key [80], which covers two types of identities: Enclave Identity and Signing Identity. Enclave Identity is represented by the value of MRENCLAVE, which is a cryptographic hash of the enclave measurement. Any operation inside an enclave that changes measurement will yield a different key. Thus, it restricts the permission to sealed data; only the corresponding enclave can access the sealed data. In contrast, Signing Identity is provided by an authority and represented by MRSIGNER. It provides the same sealing key for different enclaves, or even different versions of the same enclave. Therefore, Signing Identity can be used to share sensitive data between multiple enclaves produced by the same development firm.
Attestation. Attestation mechanism [33] is used to prove to a validator that an enclave has been correctly instantiated and when in that condition can then proceed to further establish a secure, authenticated connection for the data transmission. SGX provides two types of attestation: local attestation and remote attestation. In the former attestation, SGX facilitates the instructions to help an enclave to attest to another enclave on the same platform. In the latter one, SGX enables an enclave to prove a correct loading of code and data to another enclave that resides in a remote platform.
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.
