11

Does anyone have any information about Intel SGX:

From what I understand, all information (code and data) is encrypted in RAM, correct? Is it encrypted with a strong key (i.e. 128 or 256 bit AES) or something else?

Also, how is remote attestation performed? What information does the enclave send to prove that the program executing inside has not been tampered with?

And one other thing -- does using SGX require your computer to connect to an Intel server? I read somewhere that that might be the case, which would be a pretty major privacy issue. I'm not sure if the connection mentioned in the article I read was referring to a one time connection while the chip was being manufactured or a connection that had to be established every time an enclave was created or attested, though.

14

These are surprisingly deep questions about Intel SGX, so I've tried to give a good overview, covering the cryptographic and protocol level details to some degree of depth. Please ask followup questions if any of this is unclear! I've included a list of references and additional resources at the end.

Memory Encryption

All enclave data is transparently encrypted in memory. This is performed by the SGX Memory Encryption Engine (MEE). The MEE uses a complicated combination of Merkle trees, a tweaked version of AES Counter Mode, and a Carter-Wegman MAC construction. This uses a 128-bit confidentiality key, a 56-bit counter, a 128-bit integrity key (producing 56-bit MAC tags), and a 512-bit universal hash key (used in the MAC construction). These are generated at boot, placed in special MEE registers, and destroyed at system reset. The MEE operates on 512-bit cache lines, so each encryption takes four AES operations. (See [1, 2, 3] for more details.)

Attestation

Each enclave has an enclave certificate, which contains its supposed measurement, a vendor ID, a product ID, a version number, and some enclave attributes.

When an enclave is set up (using the EADD/EEXTEND instructions), it takes a measurement of its contents by taking the SHA-256 hash of its memory pages. This is finalized at the point of initialization of the enclave (using the EINIT instruction, after having all initial memory contents copied into its enclave pages). This hash serves as the measurement of the enclave. This is similar to other remote attestation techniques.

An enclave gets a signed attestation for itself from a special Intel enclave called the Quoting Enclave using the local attestation process. First, the enclave requests a local attestation report using the EREPORT instruction. The CPU computes an AES128-CMAC tag on the enclave's measurement and certificate to create the report. The Quoting Enclave checks the MAC on the report and replaces it with a signature using the CPU's Attestation Key (which the Quoting Enclave has special permission to access). This signature uses the Intel Enhanced Privacy ID (EPID) scheme [6,7,8], which is a group signature scheme. This means that a valid signature proves that it was part of the group, but does not reveal which member it is for. Intel maintains the group keys that let it verify signatures. The signed attestation quote is returned to the enclave, which can use it to attest to the remote party.

This signed attestation quote is sent to the remote party. It attests to the enclave's certificate (which contains the enclave's measurement, product ID number, version number, vendor ID, and some enclave attributes). The remote party connects to the Intel Attestation Service to verify the signed attestation quote from the enclave.

Remote attestation uses a secret that Intel burns into the CPU at the time of manufacturing (the Provisioning Secret) and another secret burned into the CPU at boot time (the Sealing Secret). The Provisioning Secret is shared with Intel (and stored in an Intel database for the attestation service). The Sealing Secret is not accessible outside of the CPU.

The Attestation Key is given to the Provisioning Enclave, which uses the Provisioning key (derived from the Provisioning Secret) to prove to the Intel service that it is legitimate. The Attestation Key is sealed in storage using the Provisioning Sealing Key (which is derived from the Sealing Secret). The stored Attestation Key can be reused repeatedly without contacting Intel servers.

Interaction with Intel

An SGX enabled processor will do a one-time initialization that involves communicating with Intel attestation servers. See [1, 6, 7]. This initialization survives change-of-ownership as well.

An SGX enabled processor will contact Intel servers via the Provisioning Enclave in order to receive an Attestation Key. The Attestation Key is sealed and stored and can be repeatedly used to create attestations. Note that the Intel provisioning service can detect deprecated SGX versions and refuse to issue new attestation keys.

A remote party must connect to the Intel Attestation Service each time it wants to verify a signed attestation quote from an enclave.

References

For a very in-depth treatment of SGX, I recommend "Intel SGX Explained" [1]. It gives an impressive amount of background into computer architecture, cryptography, low-level attacks, and other trusted computing hardware (which you can probably skip if you just want to read about SGX or are already familiar with those topics). This answer is largely a summary of their more in-depth explanations.

For more information about the MEE, I recommend [2] and [3].

Another good document, particularly if you are interested in current state-of-the-art in implementing secure services using SGX, is Jethro Beekman's dissertation on the subject [4]. It also provides good background on SGX from a software implementer's perspective.

The Intel Resources Library [5] provides a number of documents, at various levels of detail, on SGX functionality and implementation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.