Dictionary of Applied Machine Learning

trusted execution environment (TEE)

Updated on 2026-10-08

Typeset PDF Cite this entry

See also membership inference attack

A trusted execution environment (TEE) is a part of a computing system that runs code and holds data in isolation from the rest of the system. Neither the operating system nor the operator of the hardware can read or alter them, and the TEE can prove to another party which code it runs. Processor features such as Arm TrustZone and Intel SGX provide a TEE on an ordinary chip; a sealed, shielded embedded device without network connection is the physical extreme. In machine learning (ML), a TEE protects three assets: the feature vectors handed to a learned hypothesis, the model parameters of that hypothesis, and the integrity of the computed prediction. It hides nothing about what the prediction reveals, which is the part that differential privacy (DP) addresses, and it protects against physical side channels only with hardware countermeasures. Compared with fully homomorphic encryption (FHE), a TEE runs at near-native speed but rests on trust in the chip vendor rather than on a mathematical proof.

Definition

Consider a Raspberry Pi in a clinic that reads the signal of an electrocardiograph and computes, from the feature vector $\featurevec$ of each heartbeat, the prediction $\learnthypothesis(\featurevec)$ of a learned hypothesis that flags an arrhythmia. The board sits in a sealed metal box with no network cable and no radio. The only inputs are the sensor cable and the power cable, and the only output is a display. The model parameters $\widehat{\weights}$ of $\learnthypothesis$ and the recorded heartbeats never leave the box. A TEE is the part of a computing system that provides this kind of protection: code and data inside it cannot be read or altered from outside, and a party outside can verify which code runs inside (Sabt et al., 2015). The sealed box is the physical extreme of a TEE. Most TEEs are instead a mode of an ordinary processor: Arm TrustZone splits the processor of the Raspberry Pi into a normal world, which runs Linux and the display software, and a secure world, which runs the prediction code and holds $\widehat{\weights}$ and the heartbeats; the normal world cannot read the memory of the secure world even with root privileges (Pinto and Santos, 2019). Intel SGX provides the same isolation for an enclave inside a process on a server (Costan and Devadas, 2016), and remote attestation lets a client verify a signed digest of the enclave's code before it sends any data. Fig. 1 shows the Raspberry Pi and what each part can see.

Figure 1 of the entry tee
Figure 1: A TEE on a Raspberry Pi. The secure world holds the prediction code, the model parameters and the recorded heartbeats; the normal world receives only the prediction for the display. The sealed enclosure closes the side channels that a probe outside the processor could read
A TEE protects three assets of a machine learning (ML) system. The first is the data: the heartbeats are personal data that the clinic must not disclose. The second is the learned hypothesis: the model parameters $\widehat{\weights}$ are the outcome of training on a costly dataset, and an attack that reads them out obtains the hypothesis without the dataset. The third is the integrity of the prediction: nobody can alter the code so that it flags fewer arrhythmias. A TEE does not protect what the prediction reveals. A membership inference attack that only observes predictions is unaffected by it, and differential privacy (DP) is the tool for that part. A TEE also does not, by itself, protect against side channels. The current drawn by the processor and the electromagnetic field it emits depend on the data it processes, and a probe held near the chip recovers secret keys from these traces (Kocher et al., 1999). The same probe recovers the model parameters and the layer structure of an artificial neural network (ANN) running on an embedded processor, one multiplication at a time (Batina et al., 2019). A short electromagnetic pulse or a glitch on the supply voltage can also skip an instruction, e.g., the check that rejects unsigned code (Bar-El et al., 2006). The metal enclosure of the Raspberry Pi attenuates the emitted field and blocks the pulse, tamper sensors erase $\widehat{\weights}$ when the box is opened, and constant-time code makes the power trace independent of the data. Server TEEs face a software side channel instead: the memory access pattern of an enclave is visible to the operating system, so ML code inside an enclave must be data-oblivious, with access patterns that do not depend on the data (Ohrimenko et al., 2016), and speculative execution has leaked enclave memory outright (Van Bulck et al., 2018).

Two uses of TEEs beyond the sealed box are prediction in the cloud and federated learning (FL). A hospital that rents a server can require an SGX enclave, verify by attestation that it runs the agreed prediction code, and send its feature vectors encrypted to the enclave's key, so that the cloud provider never sees them (Ohrimenko et al., 2016). In FL, an enclave on the server implements secure aggregation: the clients encrypt their model parameters updates to the enclave, which decrypts and sums them, and the server operator sees only the sum; the TrustZone secure world of each phone protects the local update in turn (Mo et al., 2021).

A TEE, fully homomorphic encryption (FHE) and DP protect against different parties by different means. FHE hides the data from the computing party by mathematics, at a cost of orders of magnitude in time and memory, and needs no trust in the hardware. A TEE hides the data by hardware isolation at near-native speed, and rests on trust in the chip vendor and in the absence of side channels. DP bounds what the prediction reveals about any single data point and is combined with either.

Synonyms: secure enclave.

See also: fully homomorphic encryption, secure aggregation, differential privacy, privacy protection, privacy attack, membership inference attack, attack, federated learning, edge device, cloud computing, machine learning system, trustworthy artificial intelligence.

References

  1. Sabt et al. (2015). Trusted Execution Environment: What It is, and What It is Not. Proc. IEEE Trustcom/BigDataSE/ISPA. doi.org/10.1109/Trustcom.2015.357
  2. Pinto and Santos (2019). Demystifying Arm TrustZone: A Comprehensive Survey. ACM Computing Surveys. doi.org/10.1145/3291047
  3. Costan and Devadas (2016). Intel SGX Explained.
  4. Kocher et al. (1999). Differential Power Analysis. Advances in Cryptology -- CRYPTO '99. doi.org/10.1007/3-540-48405-1_25
  5. Batina et al. (2019). CSI NN: Reverse Engineering of Neural Network Architectures Through Electromagnetic Side Channel. Proc. 28th USENIX Security Symposium.
  6. Bar-El et al. (2006). The Sorcerer's Apprentice Guide to Fault Attacks. Proceedings of the IEEE. doi.org/10.1109/JPROC.2005.862424
  7. Ohrimenko et al. (2016). Oblivious Multi-Party Machine Learning on Trusted Processors. Proc. 25th USENIX Security Symposium.
  8. Van Bulck et al. (2018). Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution. Proc. 27th USENIX Security Symposium.
  9. Mo et al. (2021). PPFL: Privacy-preserving Federated Learning with Trusted Execution Environments. Proc. 19th Annual Int. Conf. Mobile Systems, Applications, and Services (MobiSys). doi.org/10.1145/3458864.3466628

Cite this entry

@misc{dictml_tee,
  author = {Jung, Alexander},
  editor = {Olioumtsevits, Konstantina and Schnoor, Ekkehard},
  title = {trusted execution environment (TEE)},
  howpublished = {Dictionary of Applied Machine Learning (course edition)},
  year = {2026},
  doi = {10.5281/zenodo.21569296},
  note = {ISBN 978-952-64-3013-3, CC BY 4.0, retrieved 2026-10-08},
  url = {https://dictionaryofml.org/terms/tee.html}
}