Rewrite audit-ready briefing: software is not a certificate.

Open with an executive summary that HIPAA, SOC 2, and ISO 27001
are organizational programs. Verae DataCubes supply store,
communicate, timestamp, verify, and audit tools for the technical
portion only. Chapters cover transit (HPKE, visible routing), rest
(IPFS/Peergos hash-verified restore), receipts, EU Peergos
evaluations (Cure53 2019, ROS 2024), cross-blockchain timestamping,
and write-once Iceberg archive. PDF is branded with the Verae logo
top-left and Verae Inc contact in the footer; last chapters are
sourced bios for Garfinkel (FINRA CRD 5052743), Haber, and Lambert.

source/data-at-rest.rst

@@ -0,0 +1,136 @@
+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.