Multimodal Cryptography Series – Accountable MPC + TEE

by Peyman Momeni, Co-Founder at Fairblock; Setareh Ghorshi, Cryptography Engineer at Fairblock; Zheng Leong Chua, Co-Founder at Automata Network

Intel SGX was breached. Have you found yourself wondering “what now?” Is there any point in using TEEs anymore? In this article, we will argue that there’s still a lot in store for TEEs and their viability for confidential computing solutions.

Let’s put the breach news on pause for a moment. Think about on-chain confidentiality schemes like Fully Homomorphic Encryption (FHE) and Identity-Based Encryption (IBE). In web3, these schemes rely on MPCs for key management and decentralization. In these MPC networks, a master secret key is distributed among the nodes and no single party has access to it. Once conditions for decryption are met, such as a specific block time, price, or computation, validators must extract private key shares and submit them on-chain for aggregation and decryption.

However, even though validators are economically incentivized to act honestly and not collude, 67% of them can theoretically coordinate a large attack that cannot be traced back to individual validators. Adding accountability to multi-party decryption means that if a set of parties collude to decrypt, their action can be caught. The consequences of such an attack are not normally loss of funds and safety, as the system will fall back to the current state of public chains. This property is very important in on-chain confidentiality schemes utilizing MPC.

The fewer nodes in the network, the more significant this problem will be. But on the other hand, having more nodes is costly and slow. So what can we do?

In this article, we will focus on a hybrid approach that does not solely rely on

$a)$ hardware security,

$b)$ any centralized party, or

$c)$ honest majority assumptions. While still efficient for web3 applications, the hybrid approach makes it practically impossible for validators to access their private key shares to collude in the first place. In future articles, we will review misbehavior tracing algorithms [1,2,3] and associated trade-offs to hold traitors accountable even if they manage to break hardware security and perform a large dishonest majority attack.

Trusted Execution Environments (TEEs)

Trusted Execution Environment (TEE) is a secure area within the memory and CPU of a device (computer or server), isolated from the rest of the system through encryption. Data inside the TEE is stored and processed in a protected environment, ensuring it cannot be accessed or altered by the untrusted components outside the TEE. Essentially, it functions like a secure processing unit for sensitive information.

By combining two confidentiality methods like MPC and TEE, we can create a hybrid solution that leverages their strengths while effectively minimizing each theoretical vulnerability. An interesting usage of such hybrid schemes is Scroll’s TEE Prover, where multiple types of TEEs are used to secure against potential bugs in ZK proving mechanisms. Automata’s Multi-Prover AVS on EigenLayer currently supports both Scroll and Linea.

SGX, TDX and Their Role

SGX and TDX are part of the Intel confidential computing technology portfolio. Getting back to the collusion problem in MPC networks, using SGX or TDX to store each validator’s secret ensures that they can’t collude with others, as they won’t have direct access to their secret value and can only use it within the SGX or TDX enclave. Moreover, since a minimum threshold of secret shares is needed to compromise the system, attacking a single SGX/TDX enclave won’t be enough to break it entirely.

SGX vs. TDX

SGX is a process-based confidential computing environment, whereas TDX is virtualization-based. Their differences lie in the size of the secure safe; SGX has a safe box that is only the size of the program whereas the TDX safe box is the size of the entire virtual machine (VM). This distinction means TDX has fewer performance and memory limitations compared to SGX. The size of TDX also makes developing on it much simpler as it encompasses the entire operating system (OS). That said, there is a tradeoff for the ease of development since we introduce additional trust assumptions with a larger Trusted Computing Base (TCB). Larger TCBs often mean more lines of code to maintain and secure, and more components that we need to be sure are correct.

Currently, SGX has been deprecated on consumer platforms but remains available on server processors. TDX can serve as a replacement for SGX due to its ease of development and performance.

SGX is still used by blockchain protocols like Secret Network and has potential applications in Fairblock. However, we are closely monitoring the security of SGX and are prepared to transition to other TEE technologies (beyond TDX) before any potential SGX vulnerabilities could compromise our network’s security. This is because if SGX breaks, TDX would be affected too.

At Fairblock, we can strengthen our threshold identity-based encryption – as well as threshold fully homomorphic encryption – by integrating TEEs into our MPC network to prevent collusion or key share leaks before the designated decryption time. TEEs enable the Fairblock network to securely store each validator’s share and extract the key shares. The rest of the operations like key aggregation and decryption do not need to rely on TEEs and happen outside them. This will reduce the overhead of using TEEs. For this purpose, the FairyRing client should operate within the TEE, ensuring key shares are submitted on-chain as needed, without any risk of tampering or leakage by validators. We have tested this process with SGX on Microsoft Azure servers and the initial results show a low overhead of around 8%, which can be further optimized.

Setting Up TEEs in Fairblock

Assuming we decide to use SGX in Fairblock, here’s how our validators can set it up:

SGX Setup Process

The first step is for the validators to enable SGX and install the required dependencies for the attestation process. The attestation process verifies the validity of the SGX and can be used as the first step for authorizing the validators during registration.

Binding a Key to the Quote

To bind a public key to the enclave, validators must include a hash of the public key as user data in the SGX attestation report. This process is detailed in the “Integrating Remote Attestation with Transport Layer Security”.

The user data (called REPORTDATA) is a 64-byte section within the quote’s body which can include custom data.

The quote’s signature covers this section, thereby cryptographically binding any data, such as a public key, to the quote.

Binding a public key, whose corresponding private key is only known within SGX, enables the verification of data coming from SGX. This public key allows for verifying the data coming from inside SGX if it includes a valid signature verifiable by that public key.

Registration

As mentioned, we need a registration process for validators to be attested and for their public keys (pk) to be used for encrypting their shares. The public and private keys are generated inside SGX. Verification and registration can occur on-chain by implementing a verification process for the quote, including the public key, and then storing the public key. Once this step is completed, any data with a correct signature can be trusted to originate from inside the SGX, as the private key is unknown outside it.

If a validator’s verification fails, they must be removed from the validator set. The public key can be updated by restarting the enclave and obtaining a new quote with a new public key.

Security Concerns

This section addresses the security implications of the previously discussed breach and assesses the robustness of our proposed hybrid solution.

Analysis of the Breach

Returning to the security breach mentioned earlier, let’s discuss whether our hybrid solution remains secure.

First, let’s examine the breach in detail. This attack leaks the Fuse Key0 (Root Provisioning Key) of SGX which is critical for its security. However, this attack primarily affects processors that are now End of Life (Apollo Lake, Gemini Lake, and Gemini Lake Refresh families). Not only that, the “keys” that were leaked are encrypted. Until and unless the Global Wrapping Key (GWK) that is used to protect the keys are leaked, the ciphertexts are just that, unusable ciphertexts.

The usage of a decentralized remote attestation workflow, as with Automata’s on-chain PCCS, also allows for the blacklisting of affected platforms at the first notice of such vulnerabilities before they are exploitable, mitigating the potential harm just like anyone would in a standard OPSEC process.

This was not the only attack on SGX/TDX. Over time, various attacks on TEEs have been discovered, often extracting sensitive information. For instance, Secret Network has been vulnerable to xAPIC and MMIO vulnerabilities, which could lead to the leakage of their private seed—a master decryption key for private transactions stored inside each validator’s SGX. While the Secret Network team took swift action by rotating the seed to enhance security, the privacy of past transactions cannot be fully guaranteed due to the nature of their protocol design. However, with Perfect Forward Secrecy, it’s possible that previous transaction data remains protected through the use of unique, ephemeral keys.

Resilience of the Hybrid Model

While TEEs are susceptible to attacks, the vulnerability is mitigated in our specific use case. In this hybrid setup, an attacker must compromise both the shared secret and individual TEEs to fully breach the system. This is analogous to TEE Committees introduced by Automata in their Multi-Prover system, which are maintained for liveness with cryptoeconomic guarantees. Even if a vulnerability exists in a TEE, the attacker would need to simultaneously break a threshold of TEEs to recover the secret and exploit the system.

Moreover, compromising one TEE does not automatically compromise all TEEs since they are not all running on the same server. Most attacks would require local access to each individual TEE and some even require physical access to the hardware (for instance Power Analysis or Fault Injection attacks). Note that there are a few attacks that can be performed remotely and do not require access to the TEE itself. However, this is not the case for the majority of the attacks.

Now, assume there is a vulnerability that can break a TEE. Examples of such vulnerabilities include address translation vulnerabilities, CPU cache vulnerabilities, DRAM vulnerabilities, branch prediction vulnerabilities, enclave software vulnerabilities, and hardware vulnerabilities. For these vulnerabilities to be exploited, the attacker would need some level of access to the TEE and the operating system it is running on. For instance, the attacker might need to run a code on the same server as the TEE enclave to perform the attack or access the shared hardware resources. This would require the attacker to either gain access to the system with the TEE or trick the user into executing malicious code on their system. Assuming users run the TEE on personal servers or use services like Microsoft Azure servers, the attacker would first need to gain access to the system and bypass the security controls to perform the attack on TEE.

If an attacker can break into a user’s system with an average probability (

$\rho$ ) and exploit the TEE to obtain the user’s share, to fully recover the master secret key, the attacker would need to break into at least (

$t$ ) servers where users run their TEE and extract their shares by repeating the attack on their TEE enclaves. The probability of at least (

$t$ ) successful attacks is given by:

$$p(\text{at least }t\text{ successful attacks})=\sum _{k=t}^n(\genfrac{}{}{0ex}{}{n}{k})\cdot {\rho }^k\cdot (1-\rho {)}^{n-k}$$

It is clear that as t increases, this probability will be significantly less than (

$\rho$ ). Therefore, it becomes more difficult to break the system.

A purely TEE-based approach without threshold cryptography could result in total system failure if a critical bug in the enclave exposes the secret and the attacker can gain access to even one TEE. Therefore, the hybrid approach offers a more robust security model, especially when considering real-world attack surfaces.

In our framework, each validator holds a share of the secret key stored inside their TEE. The system remains secure as long as fewer than a threshold number of these shares are leaked. However, if an attack compromises more than the threshold of validator enclaves, it could cause potential harm. To mitigate this risk, we periodically regenerate the shares to limit the attack window.

Exploring Alternative TEEs: Amazon Nitro Enclaves

SGX and TDX are well-known choices for TEEs, but they are not the only options. Another example is Amazon Nitro, which is less researched. Nitro enclaves, like TDX, are virtualization-based but can only be utilized on Amazon EC2 instances. Compared to SGX, Nitro Enclaves may offer better protection against side-channel attacks. However, they necessitate trust in AWS’s hardware and hypervisor, whereas SGX requires trust only in the enclave and CPU.

At Fairblock, we have the option to use Nitro Enclaves as needed for our scheme. Nitro also provides an attestation option, which is crucial for our use case. Therefore, our idea can be implemented using Nitro Enclaves without significant changes to the overall flow.

We can enhance the security of our system by allowing validators to use either SGX, TDX, or Nitro enclaves. This approach ensures that even if an attack is discovered on one type of enclave, not all validators would be vulnerable. However, this setup introduces challenges to the on-chain attestation process, as the attestation process for the Nitro and SGX enclaves are different. To address this, we can move the attestation process off-chain and only send and verify a simpler proof on-chain. That said, we need to perform further evaluations to determine the optimal structure and ensure the feasibility of this approach.

Conclusion

The strategic use of TEEs along with other on-chain MPC-based schemes results in decentralized onchain confidentiality schemes that are practically impossible to break. In our future articles, we will discuss tracing algorithms and their trade-offs as a way to hold each validator accountable even if they manage to break their TEEs and coordinate a large dishonest majority attack.

[1] "Traceable Secret Sharing: Strong Security and Efficient Constructions", https://eprint.iacr.org/2024/405
[2] "Traceable Secret Sharing and Applications", https://eprint.iacr.org/2021/871
[3] "Accountability for Misbehavior in Threshold Decryption via Threshold Traitor Tracing", https://eprint.iacr.org/2023/1724

About Fairblock

Fairblock Network delivers practical and compliant confidentiality across major blockchains. With a composable approach that allows us to plug confidentiality into existing chains, we've integrated with teams across EVM and IBC-connected chains to unlock impactful applications and make what’s possible online possible onchain.

About Automata Network

Automata is a machine attestation layer built by humans, designed for machines. TEE Coprocessors isolate computation in secure hardware for execution integrity and verifiable trust. Additionally, Automata’s Proof of Machinehood allows for machines to be provable on-chain.