The rumors about Intel SGX deprecated in new processors has been confirmed, 12th generation processors (Workstation/Desktop/Laptop/embedded platforms) will deprecate SGX and the SGX will continue to support only in high-end Xeon CPU for server:

Intel’s official explanation is that final decision is made due to market reasons. Intel SGX (software guard extension) has been shipped with the release of the 6th generation processor Skylake in 2015. Its main purpose is to better solve the trust issue in cloud environments between CSPs (cloud service provider) and tenants. SGX proposes a solution called enclave where OS isn’t able to access to. The technical details of SGX has a lot of controversy since the beginning. This article will explore a bit about SGX:

Root problem: complexity

Intel SGX is the most sophisticated implementation among the enclave solutions. Intel did a lot of work at multiple levels to leverage the support:

• Hardware, e.g: MEE
• Ucode, for special instructions
• Firmware, Intel CSME infrastructure upgrade and multiple CSME modules getting involved

SGX basics

• SGX hands over paging (EPC) to an untrusted OS, which is similar to BASTION, where the host OS can evict.
• SGX uses Intel EPID to implement attestation, which is too complex for microcode to implement.
• In addition to EPID, SGX also uses other CSME code modules such as iclsClient using CLS (Capability Licensing Services)

Attestation process

• Seal Secret and Prospering Secret are stored in e-fuses, Provisioning Secret is generated by Intel Key Generation Facility and burned to the CPU and saved in Intel xx service, Seal secret is generated inside the CPU, theoretically unknowable to Intel.
• EGETKEY uses certificate-based identify (MRSIGNER, ISVPRODID, ISVSVN) and SGX implementation version (CPUSVN) to get the Provisioning key, which allows the Intel provisioning service to verify that Provisioning Enclave is signed by Intel. The provisioning service can also refuse communication based on CPUSVN to determine if there is a vulnerability.
• When Provisioning Enclave obtains the Provisioning Key and communicates with the Intel Provisioning service and authenticates itself, the service generates an Attestation key to provision the Enclave, which encrypts the AK using the Prospering Seal key and saves it.
• AK uses the EPID cryptography, EPID as a group signature scheme to provide some anonymity for the signer, Intel key provisioning service is the issuer, it will publish the Group Public Key and will save the Master Issuing Key itself, after the provisioning enclave verifies itself to the service, The service generates an EPID member private key as an AK and then executes the EPID Join protocol to join the signature group, after which Quoting Enclave uses the EPID MPK to generate an attestation signature.

Risk： Issued SIGSTRUCT was leaked, and attackers could use the SGX debugging feature to build debugging provisioning or Quoting enclave to modify the code, or get a 128-bit provisioning key to communicate with the Intel service.

Key* of SGX

According to Intel’s patent, the implementation of SGX relies on the complex KDF process inside the CPU circuit for the global secret keys and stored in the eFUSE, Chipworks offers $50-250k to fully extract the eFUSE of one Intel i5 processor, so the eFUSE content is encrypted by a master key (called “global wrapping logic key” in the patent). GWK is used to encrypt a 256-bit message for regenerating the EPID key of the CPU and a handful of 128-bit pre-seed key 0, eFUSE also contains a plaintext copy of 128-bit pre-seed key 1 and a 32-bit EPID group ID, GWK is hard-coded into the chip circuit, all chip manufacturers share the mask set, such a process increases the cost of the attack, But there is also the possibility of being reversed.

SGX also uses PUF to generate symmetric keys for the device during the provisioning phase, the PUF key is encrypted by GWK and transmitted to the key generation server, after which the key generation server encrypts the fuse key of the chip with the PUF key and then transmits it to the chip, the PUF key increases the cost of obtaining the chip fuse key. The attacker must compromise provisioning stage simultaneously.

CSME also has an eFUSE for saving the EPID key for fTPM. The first scheme is that Provision enclave uses the provisioning seal key to encrypt the DAK, which assumes that CSME is an untrusted flash memeory, so fTPM cannot be used. Another option is to use the key agreement protocol to establish a secure communication channel between DMI buses, which ME fw can be used to store DAKs or to implement fTPM.

Wrong threat model in the very beginning

Intel SGX puts the owner of on-premise (cloud service vendors, system administrators, etc) into the threat model in the 1st place. Technically, SGX doesn’t trust the operating system and the entire stacks of firmware (except CSME), but Intel might have missed an important common sense: OS kernel may no longer the “CORE” but it’s still the entrance to the “underworld”, as the 0ldsk00l hacker was joking about “don’t make jokes about the underworld”. Most of the attacks targeting SGX are based on having kernel privilege. A proper threat model won’t guarantee a comprehensive solution for security but it could be the starting point at least.

Wrong threat model isn’t the only issue in SGX：

• Over-design and implementation leads to out-of-control complexity.
• Lack of transparency, Intel SGX implementation is closed-source in terms of dependencies on the underlying firmware, which means it can’t be audited properly with acceptable cost. While SGX is highly dependent on Intel CSME, yet another issue about “god” mode in CSME can be referred to HardenedVault’s Intel CSME Risk Assessment.
• SGX can be used to protect malware, which malware detection become an impossible mission.
• Intel didn’t open up SGX-based third-party attestation services to SME client until December 2018, a decision that may have been a little late from a market and ecological perspective.
• SGX’s Linux kernel mainline process is slow. in April 2016, Intel submitted the first version of the SGX patch to the Linux kernel community, the Linux kernel community believes that there are many unresolved basic issues, including ABI compatibility issues and SGX as the core of enclave computing assumptions: if the Linux kernel is compromised, SGX can guarantee that the application is not interfered with by attackers. Even if this premise is correct, the kernel developer’s question is: If there is a malicious enclave application, who will protect the kernel? Moreover, the first premise has been denied by the industry after L1TF was exposed (although there were also relevant studies exposed before but the media did not report on a large scale), the exposure of L1TF and cryptocurrency bubble crashed in 2018 broke many people’s silver bullet expectations for SGX. A series of issues delayed the upstreaming until Linux kernel v5.11 merged SGX into mainline in Feb 2021.
• Launch low cost of side-channel attacks with Linux kernel privileges.
• Over-hype in the market, this problem may be more prominent in China. The megacorp continues to advocate that SGX can become the “next generation” silver bullet level program, but the reality is that the general principle in infosec is that there is no silver bullet.

Is SGX still an effective security feature?

Yes, SGX is still an effective security mechanism to protect your digital assets. Intel has adjusted its expectation for SGX and it’s targeting server-only markets. From the perspective of the production environment, SGX is still a very effective security mechanism that can be utilized to build your own defense-in-depth “Cyber Bunker”.