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.
They are both crypto chips, but what are their functional similarities and difference?
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.
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 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.
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:
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.
