Intel's Software Guard Extension (SGX) promises an isolated execution environment, protected from all software running on the machine. In the past few years, however, SGX has come under heavy fire, threatened by numerous side channel attacks. With Intel repeatedly patching SGX to regain security, we set out to explore the effectiveness of SGX's update mechanisms to prevent attacks on real-world deployments.
More specifically, we survey and categorize various SGX attacks, their applicability to different SGX architectures, as well as the information they leak. We then explored the effectiveness of SGX's update mechanisms in preventing attacks on two real-word deployments, the SECRET network and PowerDVD. In both cases, we show that these vendors are unable to meet the security goals originally envisioned for their products, presumably due to SGX's long update timelines and the complexities of a manual update process. This forces vendors to make a difficult security vs. usability trade off, resulting in security compromises.
The Secret Network has been vulnerable to the xAPIC and MMIO vulnerabilities that were publicly disclosed on August 9, 2022. These vulnerabilities could be used to extract the consensus seed, a master decryption key for the private transactions on the Secret Network. Exposure of the consensus seed would enable the complete retroactive disclosure of all Secret-4 private transactions since the chain began. We have helped Secret Network to deploy mitigations, especially the Registration Freeze on October 5, 2022.
However, there is no way to know for certain whether this attack has been attempted previously. It is also possible that ordinary node operators may have unintentionally prepared the attack, if they were active nodes prior to the mitigations, and may opportunistically decide to complete it in the future. We urge privacy-conscious users to re-evaluate their risk considering that their past transactions may be exposed. The purpose of the discussion on this webpage is to explain the vulnerability in enough detail to help users make an informed risk assessment.
CyberLink PowerDVD is a popular software application to play UHD Blu-rays on computers, that relies on Intel SGX to ensure the confidentiality and integrity of AACS disc decryption keys. Given the impracticality of requiring users to install BIOS updates to use PowerDVD to play AACS2-protected content, PowerDVD allows AACS2 playback on Intel SGX machines that are not fully up-to-date and in trusted status. Thus most SGX vulnerabilities that have been disclosed over the years still affect PowerDVD's use of Intel SGX.
We ran PowerDVD on an outdated machine that supports Intel SGX and extracted the attestation keys. With these attestation keys, we are then able to reverse engineer PowerDVD's enclave to extract AACS2 keys from their provisioning process. The extraction of these keys would then allow anyone to play UHD Blu-Rays outside of Intel SGX.
Contact us at firstname.lastname@example.org.
Table 1 provides an overview of publicly known SGX attacks, what information can be leaked using them, as well as the mitigation strategies for each attack technique. Finally, we also identify whether the responsibility lies with developer or Intel to address such each attack method.
Table 2 provides an overview of attacks requiring microcode updates, as well as the platforms affected by each attack technique. A more elaborate overview of the affected platforms can be found on Intel's website.
Whenever a new SGX vulnerability is discovered, Intel typically releases new microcode in order to mitigate the issue. As microcode is distributed as part of a BIOS updates, Intel works with hardware vendors to integrate these microcode updates for affected platforms. We performed an analysis of six common SGX vulnerabilities and how long it took popular vendors to release an update for their devices. Figure 1 presents the results of our analysis, showing it takes vendors almost two months to release patches. We found that BIOS updates are generally slow, but also observed that some products get patched before disclosure, whereas others take several months (if they get patched at all).
With the frequency at which SGX vulnerabilities are discovered and disclosed, SGX developers are therefore facing a difficult trade off between security and usability. In the ideal world, SGX developers would want their software to only run on fully trusted and up-to-date SGX platforms. However, installing BIOS updates is a rather cumbersome experience for most users, thus it is sometimes more practical to allow SGX software to run on out-of-date platforms rather than requiring the platform to be fully up-to-date and in a trusted status.
PowerDVD is a popular software application for playing UHD Blu-rays on computers. In order to prevent disc copying, PowerDVD uses SGX for Digital Rights Management (DRM) via the AACS2 algorithm. As requiring SGX already severely limits the number of platforms capable of playing Blu-rays, requiring users to additionaly install BIOS updates would be rather impractical. Thus, CyberLink faces the dilemma of allowing untrusted outdated machines to playback AACS2 content versus limiting the use of PowerDVD to a few trusted machines.
In fact, we found that PowerDVD allows the playback of AACS2 content on unpatched SGX platforms. This in turn allowed us to reverse engineer PowerDVD's SGX enclave, document the AACS2 algorithm as well as outline how one would play Blue-ray movies without SGX support.
Secret Network is the first publicly-available instance of Trusted Execution Environment (TEE)-based private smart contracts. Related systems that have not yet publicly launched their smart contracts include Oasis, Phala, and Obscuro. Research projects on TEE-based smart contracts include Ekiden, KMG19, and PDOs. Secret has several notable applications making use of private smart contracts, including private bridged tokens, private DeFi, and private NFTs.
At a high level, the Secret Network works by storing a private key in every network validator's SGX enclave (every enclave contains the same key). This key has a public component which users can use to encrypt messages to the network via hybrid encryption. These encrypted messages are decrypted within the enclaves, contract state (which is also encrypted) is updated according to its contents, and the encrypted message is posted on-chain.
As a TEST NETWORK demonstration of the breach of Secret using the xAPIC vulnerability, we have set up a service that decrypts any Pulsar-2 test network transaction. You can use the button on the left to browse to any transaction on the secretnodes explorer such as this one to see the transaction with the encrypted message. Then with the button on the right you can use our service to see the decrypted message. You can change the transaction ID to see the decrypted message for any other transaction as well.
We obtained the consensus seeds for both the main network and the test network using the same technique. We have disposed of all mainnet private key materials after signing a Proof of Compromise message using the io-exchange key derived from the consensus seed.
For more detail see the FAQ item.
To the credit of Secret Network, their documentation did state that an SGX compromise would lead to a loss of privacy but not affect system integrity. We hope, however, that this work is sufficient to prompt an update to the documentation of Secret and related projects that risks due to SGX attacks are more than theoretical. We are aware that other projects may not clearly even state the potential risks, and we hope that our efforts here can be used to pressure system designers into stating these risks explicitly and in a way that can be verified publicly by knowledgeable community members. Lastly, we are not suggesting that all SGX projects should be avoided, but rather that they should consider defense-in-depth strategies, where the purpose of SGX is to raise the difficulty of attacking the system but not serve as the only line of defense.
SGX is not infallible, and its vulnerabilities do not require a sophisticated lab to exploit. Based on history, we should anticipate more SGX vulnerabilities in the future. We recommend that developers have a TCB recovery plan in place, and should implement mitigations against SGX compromise as a development priority. Furthermore, developers should push Intel and partners to initiate the TCB recovery as early as possible to minimize risk.
We have coordinated the public disclosure of our survey with Intel, CyberLink and the Secret network.
While Intel had originally planned a TCB recovery to address the xAPIC and MMIO issues on March 7, 2023, 7 months after the disclosure of these issues, this date has now been moved to November 29, 2022. However, this only partially addresses the issue as popular SGX-enabled servers and desktops will only be updated in January 2023, and thus will remain vulnerable until then.
Secret Network promptly froze registration once our initial disclosure was made, and no longer accepts nodes susceptible to the xAPIC vulnerability and MMIO vulnerabilities. Secret is developing the ability to change the consensus seed, allowing the network to protect future data from being exploited through this vulnerability. However, despite the mitigations, it is not possible to completely guarantee the privacy of past transactions performed on the network. See also Secret's blog post for more information.
As PowerDVD cannot expect their users to continuously update their BIOS as a requirement to playing UHD Blu-Ray discs, it is likely that PowerDVD will continue to trust unpatched machines with a
GROUP_OUT_OF_DATE attestation status, rendering it vulnerable to nearly all SGX attacks.
Hardware that is vulnerable to the xAPIC and MMIO vulnerabilities is widely available. We purchased a machine that is specifically vulnerable to the xAPIC variant, and registered it on the Secret Network by following the "Full Node Setup" instructions, resulting in storing a sealed consensus seed on our node. Next, we exploited the vulnerability on our own node to extract the consesus seed during the unsealing process.
To understand the difficulty involved, it helps to think of the attack as having two phases, Prepare and Exploit. The Prepare phase is technically simple and just involves joining a new node to the network like an ordinary node operator. An attacker would have needed to obtain a vulnerable processor/BIOS configuration and complete the registration process before the Registration Freeze mitigation on Oct 4.
The Exploit phase is a offline computation attack carried out against the local sealed copy of the consensus seed, without any interaction on the network. While this step is technically-involved and likely requires an in-depth understanding of the xAPIC vulnerability, attackers who completed the Prepare phase prior to Oct 4 could complete this step at their leisure, even now or in the future.
To summarize, only the prepare phase of the attack was time critical, since joining a new vulnerable node to the network has not been possible since Oct 4. However, no expertise would have been needed, just acquiring an appropriate PC.
The primary mitigation was a “Registration Freeze,” enacted shortly after our disclosure, on October 4, 2022. This works by revoking the developer’s SPID key with Intel Attestation Services (IAS), blocking new node registration altogether. Anyone attempting to register a new platform on Secret Network would fail to obtain a signed attestation report from IAS, and would therefore see an error message.
After the initial Registration Freeze, the registration process has been gradually reopening. First, an allow-list was implemented so that non-vulnerable processor types can again join the network. Additionally, after SGX TCB Recovery, even previously-vulnerable hardware will be allowed to join the network as long as their microcode has been patched.
See also Secret's blog for more information.
The most critical time window was therefore from August 9 to October 4. Any non-sophisticated attacker that began their attack in that time window by registering a vulnerable node on the network, would have completed the prepare phase of their attack in time, and would most likely succeed as the exploit phase eventually.
A list of processors affected by the xAPIC vulnerability can be found from Intel's SA-00657 advisory. We found a line of widely available inexpensive PCs that are affected by the xAPIC vulnerability and successfully pass Secret Network's attestation checks. Customers of a cloud service running nodes would not be able to mount the attack, though administrators at the cloud provider plausibly could. To summarize, motivated attackers could have easily obtain vulnerable hardware, and individual node operators may even have inadvertently registered vulnerable instances.
The main reason why devices already known to be vulnerable were allowed to join the network has to do with Intel's TCB Recovery timelines. Put simply, when an SGX vulnerability is made public, even if there are microcode patches available, IAS may not reject unpatched devices right away, so as to give vendors time to update their machines. In this case, even though the attack was known, the attack resulted in a complete compromise of enclave signing keys, and the source code to carry out the attack was publicly available, still the original TCB Recovery timeline was projected to take months.
The consensus seed can be used to derive decryption keys for the entire Secret Network. Breaching this enables decrypting all the encrypted messages that interact with smart contracts as well as all smart contract state. The most concerning application of this attack is bulk surveillance of Secret users’ personal finances. Other concerning applications are the breach of private metadata from secret NFTs, as well as front-running DeFi applications. Note that the integrity of the blockchain is still assured, so in general, funds are safe and only the privacy and confidentiality of the blockchain is threatened. However, any digital assets that rely on private metadata, such as NFTs exchanging secret authentication keys, would be at risk of theft.
Users relying on Secret for privacy or confidentiality should consider that the confidentiality of their past transactions is no longer guaranteed. Update your risk analysis with this potential data breach in mind. For node operators, applying software updates from the developers can further reduce the potential of a data breach.
We completed the Exploit phase of the attack using two approaches, initially working as two independent teams that joined up later. Team 1 made a specialized effort by applying the xAPIC vulnerability directly to Secret. Team 2 made use of a powerful generic tool, EGX, which is a scientific contribution central to the SGX.Fail research paper. Since EGX hasn’t been published until now, an attacker would not have had access to it. However, overall our experience suggests that any motivated security expert would eventually complete the Exploit phase of the attack. Again, regardless of how the Offline phase is completed, the only time-sensitive step was the Online Phase of registering a vulnerable node on the network.
Preparing the attack by following the ordinary documentation leaves a network trace, since a registration transaction containing an attestation reports must be submitted on-chain.
Secret developers have estimated that 4% of nodes registered before October 4 were potentially vulnerable.
However, it was also possible to prepare the attack in an offline way (without any registration transaction at all) that uses an existing non-vulnerable node and locally invokes the
ecall_authenticate_new_node method to generate a sealed consensus seed for the vulnerable node.
An attacker would still have needed to complete an IAS attestation prior to October 4, but they would not have needed to interact with the blockchain network.
Thus the estimate based on registration data does not include deliberately-stealthy attackers.
Given the past history of SGX vulnerabilities and the process of TCB Recovery, it’s essential to anticipate potential future vulnerabilities and have a mitigation plan in place. For example, Secret Network could automatically enact a Registration Freeze immediately following a public disclosure or 0-day announcement.
Secret’s documentation should reconsider its claims about SGX vulnerabilities, such as that they are only theoretical or require a laboratory setting to carry out. Not only have we shown this is not accurate, but it wasn’t well justified given the past history of vulnerabilities either. Previous vulnerabilities like Foreshadow and CacheOut had similar consequences and timelines, hence we should anticipate the potential for future instances like this as well.
In Secret, clients who wish to send private messages to interact with smart contracts do so by first encrypting their messages, which are later decrypted inside of enclaves and processed.
The way this works is there is a public value called the
io_exchange_public_key which is a Curve25519 generator multiplied by an unknown scalar (the
io_exchange_private_key, which is known to all enclaves).
To encrypt a message to the network, a client samples their own private scalar and performs Diffie-Hellman key exchange against the
io_exchange_public_key to derive a symmetric AES key.
The message is encrypted under this key and the ciphertext is sent alongside the Curve25519 generator multiplied by their private scalar.
Enclaves are able to parse this message, derive the same symmetric key, and decrypt and process the message.
In short, knowledge of the
io_exchange_private_key is sufficient to decrypt all confidential transactions from outside of an enclave.
Hence, the goal of this Proof of Compromise is to prove that we at one point knew this value.
io_exchange_public_key for the Secret-4 mainnet is:
We have produced a signed message here under the Axolotl 25519 signature scheme, which can be verified under the
In the Proof of Compromise section, we provided a value which we claim is the
io_exchange_public_key for the mainnet, under which we signed a "capture the flag" message. Here we provide an explanation of a possible method by which an interested reader can verify that we provided the correct value (as opposed to the public component of a keypair we generated ourselves).
If you have a working installation of secretd, run
secretd query register secret-network-params followed by
secretd parse ./io-master-cert.der.
Otherwise, follow Secret Network's tutorial for setting up the secretcli, and then run
secretcli query register secret-network-params to get the io-master-cert.
This can be parsed with OpenSSL to get a JSON blob from the Netscape Comment field.
Base64 decode the "report" field of this blob to get another JSON blob, from which the "isvEnclaveQuoteBody" should be decoded from base64 into hex.
The last 32 non-zero bytes of the hex will be the
All of this can be done with the following command:
openssl x509 -in ./io-master-cert.der -inform der -noout -text | grep -oP '(?<="report":")[^"]*' | base64 -d | grep -oP '(?<="isvEnclaveQuoteBody":")[^"]*' | base64 -d | od -tx -j 368 -N 32 -An --endian=big | tr -d ' ' | tr -d '\n'
We observed that PowerDVD can playback AACS2 content on an unpatched Intel Core i7-6820HQ (Skylake) that is vulnerable to the Foreshadow attack. We then mounted the Foreshadow attack and extracted the SGX attestation keys for this machine, which then allowed us to sign our own attestation reports. With the ability to sign our own attestation reports, we could then run CyberLink's enclaves outside of Intel SGX and fully reverse engineer them. More specifically, we ran the code that contacts the service to provision AACS2 keys outside of Intel SGX, which unable to distinguish our rogue implementation from a real one, provisions us with the AACS2 keys.
An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface, which can be used by the software running on top of it.
Furthermore, the operating system decides how this hardware is shared by your software, and as such has access to all the data stored in your computer's memory. Thus, it is essential to isolate the operating system from other programs running on the same machine.
Unified Extensible Firmware Interface (UEFI) is a specification defining the software interface between the operating system and the platform firmware. UEFI generally refers to the platform firmware that is responsible for booting the system and any of its components before starting the operating system. This replaces the Basic Input/Output System (BIOS) that was originally used to boot IBM PC-compatible computers, and hence BIOS is still in common use to refer to the platform firmware.
CPU microcode forms the translation layer between the high-level standard CPU instructions coming from the software that the CPU has to interpret, and the low-level CPU operations specific to the particular CPU that the underlying hardware can actually execute. This microcode is first loaded by the CPU, and may later in the boot process be replaced by newer microcode updates through the BIOS/UEFI or the OS. Thus, a microcode update allows the CPU manufacturer to alter low-level behavior of a given CPU in the event that new bugs are discovered.
Intel Security Guard Extensions (SGX) offer an even stronger isolation guarantee that allows third parties to run their software in secure enclaves, with protection against a compromised operating system and/or hypervisor.
Intel SGX allows third-parties to run code on your machine with the guarantee that the code cannot be compromised. However, without the ability for the enclave to prove its genuineness to remote parties over the network, Intel SGX would be useless. This is where remote attestation comes into play, as it allows your computer to cryptographically prove that your information is protected by a genuine Intel machine.
Remote attestation in Intel SGX is interesting for many kinds of application where a third-party wants to run code on your machine with the guarantee that it cannot be compromised. Developers are slowly adopting Intel SGX to develop such applications, including blockchains, DRM and secure data storage for contacts and fingerprints.
In the context of Intel SGX, a Trusted Compute Base (TCB) is the collection of hardware, firmware and software components critical to the security of Intel SGX.
In the event that a vulnerability gets discovered allowing the compromise of SGX attestation keys, the currently deployed TCB can no longer be trusted. Thus, a TCB recovery is required to mitigate the vulnerability in the TCB and derive new SGX attestation keys to restore this trust.
We found that platforms affected by the xAPIC and MMIO issues, both disclosed on August 9, 2022, were still in
TRUSTED state two months after this disclosure date.
While the TCB recovery was originally planned to happen no later than March 7, 2023 for platforms using Intel EPID attestation, Intel changed this timeline to November 29, 2022 after our disclosure for some platforms, with popular SGX-enabled servers and desktop only being planned to go through TCB recovery in January 2023.
We provide an overview of existing SGX attacks in our paper, together with information for SGX developers on how they can mitigate these issues, and/or what Intel has done and can do to mitigate these issues. For future vulnerabilities, we also provide a study based on existing mitigation strategies to give developers an idea of what to expect when similar vulnerabilities get discovered and disclosed.
Furthermore, Intel maintains a table of known vulnerabilities and affected CPUs including brief summaries of the vulnerabilities, how to mitigate the vulnerability or how Intel is planning to mitigate the vulnerability. For any vulnerabilities affecting Intel SGX, Intel will indicate that a TCB recovery is required. Furthermore, some vulnerabilities may also include a deep dive, which is a more technical analysis of the vulnerability, especially in the event software hardening is required in addition to a TCB recovery.
This work was supported by the Air Force Office of Scientific Research (AFOSR) under award number FA9550-20-1-0425; an ARC Discovery Early Career Researcher Award DE200101577; an ARC Discovery Project number DP210102670; the Blavatnik ICRC at Tel-Aviv University; the National Science Foundation under grant CNS-1954712, CNS-2047991, CNS-2112726 and CNS-1943499 and gifts from Intel and Qualcomm.
Parts of this work were undertaken while Yuval Yarom was affiliated with Data61, CSIRO.