# 03 — Threat Model
*FPMP v0.1.0 — Draft*

## 0. Assets and Adversary Classes

**Assets:** evidence blobs (highest sensitivity), claim graph, capability grants, key material, metadata (who syncs with whom, when), the integrity of the derivation graph itself.

**Adversaries:** (A) device thief / device-compromising attacker; (B) malicious or compromised delegate; (C) sync/network adversary including a malicious relay; (D) inference poisoner (malicious data source, adapter, or model); (E) the implementation vendor (us). Each section lists attacks, protocol mitigations, and **residual risk we do not pretend to solve**.

## 1. Device Compromise (A)

| Attack | Mitigation | Residual risk |
|---|---|---|
| Stolen locked device | Blobs and log encrypted at rest under keys in OS keystore/secure element | Platform keystore strength |
| Stolen unlocked / full compromise | `DEVICE_REMOVE` op from any surviving device revokes the device key; other nodes reject its future ops; per-device keys mean one device's key compromises only its signing authority, not the root | **Data already on the device is exposed. Nothing can retract it.** Revocation bounds *future* forgery, not past disclosure |
| Compromised device forges history | Append-only Merkle DAG: other replicas detect equivocation (two ops with same prev claiming conflicting state) and surface it to the user rather than silently merging | Detection, not prevention; a single-device user has no second replica to detect with — we recommend ≥2 nodes |
| Compromised device issues malicious grants | Grants are ops in the shared log → visible in every replica's audit view; mandatory expiry caps blast radius; high-sensitivity selectors MAY require root-key co-signing | Window between grant and user noticing |

## 2. Malicious Delegate (B)

| Attack | Mitigation | Residual risk |
|---|---|---|
| Exfiltrates granted slice | Selector minimization (predicate, sensitivity ceiling, confidence floor, time bounds); claims-only default keeps evidence out of reach | **A delegate can always copy what it was legitimately shown.** Revocation stops the *flow*, not past copies. We state this plainly; "DRM for claims" is a non-goal |
| Ignores revocation | Revocation is enforced by user nodes + honest relays refusing to serve post-revocation ops; projection key rotation makes new ciphertext unreadable | Already-received plaintext |
| Probes beyond grant (oracle attacks: crafted queries to infer ungranted facts) | Delegates receive a *static projection*, not a query interface, in v0 — eliminating the oracle surface | Inference from granted claims themselves (e.g., schedule claims imply location) — mitigated only by user prudence + sensitivity ceilings |
| Re-delegates | `delegable=false` enforced cryptographically (projection encrypted to delegate key); contractual beyond that | Out-of-band copying |
| Injects claims back | Delegate-origin ops are quarantined as *suggestions*; they never gain user authority without an explicit user confirmation op | Social engineering of the confirmation |

## 3. Sync Adversary / Malicious Relay (C)

| Attack | Mitigation | Residual risk |
|---|---|---|
| Read content in transit/at rest on relay | All ops end-to-end encrypted between authorized nodes; relay stores ciphertext addressed by op_id | Traffic metadata |
| Tamper / inject ops | Signatures + content addressing: invalid ops are dropped; injection impossible without an authorized key | — |
| Drop / withhold ops (eclipse, split-view) | Causal DAG: gaps in `prev` ancestry are detectable; nodes sync with multiple peers; heads exchanged on every session so withholding shows up as a stalled frontier | A relay that is a node's *only* peer can freeze its view (availability attack). Recommend ≥2 sync paths |
| Replay old ops (e.g., a revoked grant) | Idempotent op set (content-addressed); revocations are ops that dominate the grant in the causal order — replaying the grant cannot resurrect it | — |
| Metadata analysis (sizes, timing, peer graph) | Padding and batching SHOULD be applied; relays see opaque blobs | **Metadata privacy is best-effort, not guaranteed, in v0.** Full traffic analysis resistance (mixnets) is a non-goal |

## 4. Revocation: Honest Statement of Guarantees

Revocation guarantees, mechanically: (1) no new operations flow to the revoked party via any honest node; (2) rotated keys make future ciphertext unreadable even if obtained; (3) the revocation event is permanently auditable. It does **not** guarantee deletion of data the delegate already received. Any system claiming otherwise is selling DRM. FPMP's stance: minimize what is shared, make sharing auditable, make stopping it instant.

## 5. Inference Poisoning (D)

The derivation engine consumes evidence and produces claims; both ends can be poisoned.

| Attack | Mitigation | Residual risk |
|---|---|---|
| Malicious source data (calendar invite spam, crafted messages designed to plant claims: "user is interested in X") | Source provenance on every evidence op → claims inherit a *trust score floor* from their least-trusted evidence; unsolicited/unconfirmed sources (e.g., received invites the user never accepted) get low source trust; users can refute at the **source** level, cascading out all derived claims | Subtle poisoning via legitimately-engaged content |
| Compromised adapter emits fabricated evidence | Adapters run under device keys but each evidence op names adapter id+version; an adapter-level `REFUTE` invalidates its entire output wholesale; adapters SHOULD be sandboxed with no graph write access except `EVIDENCE` ops | Adapter compromise window before detection |
| Poisoned/backdoored model emits biased claims | Every model derivation is a logged `INFERENCE_CALL` (model hash, input hashes, output hash). Refuting one call — or all calls by one model version — cascades through the derivation graph mechanically. Model-derived claims are confidence-tagged `model` and SHOULD be surfaced to the user distinctly | Cannot detect bias the user never inspects |
| Prompt-injection via evidence content into the deriver | Derivers MUST treat evidence as data, not instructions; reference implementation uses structural extraction for v0 derivers and isolates any LLM deriver with output schemas | Fundamental open problem for LLM derivers; scoped tightly in M4 |
| Cross-claim laundering (low-trust claim used as input to high-confidence claim) | Confidence and source-trust propagate through `derived_from` as a *floor* function — a claim is at most as trustworthy as its weakest required support | Aggregation attacks where many weak signals legitimately combine |

## 6. The Vendor (E) — Us

A user-ownership protocol must threat-model its own implementers. Mitigations: open spec sufficient for independent implementation (this document set); open-source reference node; reproducible builds (M7); no telemetry, no phone-home, no mandatory service in the protocol; conformance test suite so users can verify third-party nodes. Residual risk: users running unaudited binaries — irreducible, but minimized by making auditing possible.

## 7. Out-of-Scope Threats

Physical coercion of the user; OS/hardware below the app layer; legal compulsion of the user; global passive network adversaries; side channels on user devices. See 04-non-goals.