Confidential Computing: Data-in-Use Protection & Limits

Confidential computing protects data while it is being processed—the one state traditional encryption leaves exposed—by running computations inside a hardware-based trusted execution environment (TEE). It encrypts memory in real time so that even the operating system, hypervisor, or cloud provider cannot read the data or the code being executed. This article explains how that protection works, where it genuinely helps, and where it falls short in practice.

Background: The Three States of Data

Security professionals divide data into three states: at rest (stored on disk), in transit (moving over a network), and in use (being processed by a CPU). Encryption has long protected the first two—AES for storage, TLS for network traffic—but data in use has historically been plaintext inside memory. Any compromise of the operating system, a rogue administrator, or a malicious hypervisor could read that memory directly. Confidential computing closes this gap by isolating the computation into a secure enclave, a protected region of memory that is encrypted by the CPU itself.

The concept emerged from academic research in the 2000s and became commercially available with Intel SGX in 2015, followed by AMD SEV and ARM TrustZone. Cloud providers now offer confidential computing as a service, making the technology accessible without owning specialized hardware.

How It Works: Trusted Execution Environments

A TEE is a hardware-enforced isolation mechanism. The CPU contains a unique key burned into the chip, which encrypts the enclave’s memory. When data enters the enclave, it is decrypted only inside the processor package; when it leaves, it is re-encrypted. This prevents any software outside the enclave—including the host OS—from reading it.

Key components include:

• Enclave: A protected region of memory with its own code and data.
• Attestation: A cryptographic proof that the enclave is genuine and running the expected code.
• Sealing: Encrypting data to a specific enclave so it can only be decrypted by that same enclave on the same machine.
• Memory encryption: Per-page keys managed by the CPU, preventing bus sniffing and cold-boot attacks.

When an application runs inside an enclave, the CPU encrypts the entire memory footprint, including the code, stack, and heap. The OS still manages scheduling and I/O, but it cannot inspect the enclave’s contents.

Real-World Use Cases

Confidential computing is not a general-purpose security tool; it solves specific problems where data sensitivity meets untrusted infrastructure.

• Multi-party computation: Multiple organizations can jointly train a machine learning model or compare datasets without revealing their raw data to each other.
• Regulated cloud workloads: Healthcare and financial institutions can move sensitive workloads to the cloud while meeting compliance requirements that mandate encryption of data in use.
• Protecting intellectual property: Algorithm owners can run proprietary code on a client’s machine without exposing the code itself.
• Blockchain oracles: Sensitive data can be processed off-chain in an enclave, with attestation proving the result is correct.

For example, a consortium of banks might want to detect fraud without sharing customer records. Each bank sends encrypted transactions into a shared enclave, which computes a fraud score and returns only the aggregate result. No bank sees another’s data, and the enclave’s attestation proves the computation ran as agreed.

How to Choose: TEE Types and Trade-offs

Selecting a confidential computing approach depends on threat model, performance, and portability.

• Intel SGX: Offers fine-grained enclaves within an application, but has limited memory (typically 128–512 MB per enclave) and has faced side-channel attacks. Good for small, security-critical functions.
• AMD SEV: Encrypts entire virtual machines, so no application changes are needed. Easier to deploy but provides less granular isolation; the hypervisor is still trusted for some operations.
• ARM TrustZone: Divides the CPU into secure and normal worlds, often used in mobile and IoT devices. Requires custom firmware and is less flexible for cloud workloads.
• NVIDIA Confidential Computing: Extends TEEs to GPUs, enabling encrypted processing of large machine learning models. Useful for AI workloads but requires specialized hardware.

Consider whether you need to protect a whole VM (SEV) or a specific function (SGX), and whether your code can be modified to run in an enclave. Also check whether your cloud provider offers the TEE you need.

Common Problems and Limitations

Confidential computing is not a silver bullet. Several practical limitations reduce its effectiveness.

• Side-channel attacks: Even with memory encryption, an attacker with local access can infer data from timing, cache behavior, or power consumption. Spectre and Meltdown demonstrated that CPU microarchitectural leaks can break enclave isolation.
• Performance overhead: Encryption and attestation add latency. Memory-heavy workloads can see 5–20% slowdowns, and context switching into enclaves is expensive.
• Limited memory: SGX enclaves are capped at a few hundred MB, making large datasets impractical without careful partitioning.
• Trusting the hardware: The entire security model rests on the CPU manufacturer’s key and the correctness of their implementation. A hardware backdoor or a compromised supply chain would defeat the protection.
• I/O and peripherals: Data must be decrypted to interact with GPUs, NICs, or storage controllers, creating attack surfaces outside the enclave.
• Attestation complexity: Verifying an enclave’s identity requires a trusted attestation service, which adds a dependency and potential point of failure.

Costs and Practical Considerations

Adopting confidential computing involves more than just buying new hardware. The costs include:

• Hardware: CPUs with TEE support (e.g., Intel Xeon Scalable with SGX, AMD EPYC with SEV) are more expensive than standard models.
• Cloud premiums: Cloud providers charge a premium for confidential VM instances, often 10–30% more than regular instances.
• Development effort: Applications must be rewritten to use enclave APIs (e.g., the SGX SDK) or run in a VM with SEV, which requires careful configuration.
• Operational overhead: Managing attestation, key rotation, and enclave lifecycle adds complexity to DevOps.

For many organizations, the cost may outweigh the benefit if the threat model does not include a malicious cloud provider or insider. If you are simply protecting against external hackers, traditional encryption and access controls may suffice.

Safety and Security Best Practices

When using confidential computing, follow these guidelines to maximize security:

• Verify attestation: Always verify the enclave’s attestation report against a trusted service before sending sensitive data.
• Keep enclaves small: Limit the code inside the enclave to the minimum necessary; larger attack surfaces increase risk.
• Update firmware: TEE security depends on microcode and firmware patches. Apply updates promptly.
• Use memory encryption: Ensure the TEE actually encrypts memory; some implementations may leave parts of the address space unencrypted.
• Monitor for side channels: Run workloads on dedicated hardware and avoid sharing physical hosts with untrusted tenants.

Alternatives to Confidential Computing

If confidential computing seems too heavy, consider these alternatives for protecting data in use:

• Homomorphic encryption: Allows computation on encrypted data without decryption, but is extremely slow and limited to specific operations.
• Secure multi-party computation (SMPC): Distributes computation across multiple parties so no single party sees the full data, but requires heavy network communication.
• Trusted platform modules (TPM): Provide hardware root of trust for boot and disk encryption, but do not protect memory during computation.
• Zero-knowledge proofs: Prove a statement is true without revealing the data, but cannot perform general computation.
• Data minimization: Simply avoid processing sensitive data in the first place—an often overlooked but effective strategy.

Frequently Asked Questions

Does confidential computing protect against all attacks? No. It protects against software attacks that attempt to read memory from the OS or hypervisor, but it does not protect against side-channel attacks, hardware tampering, or bugs in the enclave code itself.

Can I use confidential computing on my existing applications? It depends on the TEE. AMD SEV can encrypt whole VMs without modification, but Intel SGX requires code changes to use the enclave SDK. Check your hardware and cloud provider’s support.

Is confidential computing the same as homomorphic encryption? No. Homomorphic encryption allows computation on encrypted data without ever decrypting it, but is very slow. Confidential computing decrypts data inside a hardware-protected enclave, which is faster but requires trusting the hardware.

How do I know my cloud provider isn’t lying about using confidential computing? You can verify through attestation—the enclave provides a cryptographic proof signed by the CPU that the code is running as expected. This proof can be checked independently.

What happens if the CPU is physically compromised? If an attacker has physical access to the chip, they could potentially extract the root key or tamper with the hardware. Confidential computing assumes the hardware is trusted; it protects against software attacks, not physical ones.

Does confidential computing work with GPUs? Yes, but only with specific hardware like NVIDIA’s confidential computing offerings. Standard GPUs do not have TEEs, so data must be decrypted before being sent to the GPU, creating a vulnerability.

Related

• IPS Monitors and Eye Comfort: What Panels Can and Can’t Do
• Stellar Phoenix Data Recovery Alternatives
• Mac Data Safety at the Genius Bar: What to Know

in t | Time in TEE (minutes) | min | 10 | 0
in m | Memory encrypted (GB) | GB | 4 | 0
out cost | Approx. overhead (%) | % | 5 + 0.1 * m | 2