Encryption protects data at rest and in transit. Confidential computing protects data while it is being processed. That is the gap most encryption strategies do not address.In a conventional cloud deployment, data is decrypted in memory when the application processes it. The hypervisor, the host OS, and any privileged administrator with access to the underlying infrastructure can — in theory — read that plaintext data while processing is occurring. For most workloads, the trust model makes this acceptable. You trust Microsoft’s infrastructure. The threat model does not include a compromised hypervisor. For specific financial workloads — algorithmic trading models, regulatory stress test calculations, key derivation for payment cryptography — the threat model does include insider threat at the infrastructure layer. For those workloads, confidential computing changes what is possible:
The Processing Gap in Cloud Encryption
Encryption at rest protects data when it is stored. Encryption in transit protects data as it moves. Both are well understood and broadly implemented. The gap that confidential computing addresses is what happens in between: when the application decrypts the data and processes it in memory, that plaintext data exists in the CPU’s memory registers and in the guest OS memory space.
In a conventional virtualized environment, the hypervisor manages memory allocation for all guest VMs. A hypervisor with full access to the hardware could, in theory, read the guest VM’s memory. So could a host OS administrator. So could certain categories of hardware vulnerabilities. For most workloads, this is an acceptable risk because the trust model extends to Microsoft’s infrastructure operations. For specific workloads, it is not.
How AMD SEV-SNP Works
AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) encrypts the VM’s memory using a key that is generated by the AMD security processor and is never accessible to the hypervisor or host OS. Even with full physical access to the host, the guest VM’s memory cannot be decrypted without the key that exists only inside the AMD security processor.
Azure’s DCasv5 and ECasv5 VM series are built on AMD SEV-SNP. Workloads running on these VM sizes have hardware-enforced memory encryption that the infrastructure operator cannot circumvent.
Attestation — Proving the Enclave Is Genuine
Memory encryption alone does not prove the code running inside the enclave is the intended code and has not been tampered with. Attestation provides that proof. The AMD security processor generates a signed report that describes the current state of the enclave: the code that was loaded, the configuration it was launched with, and the security policy it is running under. A relying party — another service that needs to share data with the enclave — can verify this attestation report before sending sensitive data, confirming they are communicating with the genuine, unmodified application.
Trusted Launch — The Baseline for Every VM
Trusted Launch is available on all Azure generation 2 VMs and should be the default for every workload, not just those requiring full confidential computing. It provides: Secure Boot (only code signed by trusted authorities can execute during the boot sequence), a virtual TPM (cryptographic keys sealed to the boot state, so keys become unavailable if the boot sequence is tampered with), and Measured Boot (a cryptographic log of every component loaded during boot, stored in the vTPM for integrity verification).
Enable Trusted Launch on all new VM deployments through Azure Policy. The boot integrity log from the vTPM is available in Defender for Cloud and can be used to detect tampering with the boot sequence.
Which Workloads Genuinely Need Confidential Computing
Confidential computing is not the right choice for every workload. The additional complexity — attestation infrastructure, enclave-aware application development, performance impact of memory encryption — is only justified when the threat model explicitly includes infrastructure-layer insiders or when regulatory requirements mandate it.
Financial workloads where it is genuinely required: proprietary trading algorithms where the code itself is the competitive asset, key derivation functions for payment cryptography where key exposure at the infrastructure level would be catastrophic, and multi-party computation scenarios where organizations need to jointly compute on data neither party should fully disclose to the other.
Be the first to comment
Leave a Comment
💡 Comments are reviewed before publishing.