Why Data in Use Needs Protection

The three states of data

Most applications handle data in three states:

1. Data at rest 2. Data in transit 3. Data in use

Understanding these states helps us see why TEEs exist.

Data at rest

Data at rest is stored data that is not currently being processed.

Examples include:

A file saved on a computer
A database record
A cloud storage object
A backup
A stored private key
A saved AI model

Storage encryption protects this data from someone who gains access to the storage device but does not have the decryption key.

For example, an encrypted database file may remain unreadable if someone steals the physical disk.

The protection changes once the application needs to read the database. The system must retrieve or derive the decryption key and turn the ciphertext into data that the application can use.

Data in transit

Data in transit is data moving between systems.

Examples include:

A browser sending a request to a website
A mobile application calling an API
Two servers exchanging messages
A blockchain node sharing transactions
A user uploading a private document

Protocols such as TLS protect data while it travels across a network.

TLS can protect against a network observer who wants to read or modify the traffic. It does not continue protecting the data after the receiving server decrypts it.

Data in use

Data in use is data that is actively being processed.

Examples include:

A processor calculating a credit score
An application signing a transaction
An AI model processing a private prompt
A program checking a biometric sample
A service comparing two private datasets
A trading system evaluating a private order

An ordinary processor usually needs access to readable data before it can perform useful work on that data.

This creates an important gap.

The application may receive data through an encrypted connection and store it in an encrypted database. However, when the application processes that data, plaintext values may appear in memory, processor registers, caches, temporary buffers, logs, and application state.

The Confidential Computing Consortium defines confidential computing as protecting data in use by performing computation inside a hardware-based, attested Trusted Execution Environment.

Why normal application isolation is not always enough

A normal application runs under the control of an operating system.

The operating system manages:

Application memory
Virtual memory
Page tables
Process scheduling
File access
Network access
Devices
Debugging
System calls

The operating system normally has more privilege than the application.

If the operating system is compromised, an attacker may be able to inspect application memory, interfere with execution, modify files, observe system calls, or capture secrets after the application decrypts them.

A virtual machine adds another layer called a hypervisor. The hypervisor manages virtual machines and normally has more control than the guest operating systems running inside them.

A cloud administrator may also have control over the infrastructure hosting the application.

💡

How can sensitive data be processed when the operating system, hypervisor, or infrastructure operator should not be allowed to read it? TEEs are one possible answer.

Example: Private salary analysis

Three companies want to compare employee salary ranges. They do not want to reveal individual salary records to each other, the cloud provider, the system administrator, or the developer operating the analysis service.

Each company encrypts its dataset before uploading it. The datasets are decrypted only inside an isolated execution environment. The program calculates an aggregate salary range and returns the result.

The raw datasets are never intentionally exposed to the cloud host.

This is a data-in-use problem because the application needs to calculate over the original values. Storage encryption alone cannot solve it. Network encryption alone cannot solve it. The data must be protected during the calculation itself.

TEEs are not the only solution

Other privacy technologies can also protect computation:

Secure multi-party computation
Fully homomorphic encryption
Zero-knowledge proofs
Threshold cryptography
Secret sharing

These technologies use different trust and cryptographic assumptions.

TEEs are useful because they can support general-purpose computation with fewer changes to the application than many purely cryptographic approaches. The trade-off is that the system must trust hardware, firmware, attestation infrastructure, and the trusted application.

💡

**Think about it** A messaging service encrypts messages on the user's phone, across the network, and in the server database. The server decrypts every message before running a spam filter. Where does plaintext exist? Who controls the server memory? Can the server administrator inspect the message? Would storage encryption stop that inspection? Which part of the process could a TEE protect?

Key takeaways

Data at rest is stored data.
Data in transit is moving data.
Data in use is data being processed.
Encryption at rest and in transit does not automatically protect active computation.
TEEs mainly address the protection of data in use.
A TEE is one possible privacy tool, not the only one.