I know about the TPM (Trusted Platform Module). In recent years, more researchers start to develop on Intel SGX, which I do not have any experience with.

  1. They are both crypto chips, but what are their functional similarities and difference?

  2. What can SGX achieve that typical TPM can't?

(If you want, explain it in "textbook" version or "practical" version.)


Well first off, SGX is not a crypto chip. It is a feature built into Intel chipsets themselves, whereas the TPM is often a discrete chip positioned on the LPC bus, though sometimes it can be emulated in the chipset (in which case it's called fTPM, for firmware TPM, or iTPM, for integrated TPM). On Intel processors, an integrated TPM will be present for any system that supports TXT.

Trusted Platform Module (TPM)

The TPM is designed to allow for measured boot, a boot process where each stage verifies the next stage in a chain of trust, reducing the Trusted Computing Base (TCB) to a much smaller amount of code. The way it works is by getting a hash of various firmware-related data and storing it in PCRs (registers in the TPM) and unsealing a secret value if this matches a known configuration. This all starts with the trusted CRTM (Core Root-of-Trust for Measurement), which is a, usually, read-only component of the BIOS that sends a hash of the BIOS itself to the TPM. If the CRTM and TPM are trusted, then the rest of the system need not be trusted.

A TPM cannot act on any detected integrity violations. It is entirely passive, existing only on the LPC bus. All it can do in response to a violation is refuse to unseal itself. This secret value can be something like an encryption key necessary to boot the system, or a secret string not known to attackers, allowing you to verify that the TPM has really unsealed even if it is communicating this to you over an untrusted medium. The TPM also contains an Endorsement Key, or EK, which verifies it as a genuine TPM. Only genuine and approved TPMs will be given this key. This is similar to the PKI infrastructure for HTTPS where a CA allows a browser to verify the legitimacy of the connection to a server.

TPM provides the following guarantees to a sysadmin:

  • The TPM will resist attempts at tampering (e.g. decapping and glitching attacks).
  • The sysadmin will be able to verify that the TPM is genuine.
  • The TPM will only unseal itself when hash values from the boot process are correct.
  • A key can be set so the TPM will not unseal unless the PCRs are valid and the key is provided.

The TPM is not limited to being unsealed at boot. It can be unsealed at any time. As a verified boot can also verify userspace applications, a TPM can even be used, indirectly, to attest to the fact that a system is running a given piece of software or is configured in a specific way. Once the BIOS, bootloader, and kernel are verified, it can verify that the system is in an arbitrary state, for example, has up to date software. Only when all of this is in a valid state will the TPM unseal itself, allowing it to prove to clients that it is running up to date and secure software. This is called remote attestation, which itself can be used as a building block for network access controls.

Note that this is a bit of a simplification of a TPM's functionality, and it does not go into the differences between SRTM and DRTM (Static and Dynamic Root-of-Trust for Measurement, respectively), but it should be sufficient for the purpose of describing the general functionality of the system.

Software Guard Extensions (SGX)

SGX has a different design goal and is a good bit more complex. SGX can provide confidentiality and integrity to processes, and can verify the executable code before executing it. It is an active feature, and encrypts processes running in a secure enclave while protecting them. The processes know that the enclave is genuine, preventing it from being spoofed via emulation, and the enclave knows that the process is genuine, preventing the untrusted host from giving it a compromised process.

The secure enclave cannot even be read by the kernel or any other privileged task once it is set up. Because of this, a process running in a secure enclave can, at worst, be killed or made to crash. It cannot be tampered with (even with JTAG, as probe mode is disabled in SGX context, or so I'm told). This can be used for things like running a virtual machine guest which does not need to trust the host.

SGX provides the following guarantees to a process running in a secure enclave:

  • The process will be able to verify that it is running on genuine SGX.
  • The host cannot tamper with the process once it is running in the enclave.
  • The process gets to define an I/O API for communicating with processes on the host.
  • The process' state will never exist in plaintext in memory.
  • The process will be verified before being run, ensuring that it is legitimate.

Typically, an application making use of SGX would have to be designed specifically for this purpose. The application would be written to have two components. The first component would run unconfined on the host, whereas the second would be run in a secure enclave. An I/O API is defined for allowing the two components to communicate with each other. Any sensitive computation can be offloaded to the process in the secure enclave.

While SGX protects the enclave from the host, it does not do much to protect the host from the enclave. A malicious or compromised enclave process could exit the enclave and execute arbitrary code on the host. This is due to the fact that the EEXIT instruction (see page 67), which exits the enclave, only restores a limited number of registers. In particular, it allows the enclave process to set RIP, the instruction pointer, and jump to an arbitrary address.


The TPM merely tells you if your firmware or boot process has changed, and nothing more, whereas SGX is instead used to protect sensitive or confidential processes from the host. One similarity TPM and SGX have is that they both cannot be spoofed, allowing a system to know that it is talking to the real deal. Another is that they are both involved in the concept of trusted computing, reducing a system's TCB in various ways. Both systems have their own set of flaws. TPM version 1.1 and prior is vulnerable to the platform reset attack, for example. SGX is vulnerable to side-channel attacks, as two papers have recently shown.

Other than that, they are quite different, and they solve entirely different problems.

| improve this answer | |
  • 1
    The example with the video player is wrong. An enclave with an exploitable vulnerability can be used to achieve arbitrary code execution in the host process. SGX protects only the enclave process from the host but not the other way round. If this is a critical issue, then special sandboxing mechanisms for the host process must be employed. – Mike76 Sep 10 '18 at 22:51
  • @Mike76 Are you sure about that? I was under the impression that SGX protection goes both ways, given that you have to carefully specify an IO API to allow the enclave to communicate with the outside. The enclave process doesn't have access to outside memory, for example. – forest Sep 11 '18 at 1:27
  • 3
    Yes I am sure. Have a look at the "SGX explained" paper: eprint.iacr.org/2016/086.pdf On page 67 the synchronous enclave exit with the EEXIT instruction is explained. The enclave restores the host process RIP, RSP, RBP and other registers before switching back to the host process using EEXIT. Therefore a malicious enclave is able to jump to an arbitrary location within the host process. – Mike76 Sep 11 '18 at 8:44
  • 1
    If strong isolation is required for both ways, then I recommend to run the enclave within a small sand-boxed wrapper host process which does nothing else but forwarding calls to the enclave. As a sand-boxing mechanism for the host process, a strict seccomp policy might be applied to prevent exploits within the enclave or host process from taking over the control of your system. – Mike76 Sep 11 '18 at 8:50
  • 1
    " The SDM explicitly states that EEXIT does not modify most registers, so enclave authors must make sure to clear any secrets stored in the processor’s registers before returning control to the host process. " - This implies that it is the responsibility of the enclave to restore most registers before calling EEXIT. A malicious enclave could load arbitrary values to the registers before "jumping back" to an arbitrary location within the host process. – Mike76 Sep 11 '18 at 8:58

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.