Inside the TCSC-Based Voting Protocol Powered by Intel SGX

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 D. A TCSC-BASED VOTING PROTOCOL In this part, we provide a detailed description of TCSCbased voting system that utilizes the Intex SGX. The protocol mainly consists of two sub-procedures: deployment stage and execution stage. We give details as follows. Deployment Stage. In the deployment stage, all the operational code and the initial state are coded into a TCSC. This stage includes two steps. Compile. Firstly, contract binary codes are compiled into enclave codes. Since an enclave has only a small quantity of trusted zones for application code and data (the protected memory is 128MB, and only 96MB is usable for an enclave in the current version of Intel SGX [88]), a contract has to determine the boundary of these zones and identify corresponding zones used for privacy-critical functionalities. In particular, the e-voting contract needs to define: the scope of secret states, the scope of public states, the approach to access secret states and the approach to access external states. Enclave Definition Language (EDL) [80] defines trusted components, untrusted components, and corresponding interfaces between them, which takes charge of translation from contract code to enclave code. It provides two functionalities: Enclave Calls (ECALLs) and Outside Calls (OCALLs). ECALLs define the functions inside the enclave that are used to expose APIs for untrusted applications to call in. OCALLs specify untrusted functions outside the enclave where the enclave code is able to invoke. In our example, the total number of votes cast for a candidate cannot be revealed until the voting has ended. Thus, the total number of votes cast is defined at the access point ECALLs, and is thereby hidden from the public, and can only be revealed once the voting procedure has been completed. Load. Afterwards, EDL files will load into an enclave, which is stored in the Enclave Page Cache (EPC). From a micro perspective, the first step is to call the ECREATE instruction for creating an enclave. This will allocate memory inside the Enclave Page Cache (EPC). Then, enclave code and data are added to pages in EPC by calling the EADD instruction. Finally, when the instruction EINIT completes successfully, an enclave’s INIT attributes become true, and the above instructions cannot be used any more. After a successful deployment, the initial state and operational code of this contract will be replicated among blockchain nodes. This means the e-voting logic cannot be changed. But, the state of functionalities can be transferred to parties who have been granted permission with a message-call [2]. Execution Stage. In the execution stage, voters call the deployed TCSC to finish the voting. Firstly, an enclave needs to fetch the current contract state from the blockchain. Then, the CPU executes the plaintext contract in the enclave mode. External attackers cannot obtain the knowledge of sensitive information since the Memory Encryption Engine (MEE) key never leaves TCB. A critical aspect of Intel SGX’s functionality is that the code inside an enclave can access the particular enclave state by performing additional checks on memory semantics. Back to our example, confidential state (the encrypted number of votes cast for a candidate) will return only when the following four requirements are fulfilled: The processor runs in enclave mode; The requested page is part of the same enclave; The page access is through a correct virtual address; The code semantics successfully pass the check. In a word, the CPU is acting as a doorman in the TCSC, providing a hardware-based access control mechanism. After obtaining results from TEEs, the consensus algorithm starts to reach an agreement. To be specific, when a miner receives a newly mined block, he will re-execute all transactions inside the block to obtain the newly transferred state. Once enough blockchain miners receive the block and re-execute transactions, the voting results and the transactions triggering the contract execution will eventually reach the final agreement. When all the voting procedures have ended, the teller can fetch the final encrypted state and obtain the final voting result. In the meanwhile, the transactions can be used as evidence to trace the voter’s behavior. 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.

Based on reporting by hackernoon.com.