Security

There is no vendor-held recovery key to subpoena.

One authority holds the keys and sets the policy — a person, a household, a research group, an organization. sovm does not care which. What it guarantees is that nobody outside that authority can decrypt the data, including whoever operates the hardware it happens to be sitting on.

Note — This page describes a design, not shipped software

Every claim here — including the one above about compelled disclosure — is a claim about the sovm protocol as specified, not about software you can run today. SOP/1 is a frozen architecture baseline with ten open decision gates; SSP/1 is a new specification whose conformance corpus does not exist yet. Evaluate the claims against the specification.

Threat model

Privacy is not a feature here. It is the constraint the rest of the design bends around.

The threat model sovm is designed against: a holder of replicas learns nothing from the bytes it stores. Storage providers see object sizes and transfer timing, but not contents, schema, column statistics, or row counts. The encrypted Parquet footer seals those.

Plaintext exists only as transient state on an authorized machine. A machine can hold a complete replica while being cryptographically unable to decrypt any of it — "who stores this" and "who can read this" are separate sets, neither inferred from the other.

Opaque identifiers on the wire: object identity is the hash of its ciphertext. The identifier reveals nothing about the object's contents, producer, or schema.

Encrypted footers hide schema and statistics

Objects are encrypted Parquet whose footer is encrypted too, so a holder learns neither contents nor schema, column statistics or row counts.

Content-addressed, tamper-evident

An object's identifier is the hash of its exact encrypted bytes. Tampering is detectable without trusting any path or intermediary.

Reviewed primitives, no bespoke cryptography

Group membership and key distribution use MLS (RFC 9420); records and signatures use COSE (RFC 9052).

No central node, no master with full visibility

Writes happen offline and publish on reconnect. There is no single node that sees everything by construction.

One explicit, auditable export boundary

Where data must leave the encrypted domain, that boundary is singular and auditable — an export operation, never transparent background replication.

Key custody model

One authority holds the keys. It can be a person or a household.

There is no vendor-held recovery key. The trust authority — the entity that holds the MLS group state and the derived keying material — is defined by the deployment, not by sovm. It can be a person, a household, a research group, or an organization.

This means a subpoena served on a storage host produces encrypted objects and nothing to decrypt them with. The CLOUD Act reaches provider-held data, not keys the provider never had.

The corollary: if the trust authority loses its key material and its backups, the data is gone. That is the design, not a gap in it.

SSP/1: identity, trust and policy →

No recovery key means no recovery-key subpoena

Neither sovm nor any infrastructure operator holds keying material that would satisfy a compelled disclosure request for plaintext.

Key state travels on the control plane

Membership, identity and key state synchronize on SSP/1 rather than being embedded in objects. Authorized nodes verify and decrypt; unauthorized nodes cannot.

Lose the keys, lose the data

The trust authority is the only entity that can recover the key material. There is no out-of-band recovery path by design.

Revocation semantics

Revocation is an MLS membership operation with a defined cryptographic effect.

Removing a node from the group triggers an MLS commit that rotates the epoch key. Subsequent objects are encrypted to the new epoch; the removed node cannot decrypt them because it no longer holds the group keying material.

This is a cryptographic fact, not a policy promise enforced by an application tier. It is also the sanctioned answer to shadow IT: a platform team can revoke a node and the cryptographic separation is immediate for new writes.

Note — Revocation does not reach back in time

A machine that was authorized cannot be made to forget what it already read. Revocation stops future access only. Objects the revoked node already holds remain in its possession as ciphertext it could now decrypt with its previously held keying material.

Note — Traffic analysis is reduced, not eliminated

Sizes are padded and identifiers opaque, but storage providers still observe object sizes and transfer timing. Timing side-channels and network-level metadata are outside the sovm trust boundary.

What the protocol does not protect

The limits are part of the specification, not an omission from it.

sovm does not make a model private. It provides no differential privacy and no secure aggregation, and a node that trains must decrypt.

It spans exactly one trust authority. It is not a protocol for sharing data between mutually distrusting parties, and it does not provide collaborative multi-writer editing semantics.

Network-level metadata — who is communicating with whom, at what frequency, object sizes, transfer timing — is observable by infrastructure operators. sovm reduces information leakage through opaque identifiers and padding, but does not eliminate traffic analysis.

Implementation status →

Note — No differential privacy

A node that trains on the data must decrypt it. sovm does not provide differential privacy guarantees on training outputs.

Note — No cross-tenant sharing

The protocol is not designed for data sharing between mutually distrusting parties. One authority, one group.

Note — No anonymity guarantees

sovm hides what data says but not that it exists. Object exchange patterns and peer relationships are observable at the transport layer.