How does it work?
A virtual HSM combines enclaive Vault key, identity and access management with Nitride workload identity access management in a single service with hardware graded security and confidential buckypaper virtualization tailored to the private, hybrid multi-cloud settings.
Buckypaper Virtualization
In the cloud context, the atomic execution environment is considered to be a Virtual Machine (VM). A VM is an isolated, self-contained environment that provides the abstraction of a full-fledged physical machine. It runs on top of a hypervisor, which virtualizes the underlying hardware resources. VMs offer strong isolation, as each VM has its own operating system, file system, and network stack. This makes them an atomic unit of execution because they encapsulate everything needed for an application to run, independent of other VMs on the same physical server.
Buckypaper VMs shield the workload in an execution environment and ensure both confidentiality and integrity of the execution. This means that at all times, the data and code must remain encrypted and safeguarded from unauthorized modifications, whether in memory, on a storage volume, or during network communication. The service can only be fully protected from threats if these measures are consistently applied throughout the entire lifecycle of key management, identity management, and access control.
Achieving Confidentiality - Principals of 3D encryption
Technically confidential "buckypaper" virtualization is realized by combining encryption technologies in all three dimensions, such that the idea of a confidential execution environment becomes feasible:
Data at rest encryption refers to data that is stored in a persistent state on disks or cloud storage systems. In cloud environments, this can include block volumes, files, databases, or backups stored on cloud infrastructure. It is worth mentioning that the encryption occurs within the buckypaper VM (in contrast, CSPs apply encryption outside the encryption with full access to the key).
Data in transit refers to data being transferred between different systems, networks, or locations. Protecting this data from interception or tampering during transmission is crucial, particularly in cloud and multi-cloud environments where data frequently travels between on-premises systems, cloud storage, and cloud applications.
Data in use refers to data that is actively being processed by applications or systems. Traditional encryption mechanisms secure data at rest or in transit, but once data is loaded into memory for processing, it is usually decrypted, leaving it vulnerable to attacks. Confidential computing addresses this critical gap by ensuring that data remains encrypted even while being processed.
Why Encryption at All Three Stages is Critical in the Cloud
In cloud environments, data moves through multiple stages—rest, transit, and use—making it vulnerable to various types of attacks at each stage. Encrypting data across these three stages ensures full fledge end-to-end security, but each stage presents its own unique challenges:
At Rest: Without encryption at rest, unauthorized individuals could access stored data through physical breaches, misconfigurations, or internal attacks.
In Transit: Without encryption in transit, data moving across networks can be intercepted or altered, compromising both security and integrity.
In Use: Without encryption during use, sensitive data can be exposed during processing, leading to risks like memory scraping or unauthorized access from cloud administrators or attackers exploiting vulnerabilities.
Buckypaper virtualization is designed with the premise that no key material leaks the enclave in clear text. To this end, buckypaper virtualization relies on hardware graded trust anchors embodied on the SOC of the CPU (sometimes referred to as the security processor).
Achieving Integrity - Principals of Attestable Boot
Attestable Boot (also known as Measured Boot or Trusted Boot) is a process that ensures the integrity of the system's boot sequence. It verifies that every component in the boot chain—from firmware to the vault and nitride application—has not been tampered with, providing cryptographic evidence of the integrity of each step.
There are many variants of attestable boot, all of them have in come to measure the integrity of the code base loaded into the VM, deriving or unsealing a secret to boot sensitive or confidential data. In the following, we explain Attestable Boot based on raw attestation (see above illustration).
When the VM is started, a memory region is selected that is known to be memory-encrypted (step 1). This region serves as a protected area for sensitive operations during the boot process, ensuring that even as the VM is loading, memory remains secure and encrypted.
During the boot process, the Security Processor (SP) measures the UEFI firmware (step 2a). This involves taking a cryptographic hash of the firmware’s state. This measurement ensures the firmware has not been tampered with. If the hash deviates from the expected value, the boot process fails, signaling an untrusted state.
After the UEFI firmware is verified, it loads the next component, the kernel (step 2b). The UEFI is pre-programmed with a verification key that checks the signature of the kernel to ensure it is legitimate and untampered. If the kernel passes this verification, the boot process proceeds. This step guarantees that only trusted kernel modules are loaded into the enclave memory, preventing any malicious software from running at the most fundamental levels of the OS.
One of the kernel modules loaded during the boot sequence is the disk/volume encryption engine (step 2c). This module is responsible for unmounting the encrypted user space volume, which contains critical components of the application, such as vault, nitride, configuration files or secrets.
At this point, the Security Processor derives a cryptographic binding/sealing key from the measured state and the identity of the CPU. The key can have two important properties depending on the input parameters used in its derivation:
Platform Binding: The key can be bound to the specific hardware platform, meaning that the data (Vault, Nitride binaries, configurations, and secrets) can only be decrypted and used on that specific machine. If attempted on any other machine, the key is useless.
Key Sealing: Alternatively, the key can be derived in a way that seals it to the specific trusted boot state of the machine. If the machine’s configuration changes or the attestation fails, the sealed data cannot be decrypted.
This ensures that the user space volume is only accessible in a trusted environment where the boot process has been fully attested, and the machine has been verified as secure.
Once the vHSM services start running, they write data to the encrypted user space volume. Importantly, the data is encrypted before leaving the VM's enclave, meaning that sensitive data remains protected not only during storage (at rest) but also during its transmission out of the secure environment (step 3). This ensures that all data written persistently—such as configurations, secrets, and application data—is fully encrypted, and unauthorized access is prevented. Even in a cloud environment, this protects the data from unauthorized access or tampering.
Why attestable Boot is Critical in the Cloud
In cloud environments, infrastructure cannot be implicitly trusted—whether due to shared tenancy, complex supply chains, or insider threats. Technologies like Confidential Computing protect workloads by encrypting data in use, but encryption alone is insufficient without proof of a secure system state.
Attestable Boot, combined with remote attestation, addresses this gap. It provides cryptographic evidence that a machine booted from a trusted software stack, free from tampering. This ensures that sensitive workloads are deployed only within verified, secure environments—a foundational requirement for secure cloud computing.
Trusted Compute Base Verification: Attestable Boot ensures the VM or bare-metal instance launches from a known and verifiable Trusted Compute Base (TCB). Remote attestation allows external systems to cryptographically verify that firmware, bootloader, and kernel are untampered prior to workload execution.
Mitigation of Boot-Time Attacks: Without attestable boot, attackers can manipulate early boot stages (e.g., via bootkits or compromised hypervisors). Combined with confidential computing, attestable boot prevents execution of unmeasured or unauthorized code, closing attack vectors before memory encryption even activates.
Integrity-Protected Confidential Workloads: Confidential Computing protects memory, but its security guarantees depend on launching workloads from a verified and measured environment. Attestable boot provides those measurements, ensuring that sensitive workloads are decrypted and executed only within a trusted VM state.
Enabler for Remote Attestation and Zero Trust: Attestable boot generates cryptographically signed measurements consumed via remote attestation APIs (e.g., AMD SNP attestation service). This mechanism allows external systems to enforce Zero Trust policies—validating compute environments before releasing secrets, credentials, or sensitive workloads.
Regulatory Compliance and Auditability: Proving secure boot states via attestable boot supports compliance with standards like GDPR, C5, ISO 27001, and NIST 800-53. Attestation reports serve as auditable evidence that workloads execute only on verified, uncompromised infrastructure.
Last updated
Was this helpful?