According to Gartner, worldwide end-user spending on public cloud services is forecast to grow 20.4% to $678.8 billion in 2024, up from $563.6 billion in 2023. Companies are increasingly migrating their business data and applications to public cloud environments, attracted by the cost-effective and robust computing resources offered in the form of virtual machines (VM). Additionally, some public cloud platforms provide highly appealing services, such as artificial intelligence (AI) APIs, enabling the development of innovative business applications.
The cloud offers many benefits, including cost optimization, dynamic scaling, higher stability, etc. Despite these benefits, many companies are not migrating due to concerns about the security of their applications and data. The move to public cloud environments introduces the possibility of additional security threats originating from other cloud tenants and potentially untrustworthy or insecure cloud providers.
In this article, we’ll describe the key components of a full disk encryption (FDE) solution that uses Intel® Trust Domain and Intel® Trust Authority to protect a storage device and encryption key throughout its entire lifecycle with disk encryption, key registration, key broker service, and an early-boot FDE agent. With these components, you can protect the sensitive data on your storage devices from security threats in the public cloud environment.
Full Disk Encryption
Full disk encryption is a robust security measure for safeguarding the contents of digital storage devices, including hard drives, SSDs, and virtual disks for VMs, through seamless encryption. This protective shield extends to applications, user files, and even the OS. The core objective of FDE is to thwart unauthorized access to sensitive information, particularly in scenarios involving device theft, loss, or unauthorized physical access.
The mechanics of FDE involve the utilization of a cipher, typically a block cipher, to encrypt data at rest on the storage device. To initiate the process, a user or device manufacturer must initialize the storage device by providing an encryption key or passphrase. This action creates and writes a special metadata structure on the device, representing an initially empty state encrypted with the provided key. As a precaution against space analysis attacks, the initialization process includes completely overwriting the device with random noise [1].
FDE implementation can take either a hardware or software-based approach. Hardware-based FDE typically involves a dedicated encryption chip, while software-based FDE relies on encryption software operating at the OS level. Standard block cipher constructions and modes of operations such as AES-GCM-256 are commonly employed in the implementation process. Examples of software-based FDE solutions include BitLocker for Windows, FileVault for macOS, and LUKS for Linux.
FDE Key Protection
In classical computing, data exists in three states during the computing lifecycle: in transit, at rest, and in use [2]. Data traversing the network is in transit, data in storage is at rest, and data being processed is in use. Like a disk device or disk image, the encryption key is a type of sensitive data, and its confidentiality and integrity should be protected across the three states mentioned above.
Each time the system powers on or the device is accessed, a key or a passphrase is needed to decrypt and read or write data on the device. This key is not stored on the device itself and must be provided for every device use. It is typically cached in a volatile and protected memory area and erased when the device is no longer in use, or the system is shut down.
Traditional key storage and management solutions are based on a hardware security module (HSM) or trusted platform module (TPM) but are expensive and don't scale well. Another choice is a third-party key management service (KMS), which can generate the encryption keys and perform cryptographic operations by following the Federal Information Processing Standard (FIPS) 140 series.
Confidential computing is designed to protect sensitive data during processing through hardware-based trusted execution environments (TEE) [3] such as Intel® Trust Domain Extensions (Intel® TDX), AMD Secure Encrypted Virtualization-Secure Nested Paging (AMD SEV-SNP), and Arm Realm Management Extension (Arm RME). These and most other hardware-based TEEs provide a chain of trust for measurement and remote attestation.
Intel TDX includes a new kind of virtual machine guest called a trust domain (TD), which runs in a CPU mode designed to protect the confidentiality and integrity of its memory contents and CPU state from any other software, including the hosting virtual machine monitor (VMM). The TD’s memory is encrypted by the CPU and can’t be accessed by any other software, so it’s safe to put sensitive data, such as FDE keys, into the TD’s memory.
Figure 1 Intel® Trust Domain
Remote attestation is also an important part of key transmission. In the cloud-native environment, a cloud broker is an intercloud computing entity, providing a single entry point for resource management, service discovery, and service-level agreement negotiation between service provider(s) and customer(s). A key broker service (KBS) can be designed as a stateless cloud broker service to enforce remote attestation, verify the key transferring policies, obtain a key from KMS, and wrap the key before transit. KBS is a relying party as defined in the IETF RATS specification.
Architecture Design
A bootstrapping challenge arises when an OS is protected by a software-based solution because the OS cannot run natively while encrypted. This problem is addressed by incorporating a small, unencrypted bootloader that launches a minimal FDE application before the rest of the OS starts. In a presentation at the 2022 Linux Plumbers Conference,, we described two types of boot disk decryption: pre-boot disk decryption and early-boot disk decryption. In a pre-boot disk encryption architecture, the open virtual machine firmware (OVMF) serves as the unencrypted bootloader to decrypt the entire disk. The implementation at the firmware level is complicated.
Figure 2 shows an overview of the early-boot disk decryption architecture. The boot partition is unencrypted, and an agent in initrd is responsible for requesting the key and decrypting the root file system partition.
Figure 2 Early-boot disk decryption
We have developed an early-boot FDE solution that includes disk encryption, key registration, and an FDE agent running in the TD to request the key from a KBS after remote attestation. The sequence is illustrated in Figure 3. Each component and the flow will be explained in the following sections.
Figure 3 Full disk encryption architecture
Disk Encryption
AES-GCM is a widely used block cipher mode for securing data, particularly in network communications (data in transit) and data storage (data at rest). It combines two important cryptographic techniques: advanced encryption standard (AES) and Galois/Counter Mode (GCM). AES is a symmetric encryption algorithm that uses a shared secret key for both encryption and decryption. GCM is based on a combination of CTR and GMAC, a combination that ensures that the data is encrypted, and that it includes an authentication tag that allows the recipient to verify the integrity of the data.
The key features and benefits of AES GCM include confidentiality, data integrity, and authentication. The initialization vector is a random value used alongside the encryption key to initialize the encryption process, and the authentication tag is a small piece of data generated during encryption and appended to the ciphertext.
The Linux Unified Key Setup (LUKS) is a disk encryption specification that implements a platform-independent standard on-disk format for use and provides FDE by encrypting the root partition of an OS. The LUKS2 specification supports all algorithms provided by the cryptographic backend, including AES-GCM.
Figure 4 shows an early-boot FDE disk partition example.
Figure 4 Disk partition FDE example
Key Registration
After encrypting the disk, the key should be registered with KBS, which guards the key release process with an additional security check (through attestation). KBS will be discussed in detail in a later section.
Here’s a typical key registration flow:
- Connect to the KBS with authentication information to get an authorization token.
- Create a key transfer policy with the token. The policy should include the attestation type and policies.
- Register the key with the key transfer policy ID.
- Enroll the KBS URL, KBS certificate, and key ID to OVMF as extensible firmware interface (EFI) variables.
After the key registration process is complete, the KBS should handle the attestation process for a client to retrieve the key.
FDE Agent for Key Retrieval
In the early-boot stage, the FDE agent resides in the initramfs and is launched by the init process to mount an encrypted root partition. The workflow of the FDE agent can be partitioned into four steps:
- Retrieve the KBS URL, KBS certificate, and key ID from the EFI variables.
- Get the attestation quote.
- Retrieve the key using the key ID of the encrypted root partition from the KBS.
- Decrypt the encrypted partition and mount it as the guest root filesystem.
Key Broker Service (KBS)
KBS is a critical component of the FDE solution. It facilitates the key registration process and key retrieval process from the FDE agent.
KBS acts as a key broker between an existing KMS and a client (e.g., the FDE agent) by requesting keys and evaluating additional key transfer policies. One example would be a key transfer policy that requires a client to go through attestation, demonstrating that it is running in a TEE such as Intel® Software Guard Extensions (Intel® SGX) or Intel TDX. Intel Trust Authority, which we describe in detail below, can provide attestation.
Sample KBS Implementation Workflow
When releasing a key after evaluating the key release policy, KBS wraps the key with a client-owned public key. A sample workflow for a simple KBS implementation is as follows:
- Accept a quote and a public key from the client.
- Verify the quote, perform attestation, and return the verification status.
- Get the user key from the KMS and generate a symmetric wrapping key (SWK) to encrypt the user key (wrapped key).
- Encrypt the SWK using the public key from the client (wrapped SWK).
This example shows how the key broker client gets a key from KBS:
- Generate a 2048-bit RSA key pair (public and private keys).
- Encode the public key to base64 for transferring (measured as user data).
- Get a quote in the TEE with the hash of the public key for measurement (quote).
- Request a wrapped key and wrapped SWK from the KBS with quote and user data.
- Decrypt the SWK using the RSA private key.
- Decrypt the user key using the SWK.
Intel® Trust Authority
In this FDE solution, remote attestation should be verified by a third-party service to ensure the FDE agent is running in a TD guest. Intel® Trust Authority [4] is a SaaS-based attestation service developed by Intel to provide remote verification of the trustworthiness of a compute asset based on policy. Starting with an Intel TEE, it may expand to provide broader device verification, including IPUs, GPUs, platform roots of trust, and more. It is architected as a cloud native microservice platform running on a managed Kubernetes service, with appropriate abstractions on different cloud infrastructure platforms, such as on-prem and edge locations. After verification is complete, the user will receive the Intel Trust Authority’s endorsement regarding the remote platform's validity and corresponding trust level.
Figure 5 Intel® Trust Authority
Conclusion
FDE is a classical solution for protecting data when it is moved to the cloud. However, the disk decryption key should also be protected at rest, in transit, and in use. In this article, we present a solution that can protect the key throughout its entire lifecycle with an early-boot FDE agent and other technologies. Intel TDX provides a TD where a VM can run in the cloud with memory protection. Through attestation by Intel Trust Authority, the VM can be identified running inside a TD, such that the decryption key can be released to the trusted environment. KBS manages the key and its policy to protect it at rest and only releases the key wrapped (in transit) to a workload running inside a verified trusted domain.
Notices and Disclaimers
The approach and implementation of FDE can be found in the Linux Reference Stack. For details, see Whitepaper: Linux* Stacks for Intel® Trust Domain Extension 1.0.
About the Authors
Haidong Xia is a principal engineer at Intel and lead architect for Intel Trust Authority. He also manages an architecture team. Haidong has been working in security for 20+ years, with experience in cloud and full stack of a platform.
Ken Lu is a cloud native software architect at Intel, focused on confidential computing technology enabling and adoption on Kubernetes framework for confidential cluster, containers, etc. He initiated several open source projects like CCNP(Confidential Cloud Native Primitive) and CNAP (Cloud Native AI Pipeline).
Xiaocheng Dong is a cloud software engineer at Intel and specializes in developing software stacks of confidential computing technologies like Intel SGX and Intel TDX. He is skilled in confidential computing and zero-trust solutions in the cloud-native environment.
Yanhui Zhao is a cloud software architect at Intel, working on enabling differential security solutions based on Intel hardware. He has worked on TEE technologies across different platforms and architectures and has driven several related product and service launches over the past few years.
Harshitha Gowda is a cloud software engineer at Intel, specializing in key management services. She is currently a software developer for Intel Trust Authority and contributes to the Key Broker Service. Her expertise in cloud computing and key management services ensures the security and reliability of key management processes.
References
- E. Anzuoni and T. Gagliardoni, Shufflecake: Plausible Deniability for Multiple Hidden Filesystems on Linux, IACR's Eprint, 2023.
- A Technical Analysis of Confidential Computing, Confidential Computing Consortium, 2022.
- Intel, "Intel® TDX White Papers," February 2023. [Online]. Available: https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/documentation.html.
- Intel, "Intel® Trust Authority," [Online]. Available: https://docs.trustauthority.intel.com/main/articles/introduction.html.