BAAs, DPAs, and ciphertext without host keys
============================================

This chapter is **guidance for an evidence pack**. It is not
legal advice. Counsel has to sign the actual determination.

The technical fact
------------------

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 the share
graph --- **if** private keys never leave the client or the
customer's HSM.

That fact is true of the Peergos design and is the design
Cure53 reviewed in Berlin. It **changes** the Business
Associate and GDPR-processor conversation. It does **not**
automatically delete the need for contracts.

HIPAA --- Business Associate
----------------------------

A Business Associate is a person who **creates, receives,
maintains, or transmits ePHI** for a covered entity.

A technical argument the organization can document:

1. ePHI is encrypted **before** it leaves the endpoint.
2. The storage node, IPFS, disk, Iceberg archive, and backup
   hold **ciphertext plus hashes**.
3. Private keys **do not** reside on the storage host.
   Hash verification detects substitution.
4. Therefore the host **cannot maintain ePHI in intelligible
   form**.

HHS has distinguished **conduits** and parties that never
have access to ePHI. Many programs still **sign a BAA**
whenever a vendor touches infrastructure, because
misconfiguration, a support export, or a log could later
expose plaintext. OCR will look at **the organization's**
risk analysis, not at Verae's architecture diagram.

Practical pack:

* a risk-analysis memo citing cryptree, IPFS hash checks,
  key custody, and the two public Peergos evaluations;
* a BAA **or** a written determination that a named vendor
  is **not** a BA because they cannot decrypt;
* a list of every party with disk, VM, backup, IPFS, or
  Iceberg credentials.

GDPR --- processor versus technical measure
-------------------------------------------

Encrypted data can still be **personal data** if it is
reasonably attributable (usernames, IPs, invoice identity).
GDPR Article 32 lists encryption as a security measure, not
as an exemption from Article 28.

Peergos is designed so the **server is an adversary** for
content and most metadata. EU-based independent pentests
evaluated that design. Processing location for **self-host**
is the customer's region, not peergos.net's Germany, unless
the customer uses peergos.net.

A DPA may still be required with anyone who **processes**
usernames, logs, or billing. Ciphertext-only storage
**narrows** the technical annex. It does not always
eliminate the DPA.

NATS operators
--------------

NATS is an untrusted broker. Content is HPKE. Destinations
and subjects are in the clear. A NATS operator **cannot**
read bodies without endpoint private keys. They **can** see
routing metadata. They **can** drop, delay, or copy
ciphertext. Treat them like a transit provider: whether a
DPA or BAA is needed depends on whether routing metadata is
personal data in the relevant jurisdiction.

Verae as timestamping service
-----------------------------

If Verae receives **only fingerprints**, Verae's role for
**content** is not "stores the records." Verae's role is
"registers hashes and issues receipts." That is a narrower
processing. Counsel still has to decide whether the
fingerprint, plus whatever account data exists (company
name, billing, operator emails), requires a DPA or a BAA.
Do not let a sales sentence skip that memo.

Component assurance versus the organization's report
----------------------------------------------------

Attaching Cure53 2019 and ROS 2024 is **vendor / component
assurance**. It is appropriate. It is **not** the
organization's SOC 2, ISO 27001, or HIPAA program. Those
still require the organization's scope, Record of
Processing, key-custody, inspect k-of-n, admin-history,
instance evidence, restore tests, and the contracts that
match who can actually see plaintext.