pWith confidential computing we want to guarantee confidentiality and integrity of a user’s computation running on a remote (cloud) system, including:

• The program
• Its inputs and outputs
• Intermediate state, control flow, etc. Even if do not trust the cloud provider!

Usually it is easy to guarantee that kind of privacy if you are storing or communicating using encryption methods (see Asymmetric Cryptography, Block Ciphers), but it’s difficult to do so if the program is running.

Introduction to Confidential Computing

With confidential computing, we want to keep privacy even if the code is running in untrusted environment.

The Treat model

Trust relationships

• Everyone trusts the hardware
• Users do not trust each other
• Users DO NOT trust the cloud provider (and its software)
• Cloud provider does not trust users

Who has access to what?

• Users do not have physical access to hardware
• Cloud provider has physical access

How can you protect memory and CPU while it is running on an untrusted machine? If it was only data or transmission, then encryption would have been a solution, but in this case, we do not trust this.

We use trusted computing environments or homomorphic encryption, which means computing on encrypted data, but this is still not scalable, other is automatic verification of software and hardware isolation.

See Notions of Security for other treat models for cloud and enterprise systems

Why isolation?

Workloads must be isolated both for security (so one workload cannot access, or infer, data belonging to another workload), and for operational concerns (so the noisy neighbor effect of one workload cannot cause other workloads to run more slowly). ~(Agache et al. 2020)

Trusted Platform modules

Trusted Execution Environments

Trust some (hopefully small) remote hardware and software

• Trusted hardware element (e.g., TPM chip)
  1. Measures (≈hashes) privileged software
  2. Attests (≈signs hash) to a remote user Incorrect attestation → compromised software Allows the user to detect if TCB is tampered, and act accordingly. Here the prevention is relies on the user, but it does not prevents these kinds of attacks. This is close to the trusted computing base explained in Notions of Security.

Secure Boot

Secure boot: check system integrity before running software

• Certify system to external user

TPM is a specialized chip that stores encryption keys specific to the host system for hardware authentication

• Goals: secure attestation and key management
• Measure & examine state, send signed certification
• Example: measure BIOS sha256 to match the expected signature (detect tampers).

In google, this chip is called titan. Before running any code, we want to have a trusted system, this chip allows to check for this.

Confidential Computing key ingredients

1. CPU root of trust
   • Cryptographic keys and secure boot
2. Attestation infrastructure
3. Privileged execution environment Can be implemented with different forms, e.g.:
   • Extended microcode (e.g., Intel SGX enclaves)
     • Legacy applications can run only if you change the code.
   • Platform security processor (e.g., AMD SEV confidential VM)
     • Trusted firmware
   • New CPU protection mode (e.g., Intel TXT confidential VM, Arm CCA confidential VM)
     • Trusted software (“monitor”) runs below a de-privileged hypervisor
4. Memory encryption
   • Protects against physical attacks on DRAM
   • Varying degrees of integrity protection

Hardware security

If some software is implemented on bare metal, and it’s secure it reduces the trusted code base, so we have lesser attack vectors, and we have faster runtime, since it is usually faster in hardware. But not everything is implementable in a scalable manner in hardware, we need to take into account also other factors.

CHERI Memory Capabilities

CHERI stands for Capability Hardware Enhanced RISC Instructions, first chip that implements capabilities in hardware, for fat pointers, i.e. they know where is it possible to read and write.

One problem is

• Software compability often you need to rewrite parts of your code
• Revoking: it is still difficult to revoke and reissue all the capabilities.
• More cache pressure, since memory is larger.

But now we can check every read, it is like a sandboxed environment.

Nitro System

AWS has AWS Nitro, which is a hardware assisted hypervisor, see document.

From my personal understanding, it seems:

• Cards -> IO functionality and communication and encryption
• Security Chip -> Safe certified boot.
• Hypervisor -> Secure hypervisor with minimal functionality and strong isolation.

Nitro Cards

• Custom silicon implementing data encryption for networking and storage
  • Use hardware offload engines with secure key storage integrated in the SoC
  • Encryption keys are only present in plaintext in the protected volatile memory of the Nitro Cards
• Keys are inaccessible to AWS operators or customer code running on host CPUs
• A Nitro Card can be sub-divided into multiple virtual functions with SR-IOV (see Virtual Machines and Datacenter Hardware)

Nitro Security Chip

The Nitro Security Chip is a custom hardware component that provides a secure environment for the Nitro System.

• Device integrated into the server’s system main board
• During system boot/reset, controls physical reset pins
• Ensures Nitro controller completes its secure boot and verifies integrity of the BIOS and system firmware before any processing on CPU can begin
• To support bare-metal EC2 VMs, Nitro Security chip ensures the host CPU cannot update firmware in bare-metal mode

Nitro Hypervisor

Nitro Hypervisor code is a cryptographically signed firmware-like component stored on encrypted local storage:

• By design, the hypervisor is not a general-purpose system: it has no network stack, no file system, no interactive shell → relies instead on physically isolated Nitro cards for I/O → eliminates entire classes of bugs, such as remote networking attacks → even in the unlikely case of a bug, the lack of standard features like interactive shells and file systems makes it a difficult environment for attackers to exploit (not very nice environment).

Intel SGX

The primary goal of SGX is to protect code and data at runtime, shielding it from:

• Malicious OS/hypervisor (e.g., rootkits).
• Physical attacks (to some extent, like memory sniffing).
• Rogue privileged processes.

Enclaves

An enclave is a protected area of memory that is isolated from the rest of the system. It can only be accessed by the code running inside it, and it is protected from other processes, including the operating system and hypervisor.

Memory Encryption Engine

The Memory Encryption Engine (MEE) is a hardware component that encrypts memory pages before they are written to DRAM and decrypts them when they are read back into the CPU. This helps protect against physical attacks on memory. It also maintains a memory integrity tree similar to Merkle Trees.

Enclave Page Cache

The Enclave Page Cache (EPC) is a protected area of memory that is used to store the code and data of an SGX enclave. The EPC is encrypted and can only be accessed by the CPU. Usually it has a size of about 128MB

References

[1] Agache et al. “Firecracker: Lightweight Virtualization for Serverless Applications” 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20) 2020