George Lambert
da60402e88
Some checks are pending
ci / markdown (push) Waiting to run
source/ is the Sphinx tree. Companion PDF hrefs are relative, not Markdown.
76 lines
3.2 KiB
ReStructuredText
76 lines
3.2 KiB
ReStructuredText
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 :doc:`verification`).
|
||
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 distinguishes **conduits** and parties that never have access to
|
||
ePHI. Many programs still **sign a BAA** when a vendor touches
|
||
infrastructure, because misconfiguration, support exports, or logs could
|
||
later expose plaintext. OCR looks at **your** risk analysis.
|
||
|
||
**Practical pack:** risk analysis memo citing cryptree + IPFS hash checks
|
||
+ key custody; 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** lists
|
||
encryption as a security measure.
|
||
|
||
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 (usernames, logs, billing). Ciphertext-only storage
|
||
**narrows** the DPA’s technical annex.
|
||
|
||
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; **can** see routing metadata; **can** drop/delay
|
||
copy **ciphertext**. Treat like a transit provider: DPA/BAA depends on
|
||
whether routing metadata is personal data in your jurisdiction.
|
||
|
||
What “making yourself audit-ready” means
|
||
----------------------------------------
|
||
|
||
You are **not** buying Peergos’s Cure53/ROS reports as *your* SOC 2.
|
||
You are **reusing** those public evaluations as **vendor/component
|
||
assurance**, then adding your scope, RoPA, key-custody, inspect k-of-n,
|
||
admin-history, instance evidence, and contracts that match who can
|
||
actually see plaintext.
|