Encryption at rest --- IPFS blocks and Peergos ============================================== The problem ----------- Bytes that are no longer moving still have to live somewhere: a disk, a replica, a backup, a cold archive. The people who operate those surfaces --- hosting providers, backup operators, someone with a snapshot credential --- are rarely the same people who are authorized to read the records. A design that stores plaintext on those surfaces is a design that makes every disk operator a reader. A design that stores ciphertext, but lets an operator swap a block without detection, is a design that fails integrity even if it keeps confidentiality. The Verae DataCube Server Solution stores **data at rest** as **encrypted, content-addressed IPFS blocks**, with **Peergos** verifying hashes on the way in and the way out. Content-addressed blocks ------------------------ IPFS names a block by a cryptographic hash of its contents (a Content Identifier, or CID). Two properties follow immediately: * If the bits change, the name changes. There is no such thing as "the same CID, different payload" under a collision-resistant hash. * A client that asked for CID X and received bytes whose hash is not X **knows** it was given the wrong object. That is the definition of a **tamper-evident** store. It does not prevent a hostile replica from refusing to serve a block (availability). It does prevent a hostile replica from silently serving a substitute and hoping nobody notices (integrity). Peergos on top of IPFS ---------------------- Peergos is not "IPFS with a folder UI." It is an encrypted filesystem --- a **cryptree** --- whose nodes and file chunks are stored as IPFS blocks. The properties that matter for an audit-ready DataCube are: * **Client-side encryption.** Symmetric keys for chunks live with the customer, not on the storage host. A host with disk access sees padded, encrypted chunks and random labels, not filenames, not sibling names, not a social graph. * **Hash verification.** Peergos **verifies the hash** of every block it reads from or writes to IPFS. A restored cube is not "whatever was on the tape." It is a set of CIDs re-fetched and re-checked. * **Signed writes.** Updates are signed. An unsigned rewrite is not a valid Peergos write. * **Independent chunk keys.** Chunks (up to 5 MiB, padded) are encrypted with random 256-bit keys (Salsa20-Poly1305 in the published design), not with convergent encryption that would leak equality of plaintext across users. * **CHAMP** places encrypted cryptree nodes under random 32-byte labels, so the storage host cannot walk the directory tree by name. * **Sharing** uses hybrid encryption (X25519 plus ML-KEM-1024 in current Peergos) so a capability can be given to another user without placing the chunk key on the server. Tamper-evident restore ---------------------- "Backup" in this architecture does not mean a second plaintext copy in a different building. It means: 1. the CIDs that constitute a cube are known; 2. the encrypted blocks for those CIDs exist on more than one replica; 3. a restore **re-fetches** the blocks and **re-verifies** the hashes; 4. the customer, holding keys, decrypts locally. If step 3 fails, the restore fails closed. That is the opposite of a backup product that "helpfully" returns the last good plaintext it had. Helpfulness of that kind is how silent corruption and silent substitution enter an evidence set. Append-only at the cube layer ----------------------------- Peergos itself uses signed updates and immutable blocks. The Verae DataCube adds an **application-level chain**: a JSONL history in which each record hashes the previous record. Dual hashing (for example SHA-256 plus BLAKE2b or BLAKE3) is used so that a future weakness in one function does not silently rewrite history. These two layers must not be conflated in an audit interview: * **IPFS / Peergos** prove that the bytes retrieved are the bytes named by the CID, and that names and sizes are not in the clear on the host. * **The cube chain** proves that the organization's own history of writes is append-only at the application layer. Both are needed. Neither is a SOC 2 report. What a disk operator sees ------------------------- If keys never leave the client or the customer's HSM, a disk operator, a VM snapshot operator, and an offsite replica operator see **opaque hashed ciphertext**. They do not see PHI, they do not see document titles, they do not see the graph of who shared what with whom. That fact **changes the Business Associate / processor conversation**. It does not automatically end it. Usernames, IP addresses, billing identity, and support logs can still be personal data. Chapter 11 takes that up. What this does, and does not, satisfy ------------------------------------- For HIPAA encryption of ePHI **at rest**, for SOC 2 CC6 encryption of stored data, and for ISO 27001 Annex A cryptography and storage, this is the **technical control**: ciphertext on disk, keys with the customer, hash-checked restore. It does **not** by itself satisfy: * a **key-custody policy** (who can unwrap, where the HSM lives, how a lost key is declared); * a **restore-test procedure** with a dated ticket proving someone actually did it last quarter; * **retention and legal-hold** rules (those require the write-once archive in Chapter 9, plus lawyers); * **physical** security of the machines, which still belongs in the organization's ISMS or HIPAA facility controls.