| Proposal Title | Author | Phase | Type | Date Created |
|---|---|---|---|---|
| ShutterTEE | PolyCrypt GmbH | Proposal | Off-Chain | 20.06.2024 |
Summary
PolyCrypt GmbH proposes to strengthen the Shutter protocol through the trusted execution environment (TEE) capabilities of Intel’s SGX technology. This addresses one of the goals mentioned in the Shutter Roadmap. SGX is essentially a high-security black-box within the CPU that can prove correctness of computation and confidentiality of data, even against attackers that have full control over the operating system with full privileges. Using remote attestation, the TEE can prove that the expected code is running, thus Keypers can prove to users and to each other that they run the correct software, within a tamperproof black-box. Another important SGX feature used here is sealing: the ability to hardware-encrypt data for storage on disk so that only an approved executable can unseal it again, and only from within the protected context of SGX.
Our approach called ShutterTEE will run the core cryptographic components of the Shutter protocol inside a TEE, thereby providing an additional layer of security for the Shutter ecosystem. ShutterTEE offers two crucial security benefits:
- Collusion prevention: A shortcoming of threshold cryptography (as leveraged by Shutter) is that a collusion of up to t keypers can recover the secret key and decrypt shielded transactions prematurely. By running at least one Shutter Keyper inside a TEE enclave, we can guarantee that epoch keys are not prematurely released. We will guarantee interoperability between TEE Keypers and Keypers running on an unprotected machine.
- Compromise hardening: While TEEs are not unbreakable, they offer an additional layer of trust. In particular, most attacks against TEEs require that the operator/server running the TEE is behaving malicious and executes a sophisticated attack on the host system. By running the Shutter Keyper inside an enclave, it becomes significantly harder to compromise the Shutter ecosystem (For a discussion on hedging complex cryptographic protocols via TEEs see also https://ethresear.ch/t/2fa-zk-rollups-using-sgx/14462).
In the scope of this proposal, a proof of concept is built, and will be used for testing and refinement until the Shutter community decides to deploy the changes into production. The proof of concept modifies the Keyper software in these three ways:
- The permanent and epoch keys will be sealed (encrypted) via SGX, and only the authorized and unmodified Keyper node software, running securely in SGX can access and unseal (decrypt) them. This prevents intentional leaks or targeted hacking of Keypers, as even administrator-level access to a Keyper machine will not be able to reveal the secret keys. Using this principle, both the long-term keys, as well as the epoch keys are secured.
- We harden the mechanism that reveals the epoch keys after an epoch has ended, preventing any (intentional or when hacked) premature disclosure of the epoch decryption key. This is achieved by verifying the blockchain’s progression inside SGX and using the blockchain as a trusted source of time instead of relying on the Keyper’s own operating system time (which is easy to manipulate). Only when a block that is finalized on the blockchain with a timestamp that lies within a new epoch is witnessed, the previous epoch’s key is revealed. This ensures that as long as the blockchain’s timestamps are accurate, and the Keyper is unable to forge the consensus of the blockchain, the Keypers will not be able to release the decryption keys prematurely, thus preventing collusion.
- Keyper nodes can choose not to cooperate with nodes that do not run within SGX or do not run the correct executable. The Keypers prove to each other that they have the correct version of the official node software, and that it is running in the trusted execution environment. This feature is optional and will only be implemented in this Proof of Concept if time permits.
Milestones
Milestone 1: Run Keyper code in SGX (50%)
For the first milestone, we will modify the existing Keyper code so that it can run in an SGX. This includes checking if the libraries used will compile and work correctly, separate Keyper logic from any File I/O and other code that does not run inside an SGX, sealing the key material, and testing if everything still works. At this point the key material is protected from malicious code running outside of the TEE, but the Keyper still relies on a Full-Node TEE for any on-chain state including the current time.
Milestone 2: Verify integrity of on-chain data using the consensus mechanism (50%)
To function correctly the Keyper needs to know the current time and what happened on-chain. As long as the Keyper blindly trusts a Full-Node to give it the correct data, malicious code outside of the TEE could manipulate the Keyper into handing out key material prematurely. To prevent this attack vector, the TEE has to verify the consensus of the underlying ledger and check validity of all data (using merkle proofs). We have already written a significant part of this for our Erdstall Layer-2 solution, and hence, this milestone is mainly about modifying it to work with the data needed by Shutter and integrating it with the code from Milestone 1.
Motivation and Outlook
Currently, Keypers are not technically forced to obey the protocol and can reveal their master keys or the key shares for the next epoch before the scheduled time, either intentionally, or as the result of a cyber attack on their machine. SGX can be used to enforce honest and correct behavior, as well as data security even against administrator-level attackers. This proposal increases the trust of users in the honest operation and security of the Keypers.
Once the Keypers are trusted and secured, the foundation is laid to also fortify the sequencer of Rollup systems. Currently, there is a weak point where the sequencer fails to include some transactions which have been revealed (for example in case of high transaction volume). A future proposal would aim to employ similar hardening techniques to ensure that only transactions that get included on the Rollup chain are actually revealed. Thus, the current proposal is a prerequisite for strengthening MEV resistant rollups.
ShutterTEE also allows for two possible extensions that may be developed in follow-up projects:
- Slashing mechanism: ShutterTEE offers strong collusion prevention. Hence, if an epoch secret key share is released prematurely, it may be possible to develop a method for slashing malicious keypers that release their key share prematurely. While designing such a slashing mechanism is not part of this proposal, we believe that collusion prevention is an important first step towards this goal.
- Addressing the ``stuck in the mempool problem’’: Currently all transactions of an epoch get public when the epoch key is released even if the shielded transactions are still in the mempool (i.e., they have not been confirmed in a block yet). An easy extension of ShutterTEE allows to address this problem, where the decryption of the shielded transactions is done inside the TEE only if they are already part of a confirmed block.
Feasibility
PolyCrypt GmbH, a spin-off from the Technical University of Darmstadt, was founded by former members of the applied cryptography research group. The company specializes in developing Layer-2 solutions like State Channels for cross-chain and arbitrary contract execution, as well as Layer-2 solutions using Trusted-Execution-Environments (TEE). The ShutterTEE technology will re-use some of the tech-stack that was developed as part of Erdstall project (https://erdstall.dev/), which is an SGX-based Layer-2 solution.
Funding
- Milestone 1: $40k USDC + 200k SHU
- Milestone 2: $38k USDC + 150k SHU
