How Frio handles your search

If service private key is compromised: attacker can decrypt all sealed search shards and see who is being searched for. Mitigation: key stored with chmod 600, only on the daemon host. Key rotation planned (#120).

Key rotation tradeoff (#120): rotating the service key invalidates existing sealed shards (they're encrypted to the old key). Three strategies: (a) re-encrypt existing shards during rotation window (requires old key), (b) key versioning — keep old keys in a read-only keyring, decrypt old shards with old key, encrypt new shards with new key, (c) let old shards decay naturally (30d/90d) and only use the new key going forward. Option (c) aligns with the lifecycle decay model — a compromised key only exposes shards that haven't yet expired. Multi-node key distribution tracked in #149.

If service public key is replaced: new shards would be encrypted to attacker's key. Mitigation: public key is pinned in the web intake code.

Correlation risk: the pubkey is a stable pseudonym. An attacker with disk access can't see what was searched, but can see that pubkey X made N searches across regions Y and Z over time period T. If the pubkey is linked to a person via another channel (network logs, intake session), all their searches are deanonymized.

Mitigations: (a) per-shard ephemeral keypairs — breaks correlation but requestor manages multiple keys, (b) encrypt the pubkey to the service key — hides it from disk forensics, adds a decryption step during result sealing, (c) accept the risk — in the single-operator model, the operator already has the service key and can see more sensitive data.

An attacker with access to a running Frio node (disk + process) can:

• Inject fake matches: encrypt fabricated results to the requestor's pubkey (available in cleartext meta) and write them to {store}/results/. Family receives false "your person was found at facility X" notifications — causing panic, unnecessary travel, or misdirected legal action.
• Suppress real matches: delete or modify dedup state in ~/.frio_state.json so real matches never trigger notifications. Family never learns their person was detained.
• Silently stop monitoring: set frio_status to "cancelled" or "expired" on active shards.
• Impersonate via Signal: signal-cli account data is mounted from host. Attacker can send arbitrary messages to any joined Signal group as the Frio service number.
• Harvest Signal groups: from plaintext shards, extract group links, join groups, observe members (deanonymization of requestors).

Mitigation (result integrity): all stored match results are now signed with the service Ed25519 key. The requestor verifies the signature against the pinned service pubkey to confirm results came from a legitimate daemon cycle. Fake result injection is detectable — the attacker cannot forge a valid signature without the service private key.

Single node: all shards on one disk. Disk access = full shard access (mitigated by encryption). Single point of failure.

• Mitigation: full-disk encryption (LUKS/FileVault) on the host. Sealed shards protect search targets even if disk is imaged. Docker containers run as non-root with bind-mount scoped to ~/.frio/shards/ only.
• Mitigation (SPOF): shard replication to a second node (#147). Canary health check detects daemon failures — git commit logged at startup, staleness warning after 7 days of no activity.

Mesh sync: shards transit over Tailscale (WireGuard encrypted). Tailscale compromise = shard interception during sync. Mutable meta divergence between nodes (status on node A ≠ status on node B).

• Mitigation (transit): Tailscale uses WireGuard (ChaCha20-Poly1305 + Curve25519). Even if Tailscale's coordination server is compromised, peer-to-peer traffic remains encrypted. For defense-in-depth, sealed shards add a second encryption layer — intercepted shards are still NaCl-sealed.
• Mitigation (meta divergence): meta fields that diverge (last_checked, check_count) don't affect correctness — matching is idempotent. Status transitions (hot→warm) may diverge but worst case is one node checks more frequently than needed. Formal resolution via CRDT or coordinator is tracked in #148.

IPFS distributed: private swarm limits peers, but a compromised swarm key = any node can join and fetch all pinned shards. IPFS pubsub messages (job dispatch) visible to all swarm members — job envelopes must assume swarm-wide visibility.

• Mitigation (swarm key): swarm key stored in spiritwriter secrets (encrypted keychain), not in repo or env vars. Key rotation = generate new swarm key, distribute to trusted peers, restart IPFS nodes. Old peers are immediately excluded.
• Mitigation (pubsub visibility): job payloads are NaCl sealed-box encrypted to the specific contributor — swarm peers see the envelope (facility_id, priority) but not the search target. Design principle: IPFS is the transport, not the trust boundary (#150).
• Mitigation (pinned shards): only pin sealed shards and non-PII content (abilities, profiles). Never pin plaintext search shards to IPFS.

Memory exposure: during the match cycle (~seconds per shard), the decrypted search target exists in process memory. A memory dump, core dump, or debugger attach during this window exposes the plaintext name. Mitigation: match cycles are short; Python doesn't persist decrypted values beyond scope.

Service key is the crown jewel: whoever holds ~/.frio/service.key can decrypt any sealed shard at any time, not just during match cycles. The zero-knowledge guarantee depends entirely on this key being held only by the daemon process. Key stored chmod 600, Docker container runs as non-root. Rotation: #120. Multi-node distribution: #149.

Plaintext shards bypass this entirely: for non-encrypted shards (legacy or fallback path), search params are in cleartext atoms — no decryption needed, no protection at rest. Sealed-box encryption is now the default for web intake, but the plaintext path still exists as a fallback.

The source server sees the last name. A network observer, the county IT department, or a law enforcement agency with access to server logs could determine which names are being searched and when. This is unavoidable for sites that don't expose a full roster.

What we limit: only the last name is sent (never first names, never the requestor's identity, never the Signal group link). The query is indistinguishable from any member of the public using the same search form manually. Volume provides some cover — these are public-facing sites with regular traffic.

What we can't prevent: if a source server is specifically monitoring for queries about a particular surname, they will see it. The contributor extension (#128) mitigates this by distributing queries across multiple IPs/browsers, but for direct daemon fetching, the daemon's IP is visible.

Design preference: always prefer bulk sources when available for a jurisdiction. Search-form sources are a fallback for sites that don't expose a full roster API.

Plaintext window: between matching and sealing, the match result exists in cleartext in process memory. The match dict includes the inmate name, source facility, and booking details. A memory dump during this window exposes the match.

Plaintext fallback path: sealed-box encryption is now the default intake flow. A plaintext fallback still exists for non-JS clients or error cases, but the standard web intake always produces sealed shards. Plaintext shards skip result sealing entirely — match results are sent as plaintext notifications without dual-key encryption.

Result integrity: all stored match results are signed with the service Ed25519 key. The requestor verifies the signature against the pinned service pubkey to confirm the result came from a legitimate daemon match cycle, not a fabricated injection.

Result persistence: sealed results in {store}/results/ persist indefinitely. Even after the search shard decays, the encrypted results remain on disk. Only the requestor can read them, but the ciphertext itself reveals that a match occurred for a given shard_id — metadata leakage.

Requestor key management: for Frio's UX, the recommended design is to embed the requestor's private key in the URL fragment: frio.help/status/{token}#{key_fragment}. The fragment (after #) is never sent to the server — only the browser sees it. This means:

• The URL IS the key. Sharing the URL shares decryption capability. Same mental model as today's capability token — don't lose it, don't share it with people you don't trust.
• Server never sees the private key. The server stores sealed results and serves them. Client-side JavaScript decrypts using the fragment. Zero-knowledge is preserved.
• Lost URL = lost key. But this is identical to today's "lost bookmark" scenario. No worse than the current model, strictly better (results are encrypted at rest on the server).
• No account, no recovery. By design. Key escrow would create exactly the kind of backdoor this architecture exists to prevent.

For a general-purpose Spiritwriter deployment (not Frio-specific), the requestor manages their own keypair and key loss means permanent data loss. Frio's URL-fragment approach is a UX-specific adaptation that collapses "credential" and "key" into one shareable artifact.

Signal: messages are E2E encrypted. Signal group link in the shard is sensitive — anyone with it can join the group. For encrypted shards, the link is sealed.

Discord: NOT E2E encrypted. Operator webhook means Discord (the company) and anyone with webhook URL can see match notifications. Discord is for community/ops only, not sensitive searches.

Status page: capability-token URL — the core security feature. No account, no trail, no app. See the Why this exists tab for the rationale and tradeoff.

Expired shards are not auto-deleted yet. They're marked as expired in meta but the file persists on disk until manually pruned. This means search targets remain recoverable from disk forensics even after "expiry." Shard renewal prompts before expiry tracked in #119.

Sealed results in {store}/results/ also persist. The requestor's private key is needed to read them, but the ciphertext is there.

Can observe: which facility, timing of jobs, search params (ephemeral, via dev tools)

Cannot observe: who requested the search, whether there was a match, other contributors' activity

Can fabricate: results — mitigated by cross-validation (#131)

Cannot forge: signed results are attributable via contributor pubkey

The operator (Aaron) currently holds the service private key, meaning he CAN decrypt search targets during matching. The zero-knowledge guarantee is against third parties and data at rest, not against the active operator. This is documented and intentional — a single-operator service where the operator is aligned with the mission.

For a multi-operator deployment, the service key would need HSM-based isolation or multi-party computation to prevent any single operator from accessing search targets.

Service key distribution (#149): Every node that needs to decrypt sealed shards needs the service private key. More copies = more exposure. The key is currently copied manually via SSH — no automated key distribution, no audit trail, no revocation.

Dedup divergence (#148): Node A and Node B both match the same inmate. Both send alerts because dedup state is local. The requestor gets duplicate notifications. Annoying but not a security issue — more of an operational one.

Stale meta (#147): Node A transitions a shard to "warm" but Node B still has it as "hot." Both keep checking. Wastes resources but doesn't break correctness — matching is idempotent. Formal resolution via CRDT or coordinator is part of the replication protocol design.

Signal bottleneck (#153): signal-cli is single-device — only one node can own the sender number. If that node goes down, no Signal alerts from any node. Multi-node notification requires a coordinator model or separate numbers per node.

Key mitigation: Frio runs a private IPFS swarm, not the public IPFS network. The swarm is isolated — only nodes with the swarm key can connect. No content is discoverable on the public IPFS DHT. Most people picture IPFS as global, public, and permanent. Frio's is a private libp2p mesh that happens to use IPFS protocols for content-addressed transport.

Swarm key compromise: anyone with the swarm key can join the private swarm, see all pubsub traffic, and fetch any pinned content. The swarm key is effectively a network-wide shared secret. Stored in spiritwriter secrets (encrypted keychain), rotatable by generating a new key and restarting nodes — old peers are immediately excluded.

Pubsub visibility: all swarm members see all pubsub messages. Job dispatch envelopes (facility_id, priority, expiry) are visible to every peer. Only the encrypted payload is protected.

Mitigation: sealed-box encryption on job payloads ensures that even if an adversary joins the swarm, they can only see envelopes, not search targets. IPFS is the transport, not the trust boundary. Content pinned to the swarm is either non-PII (abilities, profiles) or sealed (encrypted search shards).