Initial pack: Peergos EU audit verification and DataCube audit-ready checklist

Cure53 Berlin 2019 and ROS Amsterdam 2024 are pentests, not HIPAA/SOC2/ISO
certificates. BAA/DPA guidance for ciphertext-at-rest on cryptree+IPFS.

.forgejo/workflows/ci.yml

@@ -0,0 +1,19 @@
+name: ci
+on:
+  push:
+  pull_request:
+jobs:
+  markdown:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: required files
+        run: |
+          test -f README.md
+          test -f LICENSE
+          test -f PEERGOS-VERIFICATION.md
+          test -f BAA-DPA.md
+          test -f CHECKLIST.md
+          grep -q "not a HIPAA" README.md
+          grep -q "Cure53" PEERGOS-VERIFICATION.md
+          grep -q "Radically Open Security" PEERGOS-VERIFICATION.md

.gitignore

@@ -0,0 +1,6 @@
+.venv/
+__pycache__/
+*.pyc
+keys/
+*.pem
+*.sk

BAA-DPA.md

@@ -0,0 +1,85 @@
+# BAAs and DPAs when ciphertext has no host keys
+
+This is **guidance for an evidence pack**, not legal advice.
+
+## The operator statement
+
+Data at rest lives in the **encrypted Peergos cryptree**. Restore uses
+**distributed, hash-verified, encrypted IPFS blocks**. Hosts and backup
+media see **opaque blobs** (and random CHAMP labels), not filenames, not
+PHI, not social graph — if keys never leave the client / customer HSM.
+
+That is **true of the Peergos design** (see `PEERGOS-VERIFICATION.md`).
+It **changes the BAA/DPA conversation**. It does **not** auto-delete the
+need for contracts.
+
+## HIPAA (US) — Business Associate
+
+A Business Associate is a person who **creates, receives, maintains, or
+transmits ePHI** for a covered entity.
+
+**Technical argument you can make (and should document):**
+
+1. ePHI is encrypted **before** it leaves the endpoint (Peergos client /
+   DataCube writer).
+2. The storage node, IPFS, disk, and backup hold **ciphertext + hashes**.
+3. Private keys **do not** reside on the storage host (customer HSM /
+   client). Hash verification detects tampering.
+4. Therefore the host **cannot maintain ePHI in intelligible form**.
+
+HHS has long distinguished **conduits** and parties that never have
+access to ePHI. Many security programs still **sign a BAA anyway** when
+a vendor touches infrastructure, because:
+
+- misconfiguration could later expose keys or plaintext logs;
+- support staff might be asked to handle a decrypted export;
+- OCR looks at **your** risk analysis, not only crypto papers.
+
+**Practical pack:** risk analysis memo citing cryptree + IPFS hash
+checks + key custody (`HSM-CUSTODY` in system-git-sync); BAA **or**
+written determination that the vendor is **not** a BA because they
+cannot decrypt; list every party with disk/backup (ns1, IPFS cluster,
+offsite replica).
+
+## GDPR (EU/UK) — processor vs technical measure
+
+Encrypted data can still be **personal data** if it is reasonably
+attributable (usernames, IPs, invoice identity). GDPR **Art. 32**
+explicitly lists encryption as a security measure.
+
+**Technical argument:**
+
+- Peergos is designed so the **server is an adversary** for content and
+  most metadata.
+- EU-based **independent pentests** (Cure53 DE, ROS NL) evaluated that
+  design.
+- Processing location for **self-host** is *your* ns1 / customer region,
+  not peergos.net’s Germany hosting, unless you use peergos.net.
+
+You may still need a **DPA (Art. 28)** with anyone who **processes**
+personal data (even usernames, logs, billing). Ciphertext-only storage
+**narrows** the DPA’s technical annex (they never see PHI bodies) but
+rarely deletes the contract if they run the VM.
+
+## NATS operators
+
+NATS is an **untrusted broker**. Content is HPKE; destinations and
+subjects are in the clear. A NATS operator:
+
+- **cannot** read message bodies if they lack endpoint private keys;
+- **can** see routing metadata (who talks to which inbox, sizes, timing);
+- **can** drop/delay/copy **ciphertext**.
+
+Treat NATS like a **transit provider**: DPA/BAA depends on whether
+routing metadata is personal data in your jurisdiction. Document
+passthrough + HPKE in the data-flow diagram.
+
+## What “making yourself audit-ready” means here
+
+You are **not** buying Peergos’s Cure53/ROS reports as *your* SOC 2.
+You are **reusing** those public evaluations as **vendor/component
+assurance** (like using an audited TLS library), then adding:
+
+- your scope, RoPA, key-custody, inspect k-of-n, admin-history;
+- evidence *your* instance ran those controls;
+- contracts that match who can actually see plaintext.

CHECKLIST.md

@@ -0,0 +1,54 @@
+# Audit-ready checklist (Verae DataCubes + Peergos)
+
+Use this as a working list. Check items only when **evidence exists**
+(screenshot, log export, signed policy, ticket). This list is not a
+certificate.
+
+## A. Scope and data map
+
+- [ ] Named legal entity and systems in scope (console, Drive, NATS, IPFS, ns1)
+- [ ] Data-flow diagram: endpoint → HPKE/NATS → cryptree/IPFS
+- [ ] What is PHI / personal data vs ciphertext vs routing metadata
+- [ ] Peergos verification file attached (`PEERGOS-VERIFICATION.md`)
+
+## B. Keys and encryption
+
+- [ ] Customer holds Peergos/Drive keys; not on storage host
+- [ ] NPE/HPKE endpoint keys in directory; private 0600; no xor content
+- [ ] Signed Ed25519 config; unsigned rejected; admin-history prev+new+diff
+- [ ] HSM or documented lab-to-HSM path (`HSM-CUSTODY.md` in system-git-sync)
+
+## C. Access
+
+- [ ] Console `PFC_REQUIRE_AUTH=1`, TOTP; Drive login separate
+- [ ] Inspect k-of-n; author is not an officer; log-before-reveal
+- [ ] Joiner / mover / leaver for console users
+- [ ] Google SSO does **not** unwrap cubes
+
+## D. Integrity and backup
+
+- [ ] Cube chain append-only JSONL; dual hash
+- [ ] Hash registry: first SHA-256 and receipt win
+- [ ] Peergos/IPFS: hash-verified encrypted blocks (restore = re-fetch CIDs)
+- [ ] Restore test: recover a cube from content-addressed ciphertext without
+      plaintext backup tapes
+
+## E. Logging
+
+- [ ] Inspect audit events
+- [ ] SM summaries: codes + lookup_id only (no bodies)
+- [ ] Admin-history cube for config
+
+## F. Contracts (counsel)
+
+- [ ] Written BA / not-a-BA determination for disk, VM, backup, IPFS
+- [ ] DPA Art. 28 where usernames/logs/IPs are processed
+- [ ] NATS operator: metadata vs content in the annex
+- [ ] Peergos component assurance: attach Cure53 2019 + ROS 2024 PDFs
+      (public; not your org’s ISO/SOC report)
+
+## G. Independent audit of *you*
+
+- [ ] SOC 2 Type I/II engagement **or** ISO 27001 registrar **or** HIPAA
+      risk analysis + policies (pick the program you actually need)
+- [ ] Evidence window (Type II / surveillance) if applicable

HOWTO.md

@@ -0,0 +1,22 @@
+# How to use this pack
+
+1. Read `PEERGOS-VERIFICATION.md` so you do not over-claim Peergos audits.
+2. Fill `CHECKLIST.md` with **your** instance evidence (ns1, keys, users).
+3. Give `BAA-DPA.md` to counsel with the data-flow from `README.md`.
+4. Point auditors at live technical surfaces (do not give them private keys):
+
+   - https://pfc.georgelambert.org/health  
+   - https://pfc.georgelambert.org/v1/npe/keys (public keys only)  
+   - https://docs.pfc.georgelambert.org/controls.html  
+   - https://docs.pfc.georgelambert.org/custody.html  
+   - Peergos Drive (cryptree) on your host  
+
+5. Attach the two **public** Peergos pentest PDFs from
+   https://github.com/Peergos/Peergos/tree/master/audits as **vendor
+   security evaluations**, labeled “not our SOC 2 / ISO certificate”.
+
+Related code/docs:
+
+- https://git.georgelambert.org/marchon/peergos-for-compliance  
+- https://git.georgelambert.org/marchon/system-git-sync  
+- https://git.georgelambert.org/marchon/secure-messaging  

LICENSE

@@ -0,0 +1,19 @@
+Copyright 2026 Verae / George Lambert
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

MODULE.md

@@ -0,0 +1,33 @@
+# MODULE — peergos-making-yourself-audit-ready-with-verae-datacubes
+
+Git: https://git.georgelambert.org/marchon/peergos-making-yourself-audit-ready-with-verae-datacubes
+
+This is **not** a HIPAA/SOC 2/ISO certificate.
+
+## What this module is
+
+Documentation pack: how an organization uses Verae DataCubes on Peergos
+to **prepare for** an audit. Includes sourced verification of Peergos’s
+EU security evaluations and a BAA/DPA discussion for ciphertext-at-rest.
+
+## Who calls this module and why
+
+Compliance, counsel, and auditors. No runtime NATS publisher.
+
+## Messages — from / to
+
+None. Static git + rendered docs.
+
+## Filters / security
+
+Do not claim Peergos pentests are your ISO/SOC certificate. Do not commit
+private keys. Public key directory URLs only.
+
+## Errors and timeouts
+
+n/a
+
+## Where data is stored
+
+This repo on git.georgelambert.org. Live cubes remain on Peergos cryptree
++ IPFS; NATS carries HPKE content.

PEERGOS-VERIFICATION.md

@@ -0,0 +1,81 @@
+# Peergos verification (what was actually audited)
+
+This file records **sourced** facts. It does **not** turn Peergos, Verae, or
+DataCubes into a HIPAA, SOC 2, or ISO 27001 certificate.
+
+## Claim to check
+
+> Data at rest is stored in an encrypted append-only Peergos filesystem;
+> backup/restore is managed via a distributed, hashed, encrypted Peergos
+> IPFS system, designed and evaluated in the EU as an audited secure
+> filesystem.
+
+## Verified
+
+### Independent security audits (Europe)
+
+| Year | Firm | Where | What | Outcome (as published) | Primary sources |
+|---|---|---|---|---|---|
+| 2019 | **Cure53** | Berlin, Germany | Pentest, source-code audit, **crypto/design review** of Peergos (May–June 2019) | Peergos: no fundamental architectural or cryptographic problems found; reported issues fixed. Cure53 concluded the platform **passed this evaluation**. | [peergos.org/posts/security-audit](https://peergos.org/posts/security-audit); [cure53.de/pentest-report_peergos.pdf](https://cure53.de/pentest-report_peergos.pdf); [github.com/Peergos/Peergos/tree/master/audits](https://github.com/Peergos/Peergos/tree/master/audits) |
+| 2024 | **Radically Open Security B.V.** | Amsterdam, Netherlands | Crystal-box pentest + code audit of Peergos web-ui (Sep–Nov 2024), report dated 18 Nov 2024 | **0** extreme / high / elevated findings; **2** moderate, **6** low; Peergos states all fixed; none resulted in data exposure or integrity compromise (mostly UI crashes). | [peergos.org/posts/security-audit-2024](https://peergos.org/posts/security-audit-2024); ROS PDF in the same GitHub `audits/` tree |
+
+Both firms are **EU-based**. Both full reports are **public**. That is a
+**security evaluation of the Peergos protocol/implementation**, not a
+HIPAA/SOC 2/ISO management-system certificate.
+
+### EU funding / NLNet
+
+- Peergos received funding from the **European Union Horizon 2020** programme
+  under **NGI-POINTER**, grant **871528** (stated on the 2024 audit post).
+- The 2024 audit was supported by **NLnet** (Netherlands).
+
+### Hosted instance location (peergos.net, not necessarily your self-host)
+
+Peergos’s hosted privacy notice states the hosted instance uses servers in
+**Germany** and encrypted object storage, with backups that may use other
+providers (e.g. Backblaze S3). **Self-hosted ns1 / customer cryptree is a
+different processing location** and must be documented in *your* RoPA / BAA
+pack.
+
+Source: [peergos.net/privacy.html](https://peergos.net/privacy.html)
+
+### Encrypted filesystem + hashed IPFS (design)
+
+Documented Peergos design (matches “encrypted, hashed, distributed”):
+
+- **Cryptree**: tree of symmetric keys; fine-grained read/write caps; sibling
+  names hidden from a cap-holder of one file. Writes are **signed**.
+  [book.peergos.org/security/cryptree.html](https://book.peergos.org/security/cryptree.html)
+- **Chunks**: up to 5 MiB, padded, independently encrypted
+  (Salsa20-Poly1305 / TweetNaCl); random 256-bit keys (not convergent).
+  [book.peergos.org/security/encryption.html](https://book.peergos.org/security/encryption.html)
+- **IPFS**: content-addressed blocks. Peergos **verifies the hash** of every
+  block read from or written to IPFS (server cannot silently swap bytes).
+  Client verifies hashes and signatures of data from a Peergos server.
+  [book.peergos.org/security/trust.html](https://book.peergos.org/security/trust.html)
+- **CHAMP**: encrypted cryptree nodes under **random 32-byte labels**; server
+  cannot deduce file size or directory shape from the label graph.
+- Sharing: hybrid **X25519 + ML-KEM-1024** (post-quantum hybrid) for follow
+  requests.
+
+That is an **append-mostly / capability / content-addressed** encrypted
+filesystem. “Append-only” in Verae DataCubes is the **cube chain JSONL**
+(application integrity). Peergos itself uses signed updates and immutable
+blocks; directory pointers move forward. Do not conflate the two layers in
+an audit interview.
+
+## Not verified / do not claim
+
+| Phrase | Status |
+|---|---|
+| “Peergos is HIPAA certified” | **False.** HIPAA is not a product certificate. |
+| “Peergos is SOC 2 / ISO 27001 certified” | **Not shown** in the public materials above. The published work is **security pentest/code audit**, not a Type II or ISO registrar certificate. |
+| “EU evaluated Peergos as a certified secure filesystem under a government FS standard” | **Overstated.** What exists: EU **grant funding**, NLNet-funded **ROS pentest**, Cure53 **Berlin** design+code audit. |
+| “Hosts with disk/backup never need a BAA/DPA” | **Legal conclusion — not a technical fact.** See `BAA-DPA.md`. Encryption + no keys at the host is a **strong Art. 32 / HIPAA Security Rule argument**; counsel still decides. |
+
+## How Verae uses this
+
+Verae DataCubes sit **on** Peergos cryptree (Drive) plus a **console** identity
+plane (TOTP, k-of-n inspect). Backup of cubes is **content-addressed encrypted
+blocks** (Peergos/IPFS), not a plaintext dump. That is the technical story to
+hand an auditor, with the sources in this file.

README.md

@@ -0,0 +1,73 @@
+# Making yourself audit-ready with Verae DataCubes
+
+How to **prepare an organization** for HIPAA-aligned, SOC 2, or ISO 27001
+work using Verae DataCubes on **Peergos** (encrypted cryptree + hashed
+IPFS) and HPKE on an **untrusted NATS** broker.
+
+**This repository is not a HIPAA, SOC 2, or ISO certificate.**  
+Peergos’s public pentests are **not** your Type II or ISO registrar
+certificate. They are **component security evaluations** you can attach.
+
+## What we verified about Peergos (EU)
+
+Full sources: [`PEERGOS-VERIFICATION.md`](PEERGOS-VERIFICATION.md).
+
+| Fact | Verified? |
+|---|---|
+| Encrypted client-side filesystem (cryptree); keys not on the storage server | Yes — Peergos book + Cure53 design review |
+| IPFS blocks content-addressed; Peergos verifies hashes (tamper-evident restore) | Yes — [trust-free layers](https://book.peergos.org/security/trust.html) |
+| Independent **EU** security audits, reports published | **Yes — two:** Cure53 **Berlin** (2019); Radically Open Security **Amsterdam** (2024, NLnet; EU Horizon 2020 NGI-POINTER mentioned on the post) |
+| “Peergos is HIPAA/SOC 2/ISO certified” | **No.** Those audits are pentest/code/design reviews, not management-system certificates |
+
+So: Peergos **was designed as a trust-minimized encrypted filesystem**,
+**evaluated in Europe** by two specialist firms, with **public reports**.
+That supports the **at-rest / backup** story. It does **not** finish
+*your* audit.
+
+## Architecture (audit interview in one page)
+
+```
+Endpoint (keys stay here / HSM)
+    │  HPKE content (NPE suite)
+    │  routing: dest + subject in the clear
+    ▼
+Untrusted NATS (cannot read bodies)
+    │
+    ▼
+Verae DataCube chain (append-only hashes)
+    │  written through Peergos client
+    ▼
+Peergos cryptree (encrypted names, sizes, graph)
+    │  chunks → CID / hash
+    ▼
+IPFS  (distributed, hash-verified ciphertext)
+```
+
+- **At rest:** Peergos cryptree + IPFS. Hosts with disk/backup see
+  **opaque hashed ciphertext**, not PHI, if they lack keys.
+- **In transit (NATS):** HPKE-Base to directory public keys. Broker is
+  honest-but-curious: destinations yes, bodies no.
+- **Integrity:** cube JSONL chain + dual hash + IPFS CID check on
+  restore (re-fetch blocks, re-verify hashes — not a plaintext tape).
+
+## BAAs / DPAs
+
+Ciphertext-without-keys **narrows** who is a Business Associate or
+GDPR processor for **content**. It does **not** automatically delete
+contracts for VMs, usernames, or logs. See [`BAA-DPA.md`](BAA-DPA.md).
+
+## Pack
+
+| File | Use |
+|---|---|
+| `PEERGOS-VERIFICATION.md` | Sourced Peergos/EU audit facts |
+| `BAA-DPA.md` | Counsel briefing |
+| `CHECKLIST.md` | Evidence list |
+| `HOWTO.md` | How to hand this to an auditor |
+| `MODULE.md` | Callers / non-runtime |
+
+Live technical surfaces (ns1): https://pfc.georgelambert.org/health ·
+https://pfc.georgelambert.org/v1/npe/keys ·
+https://docs.pfc.georgelambert.org/controls.html
+
+Related: https://git.georgelambert.org/marchon/system-git-sync