Secure VM

Large data centers rent out computing power to many customers at once. So that these customers don’t get in each other’s way, each one is assigned an emulated computer: a virtual machine. It behaves like its own machine with its own operating system, but exists only as software on shared hardware. A Secure VM is such a virtual machine with an additional property: its working memory is encrypted, and the key is held by a special component inside the processor. Even the data center’s management software therefore cannot read what is currently being computed inside this machine. The operator provides the computing power but sees only unreadable gibberish.

Computing at a place you don’t fully trust

With normal virtual machines, an uncomfortable truth is on the table. The management layer that starts and stops the machines has full access to their memory. Whoever controls this layer can read every line. So one has to trust the provider, its administrators, and anyone who steals their credentials.

For many applications this is not a problem. For others it is. A hospital with patient data, a bank with account transactions, or a government agency with tax records often cannot simply hand this data over to a third-party data center. Laws such as the General Data Protection Regulation require concrete protective measures. A Secure VM is one such measure that can be technically verified.

In the AI world there is a second reason. A trained model is often a company’s most valuable asset and ultimately consists of nothing more than one large file. Whoever copies it has been handed months of work for free. Companies that operate their models in third-party data centers are therefore increasingly using shielded machines. Conversely, customers want to be sure that the texts they enter are not being captured anywhere.

Encrypted memory and a proof of authenticity

The technology is built into the processor itself. Modern server chips from AMD, Intel, and ARM have a small, separated security area built in. This area generates a unique key for each Secure VM. Everything the machine writes to working memory is encrypted as it is written out and decrypted again when read back in. This happens in hardware and costs barely measurable time.

The key never leaves the processor. The management software may continue to start and stop the machine and allocate it computing time. But it sees only the encrypted memory contents. One can picture this like a safe in a rented storage unit: the landlord controls the building and knows how heavy the safe is, but cannot get inside it.

A second component is just as important and is called attestation. The Secure VM can issue a digitally signed report. It states which chip type it is running on and which software was started. The customer checks this report before sending their data. Without this proof, the encryption would be worthless, since no one could tell whether the machine is really protected or merely claims to be.

What cloud providers sell under this name

In the price lists of Amazon, Microsoft, and Google, the technology appears under names such as Confidential Computing or Confidential VM. It is booked like an ordinary virtual machine, but usually comes with a small surcharge. The underlying methods are called AMD SEV-SNP, Intel TDX, or ARM CCA. For users, little changes in day-to-day use; the operating system runs unchanged.

It is important to distinguish this from a related term. A Trusted Execution Environment in the narrower sense, such as Intel SGX, shields only individual parts of a program and requires rewritten software. A Secure VM, by contrast, protects the entire machine including the operating system. This is more convenient, but the protected surface is larger, and a security flaw in the operating system does not benefit from the encryption.

A common misconception is that a Secure VM makes applications inherently secure. It does not. It protects against the environment, that is, against operators and other customers on the same hardware. It does not help against a poorly secured password or a programming error in one’s own application. And one must trust the chip manufacturer, since it issues the certificates on which attestation is based.