Security

What encryption buys, and what it doesn't

PowerCloud is built to run on other people's machines without trusting them. That works for data at rest and in transit. It doesn't for memory: on someone else's VM, the host can read RAM, and with it any key there.

Threat model

Threat by threat

Threat	Covered?	How
A provider, or an attacker inside it, reads stored data	Covered	Client-side encryption. Providers only ever hold ciphertext.
A provider tampers with or rolls back individual blobs	Covered	Authenticated encryption and MAC'd IDs catch tampering. Rolling an object back to an older version, or dropping it, is caught against high-water marks in the nodes' consensus, when a node is reachable.
A provider pulls the plug: non-payment, a ban, an outage, bankruptcy	Covered	Replication or erasure coding across independent providers and sites. Losing one loses nothing.
Overbilling and lock-in	Covered	Backends are dumb blob stores and VMs. Moving means adding a new one and dropping the old.
A stolen disk or a snapshot of a node	Covered	The state volume is dm-crypt with HMAC-SHA256 per sector, so tampering reads as an error. Its key is wrapped by a key only admins can derive, and a rebooted node stays locked until unlocked. Rolling the whole disk back isn't detected.
A leaked passphrase or recovery key	Partly	pcctl rotate replaces the root key, re-encrypts the store, deletes the old blobs and moves every node to a new CA. Data copied before the rotation stays readable with the old key.
A stolen or compromised node, a lost admin laptop	Partly	pcctl node rm revokes the node's certificate on every node and drops it from the mesh; revoke-admins revokes admin certificates. The node keeps its own local state.
The hypervisor reads the RAM of a running VM	Only with confidential computing	On someone else's VM, the host can read memory, and with it the keys. On AMD SEV-SNP the CPU encrypts it, and pcctl verifies the chip's attestation before sending a volume key. Intel TDX and Arm CCA aren't supported yet. A VM without one of them should only ever store ciphertext, never hold keys.
You lose every passphrase and the recovery key	Not covered, by design	By design. There is no backdoor, so the data is gone.

Where the keys may go

Two kinds of node

Because a host can read a VM's memory, a node on someone else's hardware holds keys only if the CPU encrypts that memory and proves it. Today that means AMD SEV-SNP (for example AWS c6a, m6a and r6a), where pcctl verifies the chip's attestation, chained to AMD's root and bound to the node's key, before sending a volume key, and requires it at every unlock after. Intel TDX and Arm CCA are planned.

Trusted node

Your own hardware, or a confidential VM that passed attestation. Holds keys and runs apps.

Untrusted location

A plain cloud VM or a storage bucket. Stores and relays ciphertext, and nothing else.

Defence in layers

From the root key to the boot

Keys

One random 256-bit cluster root key, never stored in plaintext. Passphrase (Argon2id, 256 MiB) and offline recovery-key slots each unwrap it, and every working key is derived from it with HKDF-SHA256.

Boot

A minimal Linux with no loadable modules and lockdown forced on. The kernel, initramfs and command line are one EFI binary, which Secure Boot with your own key will only start if you signed it.

Unlock

A rebooted node stays locked until an admin unlocks it, or, with Secure Boot and a TPM 2.0, unlocks itself only on the same machine with the same keys. On an SEV-SNP VM, the chip's attestation is checked first.

Identity

A cluster CA derived from the root key, one-time enrollment codes, mutual TLS everywhere, certificates that renew and revocations that spread over the mesh to nodes that were offline.

There is no shell, no SSH and no login on a node, so there is nothing to log in to. All control goes through an API over mutual TLS, with roles.

See the parts behind it

How it works covers each part these defences rest on; the roadmap says which are built and which are planned.

How it works The roadmap