Skip to content

CONCEPT Cited by 1 source

Confidential storage inside the TEE

Definition

Confidential storage inside the TEE is the architectural move of placing the storage engine — not just the compute — inside the TEE trust boundary, so that stateful data is stored confidentially rather than merely processed confidentially. Instead of treating the cloud as a distant encrypted database that a TEE reaches out to, execution and state are co-located inside processor-encrypted memory: query engines run within the TEE, and reads never cross an external network boundary.

This is the answer to a specific problem: how do you give a confidential-computing service long-term memory (recall across days/weeks, semantic search over a growing personal context) without reintroducing the very leak the TEE was built to close?

Why encrypting-then-storing-in-a-normal-DB is not enough

The obvious approach — encrypt user data on the device, store the ciphertext in a standard cloud database, pull it back into a TEE to query — fails on two counts (Source: sources/2026-09-24-meta-bringing-private-processing-to-meta-ai-glasses):

  1. Access patterns leak behavior. Even with strongly-encrypted contents, an external database still observes when you read and write, how frequently you query, and which records are accessed together. That metadata alone maps a daily routine and behavioral patterns. As Meta puts it: "Encryption protects payload content; it does not hide execution patterns." This is the same class of leak that motivates oblivious RAM and private information retrieval — encryption of the payload does not hide the shape of access.
  2. Remote encrypted queries do not scale. Running semantic vector search or multi-session joins over traditional encrypted storage means pulling massive ciphertext payloads out of the DB, transferring them across the network into the TEE, and decrypting them just to run a single query. As a user's context grows, latency spikes and performance collapses — the ciphertext-shuffling cost is proportional to the data, not the query result.

The resolution

Extend the trust boundary from compute to state:

  • The storage engine runs inside the TEE (across CPU and GPU where the boundary spans both).
  • Data remains encrypted, accessible only from within the TEE.
  • Persisted output is encrypted with a user-provided key before it ever leaves the TEE; the provider stores only ciphertext and cannot decrypt it. Retrieval requires the device to supply the key, at which point the TEE decrypts and processes the query internally.
  • Because reads stay inside processor-encrypted memory, read/write transactions are fast and access patterns are not observable to the operator.

Meta frames it as: "Instead of treating the cloud as a distant database, stateful Private Processing on demand co-locates execution and state inside processor-encrypted memory."

When you need it

The moment a confidential-computing service moves from discrete, stateless tasks (summarize this one message) to stateful, personalized experiences (recall a moment from earlier, pick up across sessions, connect ideas across weeks), payload-only encryption is insufficient — the access-pattern leak and the encrypted-query-scaling wall both bite. This is precisely the transition Private Processing makes when extended from WhatsApp AI to always-on AI glasses.

What it does not solve

  • Side-channel risk on the TEE itself persists (concepts/side-channel-attack); confidential storage rides on the same hardware boundary and inherits its residual risk. Defence-in-depth still applies.
  • User-key management becomes load-bearing — if the user-provided key is lost the ciphertext is unrecoverable; if it is compromised the storage confidentiality is defeated. The article states the property but not the key-lifecycle mechanism.

Seen in

Last updated · 766 distilled / 2,225 read