Confidential Computing

From Kicksecure
< Dev
Revision as of 09:37, 5 October 2024 by Patrick (talk | contribs) (import from https://www.whonix.org/wiki/Dev/cloud)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Confidential computing is an advanced security technology that protects data while it's in use, complementing existing protections for data at rest and in transit. The goal is to isolate sensitive data from unauthorized access, even from the cloud provider or system administrators.

Introduction

Confidential computing is an advanced security technology that protects data while it's in use, complementing existing protections for data at rest and in transit. The goal is to isolate sensitive data from unauthorized access, even from the cloud provider or system administrators.

One use case of confidential computing are virtual machines that can be trusted to remain uncompromised even in the event the cloud provider is malicious. Confidential computing is difficult because, as per the development status of most operating systems, a malicious host machine is usually able to control the environment, including all VMs in its entirety.

There are two primary things that need to be shielded against in order for confidential computing to work: compromise of the host operating system/hypervisor, and compromise of the host hardware. Three separate methods must be used in combination to defend against these threats:

  • Encryption of virtual machine RAM and both physical and virtual machine disk. This is required to prevent data compromise in the event of an attacker gaining physical access to the hardware.
  • Isolation of host and guest kernels. A properly configured host must NOT be able to freely inspect virtual machine RAM or inject malicious commands into virtual machines.
  • Remote attestation. A user must be able to verify that the host is properly configured without having to trust the host.

The following related projects provide useful features towards confidential computing:

Components

Full Disk Encryption Key Proetction from Cold Boot Attacks

TRESOR

  • https://www.cs1.tf.fau.de/research/system-security-group/tresor-trevisor-armored/archive.org iconarchive.today icon
  • Provides full disk encryption capabilities using an encryption key that is stored only within CPU registers.
  • TRESOR is actually more performant than standard AES encryption.
  • When used on the host machine, it renders it impossible for a cold-boot attack to compromise disk encryption keys without being able to compromise the CPU's memory itself.
  • Similar advantages are conferred on guest VMs if their CPU registers are encrypted when saved to RAM.
  • Not yet present in the Linux kernel.

RAM Encryption

Intel TME-MK

  • https://www.intel.com/content/www/us/en/developer/articles/news/runtime-encryption-of-memory-with-intel-tme-mk.htmlarchive.org iconarchive.today icon
    • Provides granular, user-controllable full memory encryption. Multiple keys can be used at once, allowing a hypervisor to use one key for the host and different keys for each guest. The performance impact of using TME-MK is negligible (less than 2%).
      • Allows the use of tenant-provided encryption keys, which theoretically should prevent an attacker with access to Intel from compromising the keys.
      • Does not attempt to enforce guest/hypervisor isolation; the hypervisor must be trusted.
      • Only supports 128-bit AES encryption.

AMD SEV

  • https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/memory-encryption-white-paper.pdfarchive.org iconarchive.today icon
    • Encrypts VM memory to make VMs immune to memory-based attacks.
      • Attempts to provide host/guest isolation; however, this isolation is not bulletproof as the hypervisor's device emulation is free to provide malicious data to guest device drivers (same problem mentioned in https://x86.lol/generic/2023/06/28/intel-tdx-2.htmlarchive.org iconarchive.today icon, "With TDX, the attack surface includes all device drivers... All devices are fair game from the attacker’s perspective. The malicious VMM can craft problematic responses from any device, such as the PCI Configuration Space or VirtIO."). Thus, it remains critical that the hypervisor be trusted.
      • Only supports 128-bit AES encryption.
      • Scary, makes use of keys generated by AMD SEV firmware and does not appear to allow the hypervisor to specify the key to use.

RamCrypt

  • https://faui1-files.cs.fau.de/filepool/projects/ramcrypt/ramcrypt.pdfarchive.org iconarchive.today icon
    • Provides memory encryption for individual processes running under a Linux kernel. Fully software-based, uses TRESOR for encryption of RAM. Due to being software-based, RamCrypt must store process memory in a decrypted form when that memory is being actively used. Otherwise, the software using that memory would be unable to understand the memory contents. This means that sensitive data is occasionally exposed in cleartext in system memory, though it is later re-encrypted when no longer in active use. RamCrypt therefore *mitigates* cold-boot attacks, but does not *prevent* them. RamCrypt also comes with a very substantial performance hit (at least 25%, sometimes much more).
      • It may be possible to use no-fill cache mode (a.k.a. cache-as-RAM) to mitigate RamCrypt's shortcomings in this area. It is not yet known if this is possible, and it is very likely that doing so would come with an even greater performance hit. See https://frozencache.blogspot.com/archive.org iconarchive.today icon
      • Could be made to support 256-bit AES? The default implementation only supports 128-bit AES.

Kernel isolation

pKVM

  • https://source.android.com/docs/core/virtualization/architecturearchive.org iconarchive.today icon
  • https://lwn.net/Articles/836693/archive.org iconarchive.today icon
    • Provides separation of host and guest operating systems on arm64 platforms (specifically Android). Uses ARM virtualization features to install a portion of the KVM hypervisor in a higher-privileged area than the rest of the kernel, thus preventing the kernel from accessing the memory of, or interfering with the execution of, VMs on the same physical device. Additionally, provides strong local and remote attestation features both within pKVM itself and with Verified Boot.
      • Guest operating systems are not assumed to be locked down, arbitrary code can be run in guests with pKVM. See https://source.android.com/docs/core/virtualization/securityarchive.org iconarchive.today icon
      • Local attestation is provided by pKVM itself to prevent malicious VM tampering.
      • pKVM's security features are not guaranteed to work correctly if the device pKVM runs on is unlocked. Verified Boot can be used for remote attestation of the device to detect when this is the case (this does not use SafetyNet/Play Integrity).
      • Currently ARM64-specific; while some of the code is in the upstream Linux kernel, it is likely that some of it may be Android-specific and thus hard to use outside of the context of Android.
    • KVM private memory (https://lwn.net/Articles/890224/archive.org iconarchive.today icon) Isolates guest memory from a malicious KVM hypervisor.

Xen

  • https://xenproject.orgarchive.org iconarchive.today icon
  • A true type-1 hypervisor. Much smaller than the Linux kernel, currently at around 370K lines of code, thus has a dramatically lower attack surface and is much easier to trust than a full Linux kernel. While a privileged virtual machine (dom0) can *control* the hypervisor, it cannot inspect VM memory. Xen also provides guest (domU) protection from dom0 to some degree (this needs to be researched further). Additionally, it provides a hardware TPM-backed vTPM implementation. Used in Qubes OS.

Remote Attestation

Intel Trusted eXecution Technology

Missing Pieces

  • How does one ensure that the VM they uploaded to the cloud vendor is really the one they want to run? One possible idea is to upload pre-installed, fully encrypted VMs to the cloud vendor, which can be booted only by passing an encryption key to the VM at boot time using an end-to-end encrypted channel (SSH login to initramfs). The VM then would contain sha512 hashes for every static file in it, with those hashes protected by a digital signature. On first boot, the VM would run a self-check using these hashes and signature to ensure it had not been tampered with. If this check passed, the VM would then consider itself trusted and would set itself up for vTPM-powered remote attestation. Investigate to see if a technology that performs the same functions already exists or is even needed; consider creating it if it doesn't exist and is needed.
  • Does Xen support Intel TME-MK?
  • Is there a way to remotely attest more than just the OS?

Putting it all together

  • A cloud vendor uses Xen and a minimal dom0 to run cloud servers. tboot is used to ensure the hypervisor is secure.
  • The cloud vendor uses TRESOR for full disk encryption, storing the encryption key on a hardware authentication device, such that in order to boot the device, a trusted staff member must insert the key into the server at boot time. (With the use of Intel TME-MK, it might theoretically be possible to implement cold-boot proof disk encryption *without* needing TRESOR; however, this requires further investigation.)
  • The cloud vendor uses Intel TME-MK to encrypt the RAM of the host, preventing cold-boot attacks by a third party. At boot, the host generates an encryption key of its own and re-encrypts its memory with that new key, so as not to trust the processor-generated key used by default.
  • Remote users can remotely attest the cloud vendor's physical machines at will, ensuring they trust the Xen and dom0 code running on them.
  • Users upload pre-installed, encrypted VM images to the cloud vendor, which are kept tamper-proof using something (see the "missing pieces" section above). Upon passing a self-check, the VM sets itself up for remote attestation using a hypervisor-provided vTPM.
  • Xen uses Intel TME-MK to encrypt the RAM of the running VM with a user-provided encryption key, preventing cold-boot attacks by either the vendor or a third party.
  • Users remotely attest running VMs to ensure they are trusted.
  • At this point, the user has a confidential, cold-boot-proof VM. The cloud vendor must be trusted to keep their Xen and dom0 software up-to-date so as to prevent vulnerabilities from allowing VM compromise.

Rough time estimate to get TRESOR working in Linux: possibly around 80 hours of actual time invested (four hours a day, five days a week, for one month). This is a very rough estimate since actual time will depend on how receptive devs are to the ideas and how much effort is required to polish their implementation to a usable state.

Secure Cloud Hardware TODO Research List

RAM Encryption

Homomorphic Encryption

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Dev/confidential_computing&oldid=86555"