Another Intel SGX Security Flaw? Our Analysis of the SGX Fuse Key Extraction Claim

Another Intel SGX Security Flaw? Our Analysis of the SGX Fuse Key Extraction Claim

A recent discovery reveals a weakness in older Intel CPUs affecting SGX security. Despite the alarm, the extracted keys are encrypted and unusable. Dive in to learn more.

Corentin Lauverjat,
Massilia B

At Mithril Security, our mission is to develop cybersecurity solutions for AI leveraging trusted environments. Our first product, BlindAI, was the market’s first open-source confidential AI inference solution running in an enclave. The solution, audited in 2023 by Quarkslab, relies on Intel SGX. Intel SGX sometimes makes headlines in tech news when vulnerabilities or weaknesses are disclosed. These concerns frequently come up when we present our security solutions based on enclaves. However, these articles often sensationalize the security issues, misrepresenting the actual threat. Here is our take on the latest weakness that was recently discovered.

TLDR: 

- Mark Ermolov discovered a weakness in Intel CPUs, allowing extraction of two root keys used in Intel SGX.

- The extracted keys are encrypted and cannot be decrypted, making them unusable for attackers. 

- The flaw only impacts old (end-of-life) processors (e.g. Gemini Lake Refresh).

- Intel SGX’s security remains unaffected thanks to its defense in depth design, and no remedial actions are required.

- Parties with (very) low-risk tolerance can take a proactive measure to protect against the identified weakness

On August 26, 2024, Mark Ermolov, a researcher at Positive Technologies, uncovered a weakness in Intel CPUs. He announced that he had successfully extracted Intel’s SGX Fuse Key0 (FK0), also known as the Root Provisioning Key (RPK), as well as the Fuse Key1 (FK1), i.e. the Root Sealing Key (RSK). 

(source)

Each CPU that supports SGX contains these two root keys. The RPK enables remote attestation of the CPU, and the RSK enables sealing. These two features are core to what SGX provides. 

This disclosure raised concerns within the security community, and Intel published a statement in response

A closer look at Ermolov’s claims reveals that his findings do not lead to any practical security damage. Also, the impact is minimal, as the affected processors have reached their End of Life. 

Analysis

Ermolov identified a flaw in Intel microcode that results in Fuse Key0 and Fuse Key1 not being adequately cleared, allowing the secrets to be extracted.

(Source)

To understand the implications, it's important to know some implementation details of Intel SGX. The details are officially undocumented but have been studied by researchers like Victor Costan, Ilia Lebedev, and Srinivas Devadas, who gleaned information from Intel patents[1] [2].

Their work reveals that the Fused Seal Key and Provisioning Key are encrypted using a key known as the Global Wrapping Key (GWK), a 128-bit AES key embedded in the processor’s circuitry. 

Reading Ermolov's tweets more carefully, it becomes clear that the keys he extracted are the encrypted versions of FK0 and FK1. He did not obtain the GWK and therefore cannot decrypt the Fuse Keys. This is an important precision as the encrypted root keys are useless for an attacker.

There is no dispute on the matter, with both Ermolov and Intel in agreement. As a result, the issue should be classified as a security weakness rather than a vulnerability.

Affected processors

The affected processors are limited to the Denverton, Apollo Lake, Gemini Lake, and Gemini Lake Refresh platforms. According to Intel, only the Gemini Lake and Gemini Lake Refresh platforms support Intel SGX. All of these processors have now been discontinued, having reached their End of Life (EOL).

Intel TDX is not impacted, as it was introduced in later platforms, specifically Emerald Rapids and Sapphire Rapids.  

Discussion

Our analysis indicates that the weakness is real but not exploitable. While the weakness erodes the security margin on the affected processors, it does not compromise Intel SGX security properties. 

The main concern about this weakness is that there is no way to completely recover from it. Applying Intel recommended actions will only prevent an attacker from extracting the encrypted secrets once it is applied, but if the attacker has already extracted the FK0 and FK1 values then it is already too late : FK0 and FK1 cannot be rotated, they are coming from fused secrets which are burnt during manufacturing. So the adverse consequence of the weakness on the security margin will remain forever.  

The security of the remote attestation of the affected processors now rests on the GWK remaining secret. This is not ideal because the GWK is common to all chips produced from the same mask (the mask used during the lithography process), whereas each chip's fused secrets are unique. Extracting the GWK, however, would require yet another substantial breach. The GWK is hard-coded into the processor’s circuitry specifically to increase the cost of attacks to extract the secrets. This means that while reading the e-fuse via a hardware attack is expensive, reading the GWK will be orders of magnitude harder and requires even more expensive equipment. A more realistic threat is that an attacker finds a software vulnerability enabling him to extract the GWK. The combination of the present weakness with such vulnerability would then break Intel SGX by enabling attackers to forge Intel attestation. 

On the plus side, this finding highlights the resilience of Intel SGX's design. Despite this serious microcode vulnerability, SGX maintains its security. Moreover, it shows that security researchers are continuing to study the security of SGX, a sign of a healthy security ecosystem around SGX. 

What actions should be taken?

No action is required since there is no actual security issue. 

In the unlikely event that this weakness eventually leads to a complete compromise of the affected processor’s attestation, Intel would respond by revoking the compromised processors. This would be handled automatically through Intel’s attestation system, meaning no updates or manual interventions would be necessary. Once revoked, attestations from these processors would be rejected by relying parties.

For service providers not relying on the affected CPUs, enclave vendors may proactively block attestations from these processors to mitigate potential risks. 

To block attestation originating from the affected processors, your enclave vendor will provide an update to the relying party software, making its attestation appraisal policy more strict. It will alleviate both immediate and future concerns about the reduced security margin. Before taking this step, however, service providers should verify that the enclaves are not hosted on the affected processors. Given that these processors are at the end of life,  enclaves are likely already hosted on unaffected hardware, making the measure painless for the service providers and alleviating the relying party’s security concerns.

If enclaves are still hosted on the affected processors, service providers can:

  1. Upgrade the hardware or migrate the enclave to unaffected processors, then block attestations from the compromised hardware.
  2. Do nothing, depending on the relying party's risk tolerance (which also makes complete sense).

Affected Mithril Security solutions

No actively maintained solution from Mithril Security is affected. 

BlindAI (no longer actively maintained) is affected by the weakness. However, since there is no practical security impact, no actions are required. If you are still concerned about this weakness, we invite you to contact us. As explained above we (as the enclave vendor) can provide a custom BlindAI client that proactively blocks the affected CPUs. 

Maintained projects based on Mithril OS use either TPM or Confidential VM (AMD SEV SNP), which are not impacted by the vulnerability. 

Conclusion

Intel SGX regularly makes headlines in tech news when vulnerabilities or weaknesses are disclosed, but these reports frequently exaggerate the actual risk. 

Crucially, Intel can revoke a processor trust status at any time via Intel SGX’s attestation system.  If Intel discovers a processor to be affected by a vulnerability, Intel will simply revoke it, and the relying party will no longer accept attestation reports from the compromised hardware. This revocation mechanism enables users to remain confident in SGX’s ability to uphold its security promises.

In this case, the reported weakness impacts end-of-life processors and is non-exploitable. Concerned parties can apply stricter attestation appraisal policies if needed to mitigate any residual risk by asking their enclave vendor. 

  1. V. Costan and S. Devadas, “Intel SGX Explained,” 086, 2016. Accessed: Sep. 03, 2021. [Online]. Available: https://eprint.iacr.org/2016/086 ↩︎
  2. V. Costan, I. Lebedev, and S. Devadas, “Secure Processors Part II: Intel SGX Security Analysis and MIT Sanctum Architecture,” Found. Trends® Electron. Des. Autom., vol. 11, no. 3, pp. 249–361, 2017, doi: 10.1561/1000000052. ↩︎