Achieving superior blockchain security with SGX and ZK proofs

06/11/2023

Including fatal SGX vulnerabilities and ways to solve them with technolgies like zero-knowledge proofs or full-homomorphic encryption.

INTRODUCTION

The realm of blockchain technology and cryptographic security continually evolves, with innovations such as ZK-Rollups, circuits, and SNARKs at the forefront of this transformation. However, the complexity and relative immaturity of these technologies pose risks, including potential bugs and security vulnerabilities. A strategic approach to mitigating these risks involves the adoption of a multi-prover system. This system leverages a variety of proof types (like validity proofs and fraud proofs), different proving systems (e.g., SNARK and STARK), and distinct implementations crafted by diverse teams. Such a multi-layered approach significantly enhances the security and robustness of blockchain networks.

This article unfolds in five critical parts: Firstly, we delve into the essence of the multi-prover strategy, exploring its components beyond just the proving system. Secondly, we illuminate the concept and mechanics of SGX (Software Guard Extensions) as a form of validity proof and examine its role as a reliable addition to cryptographic and economic frameworks. Then, we elucidate how the multi-prover system functions within nodes and smart contracts, particularly focusing on its application in rollups. Equally, we dig deeper into some common and critical vulnerabilities of SGX. Finally, we compare how ZK and FHE can indeed complement this technology for it to be applicable widely in the blockchain space.

WHY MULTI-PROOF MATTERS IN BLOCKCHAIN SECURITY

Challenges in Current Technologies

Blockchain technologies, especially those involving complex constructs like ZK-EVM circuits, are inherently intricate and laden with thousands of code lines. This complexity inevitably leads to a longer path towards achieving a bug-free environment. The risks are manifold — spanning across the proving systems, circuit compilers, and the ZK-EVM code itself.

Moreover, the cryptographic primitives underpinning ZK-Rollups, predominantly SNARKs, are relatively new. Their novelty brings an inherent uncertainty in terms of undiscovered vulnerabilities within the proving systems themselves.

The Multi-Prover Solution

In response to these challenges, the multi-prover approach offers a resilient safety net. This strategy involves generating several types of proofs for a single block. Consequently, even if one proof type is compromised, the presence of others obstructs the exploitation of the same vulnerability. In scenarios where a particular proof type fails to validate a block, the multi-prover system’s design could lead to a temporary halt in the chain’s operations, contingent on the acceptance criteria set for validating a block. This additional layer of requiring diverse proof types significantly elevates the overall security.

Disclaimer: Henceforth, our reference to “multi-prover” encapsulates the diversity in proof types.

A Conceptual Analogy

To better grasp the concept of a multi-prover system, we can draw a parallel with the client diversity in Ethereum’s network. This diversity allows Ethereum to withstand and recover from partial network failures. As Vitalik Buterin articulates in his discourse, Ethereum’s approach to using multiple clients is a form of decentralization that brings both technical and social benefits. These benefits range from architectural diversity to the prevention of power centralization within the network’s operational team.

Similarly, the multi-prover philosophy in Rollups champions both technical and social advantages. Technically, it encompasses varied proving systems, architectural designs, and implementations. Socially, it promotes a distribution of power, ensuring that no single entity holds disproportionate influence within the blockchain infrastructure.

DIVERSIFIED CONSTRUCTION OF MULTI.PROVER SYSTEMS

The architecture of a multi-prover system is inherently diverse, incorporating various elements that collectively fortify the blockchain against a myriad of vulnerabilities.

Variety in Proof Types

Multi-prover systems don’t just hinge on a single type of proof. They amalgamate different kinds, such as:

- Fraud Proofs: Commonly utilized in optimistic rollups, these proofs operate on fundamentally different principles compared to validity proofs, greatly reducing the likelihood of correlated vulnerabilities.
- Validity Proofs: Typically seen in zk-rollups, these proofs are based on different computational assumptions and methodologies.
- Innovative Proving Systems like SGX: As a less conventional but emerging option, SGX (Software Guard Extensions) provides an additional layer of security. We’ll explore SGX in greater detail later in this article.

Multiple Proving Systems

The multi-prover framework isn’t just about using different types of proofs; it’s also about employing varied proving systems. For instance, in the context of zk-rollups, both SNARK and STARK backends can be utilized. The dual-use of these systems not only introduces redundancy but also mitigates the risk of systemic failures in any single proving system.

Diverse Implementations by Varied Teams

A robust multi-prover approach involves different teams working on separate implementations. This diversity significantly reduces the risk of a universal bug affecting the entire network, as the likelihood of different teams making identical errors in their code is minimal.

Addressing the Risks of Broken Proofs

In a multi-prover ecosystem, the possibility exists that different proof types may yield conflicting results for the same block. This situation necessitates an understanding of two key properties of proofs: completeness and soundness.

- Completeness Issues: If a proof for a valid block cannot be generated, it implies a breakdown in completeness. In such scenarios, depending on the blockchain’s design (e.g., the number of required proofs), the entire chain might temporarily halt.
- Soundness Concerns: This arises when multiple proofs for a valid block result in different block hashes. Ideally, only the proof for the correct blockhash should be possible. If the same vulnerability impacts multiple proof types, leading to the submission of incorrect blockhashes, the integrity of the multi-prover system could be compromised.

To address these risks, especially when using two types of proofs, a multi-sig governance mechanism can serve as an emergency resolution method. This entity would determine the correct blockhash and take necessary actions (like updating or excluding the faulty proof type). The decision-making in scenarios involving more than two proof types might hinge on a majority consensus regarding the validity of the proofs, followed by corrective measures against the erring proofs.

UNDERSTANDING SGX AND ITS ROLE IN BLOCKCHAIN

What is SGX?

SGX, or Software Guard Extensions, represents a significant stride in the domain of secure computing. Developed by Intel, SGX is a set of security-related instruction codes that enable the creation of protected memory spaces, known as enclaves.

How SGX Works

At its core, SGX allows for the establishment of enclaves, which act as fortified, isolated compartments within a processor. These enclaves are designed to be a secure space where code and data can be kept protected from external threats, including those originating from the system’s own operating system.

In blockchain applications, SGX can be a game-changer, particularly for private smart contracts. For instance, running an oracle within an SGX enclave can enhance privacy and security, providing proof of data integrity without revealing the data itself.

Secure remote computation. A user relies on a remote computer, owned by an untrusted party, to perform some computation on her data. The user has some assurance of the computation’s integrity and confidentiality

SGX’s Structure and Key Components

- Trusted Computing Base (TCB): This encompasses the hardware, firmware, and software essential for creating a secure computing environment.
- Hardware Secrets: Such as the Root Provisioning Key (RPK) and Root Seal Key (RSK), which are integral to the hardware’s secure operations.
- Attestation Mechanisms: These are crucial for verifying the integrity and security of the code running within the enclaves. SGX offers two attestation forms: local and remote. Local attestation is used within the same trusted computing base, whereas remote attestation allows external entities to verify the enclave’s integrity.

Software attestation proves to a remote computer that it is communicating with a specific secure container hosted by a trusted platform. The proof is an attestation signature produced by the platform’s secret attestation key. The signature covers the container’s initial state, a challenge nonce produced by the remote computer, and a message produced by the container

Challenges and Limitations of SGX

Despite its robust design, SGX isn’t without its challenges. Trusting Intel’s hardware and the security of the SGX technology itself can be seen as a potential risk. Furthermore, the complexity and novelty of SGX mean that its reliability in various attack scenarios is still an evolving area. Security in SGX also doesn’t exist in isolation and often needs to be supplemented with other cryptographic methods or economic incentives for a well-rounded defense strategy.

SGX DOUBTS, CONSTRAINTS, AND WEAK POINTS

1. Trust in the Technology and Provider

Utilizing SGX necessitates a degree of trust in Intel, the technology’s creator. This trust extends to the belief that the SGX technology is robust against various attack vectors and that Intel will be responsive in patching new vulnerabilities as they emerge. However, skepticism remains, especially given the history of delay in addressing known SGX attacks. Furthermore, Intel’s decision to deprecate SGX in consumer CPUs in 2021 raises questions about its long-term viability and support.

2. The Newness of the Technology

SGX, being relatively new, is still under scrutiny regarding its overall reliability. The lack of extensive real-world testing and understanding of potential attack vectors means that the full spectrum of its security capabilities is yet to be established.

3. Security Beyond the Hardware

While SGX provides a secure hardware environment, it isn’t a standalone solution for all security needs. To build a comprehensive security model, SGX should be integrated with other cryptographic methods such as Multi-Party Computation (MPC), Zero-Knowledge Proofs (ZKP), Fully Homomorphic Encryption (FHE), and Oblivious RAM (ORAM). Balancing SGX’s technical strengths with economic incentives and other security mechanisms can create a more resilient overall system.

4. High-level CPU Diagram

Random Access Memory (SRAM) cells, generally known as registers, which are significantly faster than DRAM cells, but also a lot more expensive. An instruction performs a simple computation on its inputs and stores the result in an output location. The processor’s registers make up an execution context that provides the inputs and stores the outputs for most instructions. For example, ADD RDX, RAX, RBX performs an integer addition, where the inputs are the registers RAX and RBX, and the result is stored in the output register RDX. The registers mentioned in Figure 6 are the instruction pointer (RIP), which stores the memory address of the next instruction to be executed by the processor, and the stack pointer (RSP), which stores the memory address of the topmost element in the call stack used by the processor’s procedural programming support. Under normal circumstances, the processor repeatedly reads an instruction from the memory address stored in RIP, executes the instruction, and updates RIP to point to the following instruction. Unlike many RISC architectures, the Intel architecture uses a variable-size instruction encoding, so the size of an instruction is not known until the instruction has been read from memory. While executing an instruction, the processor may encounter a fault, which is a situation where the instruction’s preconditions are not met. When a fault occurs, the instruction does not store a result in the output location. Instead, the instruction’s result is considered to be the fault that occurred. In a nutshell, the processor first looks up the address of the code that will handle the fault, based on the fault’s nature, and sets up the execution environment in preparation to execute the fault handler. Each device attached to the bus decodes the operation codes and addresses of all the messages sent on the bus and ignores the messages that do not require its involvement. For example, when the processor wishes to read a memory location, it sends a message with the operation code READ-REQUEST and the bus address corresponding to the desired memory location. The memory sees the message on the bus and performs the READ operation. 6 At a later time, the memory responds by sending a message with the operation code READ-RESPONSE, the same address as the request, and the data value set to the result of the READ operation. The computer communicates with the outside world via I/O devices, such as keyboards, displays, and network cards, which are connected to the system bus. Devices mostly respond to requests issued by the processor.

A processor fetches instructions from the memory and executes them. The RIP register holds the address of the instruction to be executed.

EXISTING BLOCKCHAIN IMPLEMENTATIONS WITH SGX

1. Development Tools and Frameworks

To facilitate the integration of SGX into blockchain applications, several Software Development Kits (SDKs) and libraries are available, including Intel’s SGX SDK, Open Enclave, Rust SGX, Teaclave, and others. For existing applications that need to run in isolated environments without significant code modifications, library Operating Systems (libOSes) like Gramine, Occlum, and EGo have been developed. These provide a Linux-like abstraction layer, helping to adapt applications to secure enclave environments.

2. Pioneering Efforts in Blockchain

Organizations like Flashbots and Nethermind have been at the forefront of exploring SGX within the blockchain space. One notable application is running Ethereum’s Geth client inside an SGX enclave. Though feasible, this approach presents challenges, including high memory requirements, long startup times, and potential information leakage risks.

How the memory is handled with SGX:

The virtual memory abstraction gives each process its own virtual address space. The operating system multiplexes the computer’s DRAM between the processes, while application developers build software as if it owns the entire computer’s memory.

3. Block Building and Transaction Privacy within SGX

Another critical application of SGX in blockchain is in the area of private transactions and decentralized block building. By running the block-building process within SGX enclaves, the contents of user transactions can be kept private, and the block construction can be done in a verifiable manner. However, challenges such as managing the large state size of blockchain databases and the additional performance overheads remain topics of active research and development.

Applying SGX to Rollups:

SGX’s application to rollups brings promising possibilities, particularly in verifying the correctness of block execution. In rollups, the verification process can be rendered stateless: the program inside the SGX enclave receives only the necessary data (like the state root, transaction list, and block parameters) as input. It then verifies these inputs against the expected output, ensuring the integrity of the block execution.

This method aligns well with the principles of zero-knowledge proofs, where direct access to the state isn’t possible. The SGX enclave thus serves as a trusted component that can attest to the correctness of a block’s execution, adding another layer of security and integrity to the rollup process.

Multi-Prover in a Rollup Setting

In the context of rollups, implementing a multi-prover system requires the participation of nodes dedicated to proof generation. These nodes gather necessary data such as transactions, state accesses, and Merkle proofs. The generation of zk-based proofs might be resource-intensive and time-consuming, whereas SGX-based proofs can be quicker and less resource-demanding.

Once generated, these proofs are submitted to the rollup smart contract collectively, ensuring that all required proofs are available for verification. The contract then checks each proof for correctness. In the case of zk proofs, this involves running a verifier algorithm; for SGX proofs, it might be as simple as verifying an ECDSA signature. The final step is to ensure that all proofs agree on the same blockhash, confirming the block’s validity and marking it as proven on the chain.

STRATEGIC INTEGRATION OF SGX WITH ECONOMIC INCENTIVES

1. SGX and Economic Incentives: A Balanced Approach

When considering the security model of blockchain systems, a nuanced approach that combines the technical assurances of SGX with the strategic application of economic incentives is vital. SGX, with its hardware-based encryption and isolated execution environments, offers a robust defense against many attack vectors. However, its effectiveness can be further enhanced when used in conjunction with well-designed economic incentives.

2. Complementing SGX with Economics

The integration of SGX with economic models needs to consider various scenarios:

- High-Risk Situations: In instances where economic models face extreme stress or breakdown (e.g., market crashes or systemic financial failures), SGX’s technical security can provide a stable defense line, independent of economic fluctuations.
- Prevention of Exploits: SGX alone, while formidable, can still be susceptible to sophisticated attacks. Therefore, pairing SGX with economic deterrents (like high costs for attempting security breaches) can enhance overall system resilience.

WSGX in Blockchain: Beyond the Ideal

While SGX presents an impressive array of features for enhancing blockchain security, it’s crucial to acknowledge that it isn’t a panacea. The complexity and evolving nature of SGX mean that it should be part of a broader strategy incorporating other security measures and techniques. For instance, combining SGX with different cryptographic primitives and economic models can help create a more well-rounded and formidable security framework.

UNDERSTANDING INTEL SGX VULNERABILITIES IN DEPTH

Understanding SGX and Its Operational Model

Before diving into the vulnerabilities, let’s understand the basic functioning of SGX. SGX allows applications to create protected areas in memory, called enclaves, which are designed to be resilient to attacks from both the operating system and the hardware. The cornerstone of SGX is its promise that code and data loaded in the enclave are protected and cannot be seen or modified from outside the enclave.

1. Exploiting Side Channels: A Pathway to Breaching SGX

Side-channel attacks have emerged as a potent threat to SGX, exploiting indirect paths to glean sensitive information. These attacks typically observe variations in physical parameters like execution time or power consumption to infer data or cryptographic keys.

a. Cache Attacks:

Cache attacks like Prime+Probe and Flush+Reload target the processor’s cache. By monitoring cache access patterns, an attacker can deduce the data being processed inside the enclave, thus compromising the confidentiality guaranteed by SGX.

A malicious OS can partition a cache between the software running inside an enclave and its own malicious code. Both the OS and the enclave software have cache sets dedicated to them. When allocating DRAM to itself and to the enclave software, the malicious OS is careful to only use DRAM regions that map to the appropriate cache sets. On a system with an Intel CPU, the the OS can partition the L2 cache by manipulating the page tables in a way that is completely oblivious to the enclave’s software.

b. Branch Prediction and Speculative Execution Attacks:

These attacks exploit the CPU’s branch prediction and speculative execution features to access protected memory areas. Notable examples include Spectre and Meltdown, which have also been adapted to target SGX enclaves.

c. Page Fault Attacks:

By inducing and observing page faults, attackers can figure out the access patterns inside the enclave, thereby inferring the data being processed.

2. Specific Vulnerabilities in SGX: xAPIC and MMIO

The xAPIC and MMIO vulnerabilities, as exposed in the Secret Network incident, are particularly concerning.

a. xAPIC Vulnerability:

This vulnerability arises from a flaw in the Advanced Programmable Interrupt Controller (xAPIC) that allows an attacker to infer the data being accessed inside the enclave. By manipulating and observing the interrupt handling mechanisms, sensitive data like the consensus seed in the Secret Network can be extracted.

b. MMIO Vulnerability:

Memory-Mapped I/O (MMIO) attacks exploit the SGX design’s handling of certain memory-mapped I/O regions. Attackers can potentially gain unauthorized access to enclave memory, leading to data leakage.

3. Real-World Impact and Mitigation Efforts

The real-world implications of these vulnerabilities are far-reaching. The Secret Network’s compromise and the potential extraction of AACS2 keys in PowerDVD are testaments to the threats posed by these SGX vulnerabilities.

Mitigating these vulnerabilities often involves firmware and microcode updates, which can be challenging to deploy due to their reliance on BIOS updates, leading to a slow and cumbersome patching process.

4. The Challenge of Patching SGX

Patching SGX vulnerabilities is not straightforward. Each update must be carefully tested to ensure it doesn’t inadvertently introduce new vulnerabilities or impact the performance or functionality of the system. The delay in deploying these updates can leave systems vulnerable for extended periods.

5. The Future of SGX Security

The ongoing discovery of SGX vulnerabilities necessitates a re-evaluation of the trust placed in enclave-based security models. While Intel and other stakeholders have been actively addressing these vulnerabilities, the evolving nature of side-channel attacks means that a single solution is unlikely to be sufficient.

ENHANCING INTEL SGX SECURITY WITH ZERO-KNOWLEDGE PROOFS AND HOMOMORPHIC ENCRYPTION

ZERO-KNOWLEDGE PROOFS (ZKPs) ADDRESSING SGX SHORTCOMINGS

ZKPs, a cryptographic method that enables one party to prove to another that a statement is true without revealing any information beyond the validity of the statement itself, can complement SGX in several ways:

1. Enhancing Privacy Against Side-Channel Attacks:

- Mitigation Strategy: ZKPs can verify the correctness of a computation (like a smart contract execution) without revealing the input or internal state. This method counters specific side-channel attacks that target the data or the state of computations within SGX.
- Use Case Example: In blockchain, a ZKP could validate a transaction’s correctness processed within an SGX enclave without exposing the transaction’s details, thus maintaining transaction confidentiality despite SGX vulnerabilities.

2. Building Trust Despite Vulnerable Environments:

- Trustless Verification: ZKPs enable external validation of data processing in SGX enclaves, building trust even if the enclave itself might be compromised.
- Blockchain Integration: For blockchain networks, ZKPs can ensure the integrity and correctness of off-chain computations done within SGX enclaves, crucial for maintaining consensus and trust.Fully Homomorphic Encryption (FHE): A Complementary Shield

FULLY HOMOMORPHIC ENCRYPTION (FHE): A COMPLIMENTARY SHIELD

FHE allows computations to be performed on encrypted data, and the results of these computations remain encrypted. FHE can address some of SGX’s vulnerabilities:

1. Securing Data in Use:

Protection Mechanism: Even if attackers bypass SGX protections, the data, if encrypted using FHE, remains secure as they cannot decrypt it without the corresponding keys.
Blockchain Application: Storing encrypted blockchain states or smart contracts and allowing computations (like transaction processing) in their encrypted form enhances security and privacy.

2. Extended Security Boundaries:

Data Security Outside Enclaves: FHE keeps data encrypted during processing outside the SGX enclave, mitigating risks related to data exposure in untrusted parts of the system.
Blockchain Scenarios: Blockchain nodes leveraging SGX can perform certain computations on encrypted data (e.g., transaction validation) without decrypting it, reducing the attack surface.

PRACTICAL INTEGRATION IN BLOCKCHAIN AND CRYPTOGRAPHY

Integrating ZKPs and FHE with SGX in blockchain systems must consider the complexity and performance overheads. Implementing such systems requires a deep understanding of cryptographic primitives, SGX architecture, and blockchain protocols.

Implementing ZKPs with SGX:

Designing ZKP Protocols: Choose ZKP types (e.g., SNARKs, STARKs) based on the trade-off between setup requirements, proof size, and computational overhead.
Integration with SGX: Develop SGX enclaves to generate or verify ZKPs. Ensure that enclave’s code is optimized to mitigate known side-channel attacks during ZKP computation.

Utilizing FHE alongside SGX:

Selecting FHE Schemes: Pick suitable FHE schemes that balance between encryption strength and computational efficiency.
SGX-FHE Workflow: Design workflows where data is encrypted via FHE outside SGX, processed within the enclave, and results are sent out still encrypted.

FUTURE DIRECTIONS AND EMERGING TRENDS

1. Advancements in Technology and Security

he blockchain landscape is continually evolving, with new technologies and security challenges emerging regularly. SGX, as part of this landscape, will also evolve, addressing current limitations and adapting to new threats.

2. Holistic Security Strategies

Future blockchain implementations will likely adopt more holistic security strategies, integrating SGX with other advanced cryptographic methods and adapting to changing economic and technical environments. This approach ensures that blockchain systems remain resilient against a broad spectrum of threats, both known and unforeseen.

CONCLUSION

The article dug deep into the intricate world of multi-prover systems in blockchain, highlighting their significance, operational mechanisms, and the role of SGX within this framework. The multi-prover approach, by leveraging a diversity of proofs, proving systems, and implementations, significantly enhances the resilience and security of blockchain networks. SGX, with its ability to create secure and isolated execution environments, adds a valuable dimension to this approach, particularly in the context of private smart contracts and rollup verifications.

However, the journey towards achieving a foolproof blockchain security model is ongoing. The continuous evolution of threats and technologies necessitates an adaptable and multi-faceted security strategy, where innovations like SGX are integrated thoughtfully with other cryptographic techniques and economic models. As blockchain technology matures and faces new challenges, the integration of these diverse yet complementary elements will be crucial in building robust, secure, and trustworthy systems.

In conclusion, while the multi-prover strategy and tools like SGX significantly fortify blockchain systems, the search for impenetrable security continues.

Pentestify is committed to ensuring that the new web3 world thrives in abundance by making sure that web3 companies stay resilient throughout their lifecycles, iterations, and even attacks, and we believe it is not possible without continuous smart contract security resilience.