What is Virtual HSM?
In today's rapidly evolving digital landscape, securing sensitive data and controlling access to critical systems are top priorities for organizations of all sizes. Key, Identity, and Access Management (e.g. Azure Entra ID, Google Cloud KMS) forms the cornerstone of cybersecurity strategies, ensuring that the right individuals and systems have appropriate access to resources, while unauthorized users are kept at bay. Effective IAM practices are crucial for maintaining the confidentiality, integrity, and availability of data across distributed environments, such as cloud services, on-premise infrastructures, and hybrid models.
Role of Key, Identity and Access Management in Cloud Security
At the core of Identity and Access Management (IAM) is the ability to verify and authenticate users, assign roles and permissions, and manage user identities throughout their lifecycle. By combining IAM with strong key management practices and leveraging tools like HSMs and BYOK, organizations can build a robust security framework that ensures secure access to systems and data, reduces the risk of unauthorized access, and simplifies the enforcement of regulatory compliance.
Central to IAM is the concept of key management, which involves generating, distributing, storing, and rotating cryptographic keys that safeguard data. Proper key management ensures that encryption keys are protected against unauthorized access, preventing data breaches and unauthorized decryption of sensitive information. The loss or compromise of a key can lead to devastating consequences, making it essential for organizations to implement stringent key management practices.
Hardware Security Modules (HSMs) play a critical role in enhancing the security of key management. HSMs are physical devices designed to generate, store, and protect cryptographic keys in a tamper-resistant environment. They provide a higher level of security compared to software-based key storage, as they safeguard keys from external threats and insider attacks. HSMs ensure that cryptographic operations are executed in a secure environment, making them indispensable for organizations that need to comply with stringent regulatory requirements, such as financial institutions and government agencies.
With the proliferation of cloud services, organizations increasingly seek control over their cryptographic keys in cloud environments. This is where the concept of Bring Your Own Key (BYOK) comes into play. BYOK allows organizations to maintain ownership and control over their encryption keys, even when using cloud service providers. Rather than relying on the provider to generate and manage keys, organizations can import their own keys into the cloud provider's infrastructure, ensuring that they retain full control over data encryption and access policies. This is particularly beneficial in highly regulated industries, as it enables compliance with data sovereignty laws and enhances trust in cloud-based systems.
Challenges
Deploying cloud-native applications introduces new challenges in key, identity, and access management, as well as key protection mechanisms such as Hardware Security Modules and Bring Your Own Key. These challenges become particularly pronounced in multi-cloud environments, where traditional solutions often fall short.
Some of the key problems include:
Single Point of Trust: Single Point of Trust: Organizations must ultimately trust the cloud service provider (CSP) to securely manage their keys and identity systems in a "take-it-or-leave-it" approach. This trust extends to the CSP’s internal personnel, including engineers, DevOps, and DevSecOps teams, who may have access to these systems. As a result, organizations must accept the potential risks associated with having multiple, often unknown, individuals who might gain access to their sensitive data and services.
Single Point of Attack: CSPs handle a vast number of clients, making them attractive targets for attacks, espionage, or compromise. In the past, targeting individual businesses required substantial effort and resources, but with the shift to cloud services, the economics of attacks have changed. Once attackers find vulnerabilities in a CSP's infrastructure, they can potentially gain access to multiple organizations at once. This was demonstrated in high-profile incidents like the STORM attack, where businesses suffered data breaches not because they were directly targeted, but because they were collateral damage of a larger attack on the CSP itself.
Single Point of Ecosystem: CSPs promote their extensive portfolios of managed services, creating a comprehensive ecosystem that often leads to vendor lock-in. As organizations increasingly adopt cloud solutions, they risk becoming overly dependent on a specific provider's proprietary tools, APIs, and architectures. This dependency makes it difficult and costly to switch to other cloud platforms, limiting operational flexibility and long-term competitiveness. Although cloud platforms offer scalability and innovation, vendor lock-in can inflate costs, reduce adaptability, and prevent organizations from leveraging better technologies available from other providers.
Why “Bring Your Own Key” is Misleading in the Cloud
Bring Your Own Key allows organizations to generate and manage their own encryption keys and upload them to a cloud service provider for encrypting their data in the cloud. While this approach gives a sense of control, it has limitations that can make it less secure than it seems. The primary reasons why BYOK can be seen as misleading or inadequate in the cloud are:
Cloud Provider Control: Despite the idea of BYOK giving organizations control over their keys, once the keys are uploaded to the cloud provider, they are still managed by the provider's infrastructure. This means the cloud service provider still has significant access and control over key management, encryption processes, and underlying systems. While cloud providers claim that the keys are securely stored in Hardware Security Modules, the organization must still trust that the CSP’s administrators, internal teams, and service architectures do not have access to the keys or misuse them.
Key Access by Cloud Personnel: Even though cloud providers put security measures in place, there's always the risk of insider threats or vulnerabilities within the provider’s infrastructure. Administrators, engineers, or external actors with privileged access to cloud environments could potentially gain access to the encryption keys or the encrypted data, breaking the security perimeter intended by BYOK.
No Control Over Operational Processes: BYOK assumes that the cloud provider’s operational processes (e.g., backups, replication, or monitoring) are secure and flawless. However, organizations do not have visibility into how the CSP handles these processes. If a CSP needs to access encrypted data for backup or maintenance purposes, they could potentially decrypt the data using the provided key, compromising the entire security model of BYOK.
Shared Infrastructure Risks: Cloud services often run on shared infrastructure, where multiple clients’ data resides on the same physical hardware. Even if keys are separate, a breach at the hardware or hypervisor level could expose both the keys and the encrypted data. BYOK does not address these shared infrastructure vulnerabilities.
Virtual HSM: Hardware-grade Key, Identity Access Management in the Cloud
Confidential Computing is a technology designed to solve many of the security gaps that BYOK leaves open. It provides a more robust solution for protecting data in cloud environments, ensuring that sensitive data remains secure even from the cloud provider itself.
A Virtual Hardware Security Module (vHSM) provides the same secure key management, identity and access management as traditional physical HSMs but with the added benefits of cloud scalability, flexibility, and cost-effectiveness. These virtual HSMs are designed to protect sensitive cryptographic keys and perform secure operations, such as encryption, decryption, and digital signing, within a cloud environment.
By leveraging virtual HSMs, organizations can enhance their security posture without the need to manage physical hardware, ensuring compliance with strict regulatory requirements for data protection. As cloud adoption grows, virtual HSMs offer a practical solution for businesses looking to secure their cryptographic assets in a scalable, on-demand, and fully managed way, reducing the complexities associated with on-premise hardware.
Concepts
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 an 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.
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 Vault/Nitride 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.
Last updated
