TL;DR;

White-hat academic researchers just published the Wiretap.fail and Battering Ram attacks that can expose confidential data from certain Intel SGX systems. Attacks require physical access to SGX servers. The researchers demonstrated their attack on Secret Network, Phala, Crust Network and IntegriTee.
Secret Network implemented proactive measures to mitigate the vulnerability in our recent 1.22 upgrade. According to wiretap.fail, Secret Network is the only project that implemented such proactive measures.

This is not a Secret Network vulnerability, but an Intel SGX vulnerability that affects certain processor models.

Data is safe. Funds are safe. Details below.

Recent Disclosures

Earlier today, Intel publicly disclosed a vulnerability report based on independent work by two white-hat academic researcher teams: WireTap: Breaking Server SGX via DRAM Bus Interposition, as well as Battering Ram (currently only in Dutch).

Using physical access to an SGX machine, and by employing special measurement equipment, the attack allows generation of forged attestation, so any code can pose as a legitimate SGX enclave. The attack is only possible if the attacker has physical access to the machine.

The Wiretap researchers performed attacks on Secret Network, Phala Network, Crust Network and IntegriTee, extracting sensitive data. On Secret Network, the researchers used the vulnerability to create a forged Testnet enclave that posed as a legitimate Secret Network Testnet enclave and was able to access confidential data.

On Secret Network, the attack can only put data privacy at risk. It cannot affect any funds.

Secret Network Privacy is Safe

The researchers are part of academia and adhere to academic ethical standards. We got explicit assurances from them that they did NOT extract any confidential information from Secret Mainnet. All attacks were performed on the Secret Testnet, and only on Testnet.

Affected Systems

The attack only affects Intel Xeon 3rd Gen Scalable Processors.

According to Intel disclosure, such attacks are outside the scope of the boundary of protection.

Our Mitigation

We implemented three critical protections against these and similar attacks in the recent 1.22 upgrade:

1. Network Access Control: We suspended the acceptance of new nodes to the network. Even if an attacker creates a forged attestation, they would not be able to join the Secret Network and put our confidential data at risk.
   
   
   

2. Trusted Node Allowlist: We established a curated allowlist of known and trusted nodes, including our validators, RPC nodes, and other critical network infrastructure.
   
   
   

3. Network Seed Rotation: we changed the seed to mitigate an extremely unlikely event that someone other than the researchers discovered the same technique and could extract the network seed. We have no evidence that it happened, but we chose caution.

From what we know at the moment, Secret Network is the only project that took proactive measures to protect from this vulnerability.

Next steps

We already started working on version 1.23 that will include the following:

1. Allowing new nodes to be added to the network through  Governance approval

2. Allowing any Azure nodes to join the network without Governance approval. More CSPs may be added in the future (see below)

3. Detection of end-of-life (EOL) hardware. More on this in separate communications in a few days.

We value the permissionless nature of Secret Network and will strive to reach the right balance between security and permissionless nature of our network.

We will be issuing separate communications about the proposed changes to be discussed and approved by the community.

Longer-term mitigations

In the mid-term and long-term we see the following mitigations to this particular vulnerability:

1. Proof-of-cloud: A viable approach to mitigate this vulnerability is to validate that nodes are operating from within known cloud providers and thus cannot be susceptible to physical attacks. This can be achieved by relying on custom Attestation Authorities. Currently, Microsoft Azure, Google Cloud Platform and IBM Cloud are the only cloud providers that offer custom Attestation Authorities that guarantee that a given machine is located in a secure data center. We already plan to support Azure in release 1.23, and we will be considering adding more cloud providers in the future.

Also, we will explore working with other cloud providers outside Azure, Google and IBM to introduce custom Attestation Authorities to them, working together with other players in the industry.

2. Patching the vulnerability: At the moment, Intel claims that the vulnerability is outside of scope. We are looking for ways to develop patches for this vulnerability, including hardening of the Quoting Enclave and Provisioning Certification Enclave. This is a complex and high-risk task and we will approach it accordingly, and strive to work with the industry on that.

3. Hardware Solutions - Intel may offer protection from such attacks in their future products, but we aren’t currently aware of any specifics

Moving Forward 

Secret Network remains safe, resilient, and forward-looking. While no mainnet data or funds were at risk, we are treating this disclosure as an opportunity to further harden our infrastructure and set new standards for confidential computing. By collaborating with academia, industry, and our community, we will continue to address vulnerabilities, pursue long-term mitigations, and lead the evolution of trusted execution technologies. We invite all validators, developers, and community members to take part in the upcoming governance proposals and discussions. Together, we will ensure that Secret Network stays secure and inclusive