A trusted execution environment (TEE) is a secure area of the main processor that protects code and data in terms of confidentiality and integrity. Data integrity prevents unauthorized entities outside the TEE from altering data, while code integrity prevents TEE code from being modified or replaced by unauthorized parties, which in some DRM schemes could include the device owner. This protection is provided by hardware-based mechanisms such as Intel Software Guard Extensions (Intel SGX), which offers memory encryption and isolates specific application code and data. Intel SGX allows user-level applications to allocate private memory regions called enclaves, which are protected even from higher-privileged processes. As an isolated execution environment, a TEE provides isolated execution, integrity of applications running inside it, and confidentiality of their assets. Generally, a TEE offers stronger security for trusted applications than a rich operating system and more functionality than a secure element. History:
The Open Mobile Terminal Platform (OMTP) first defined TEE in their "Advanced Trusted Environment: OMTP TR1" standard, defining it as "a set of hardware and software components providing facilities necessary to support applications," which had to meet the requirements of one of two defined security levels. Profile 1 targeted only software attacks, while Profile 2 targeted both software and hardware attacks. Commercial TEE solutions based on ARM TrustZone technology and conforming to the TR1 standard were later launched, such as Trusted Foundations, developed by Trusted Logic. Work on the OMTP standards ended in mid-2010 when the group transitioned into the Wholesale Applications Community (WAC). The OMTP standards, including those defining a TEE, are hosted by the GSMA.

Details:
The TEE typically consists of a hardware isolation mechanism plus a secure operating system running on top of that isolation mechanism. However, the term has been used more generally to mean a protected solution. While a GlobalPlatform TEE requires hardware isolation, others such as EMVCo use the term TEE to refer to both hardware/software and software-only solutions. FIDO uses the TEE concept for restricted operating environments based on hardware isolation. Only trusted applications running in a Trusted Execution Environment (TEE) have access to the full capabilities of a device's main processor, peripherals, and memory; hardware isolation protects these resources from user-installed apps running in the main operating system. Software and cryptographic isolation inside the TEE also protect trusted applications from one another. Service providers, mobile network operators (MNOs), operating-system developers, application developers, device manufacturers, platform providers, and silicon vendors are the primary stakeholders in TEE standardization. To prevent simulation of hardware by user-controlled software, a hardware root of trust is used: a set of private keys embedded into the chip during manufacturing. One-time programmable memory such as eFuses is typically used on mobile devices; these keys cannot be changed even after device resets. The public counterparts of those keys are stored in a manufacturer database, along with a non-secret hash of the trusted party's public key (usually the chip vendor), which is used to sign trusted firmware and the circuits that perform cryptographic operations and control access. The hardware is designed to prevent any software not signed with the trusted party's key from accessing privileged features. At runtime, the vendor's public key is provided and hashed; the result is compared to the hash embedded in the chip. If the hash matches, the public key is used to verify a digital signature on trusted, vendor-controlled firmware (for example, the chain of bootloaders on Android devices or architectural enclaves in Intel SGX). That trusted firmware implements remote attestation. During attestation, an application's untrusted component loads its trusted component into memory, and hardware prevents untrusted components from modifying the trusted component. The untrusted party requests a nonce from the verifier's server; the nonce is used in a cryptographic authentication protocol to prove the integrity of the trusted application. The proof is returned to the verifier, which checks it. A valid proof cannot be produced on simulated hardware (e.g., QEMU) because constructing it requires access to keys embedded in the device; only the trusted firmware can access those keys or keys derived from them. Because only the platform owner is intended to access the data recorded by the manufacturer, the verifier must interact with a service set up by the vendor. If the scheme is implemented improperly, the chip vendor could track which applications run on which chip and selectively deny service by falsely reporting that authentication failed. To simulate hardware so it passes remote authentication, an attacker must extract keys from the device, which is costly because of the required equipment and technical skill. Techniques such as focused ion beams, scanning electron microscopy, microprobing, and chip decapsulation are difficult—or impossible—if the hardware is designed so reverse engineering destroys the keys. In most cases keys are unique to each device, so a key extracted from one chip cannot be used on others (for example, with physically unclonable functions). Although loss of ownership is not inherent to TEEs—it is possible to design a system that lets the first user retain control by burning a hash of their key into e-fuses—in practice consumer electronics are typically designed to allow chip manufacturers to control access to attestation and its algorithms.