Touchstone Threat Model — Phase 1

Status: Phase 1 (hackathon build). Written 2026-08-14; revised 2026-08-17 after PLAN-T7 and PLAN-T8 closed and PLAN-T10/T11 were cut. That revision existed to remove deferrals pointing at items that had since closed without doing the work — a backlog label naming a finished item reads as covered when it is not.

This document states what Touchstone defends against today, what it does not, and where each roadmap security requirement actually stands. It is deliberately narrow: the formal threat model, the independent contract audit, and the external pipeline review are Phase 3 deliverables and are not claimed here.

Every control below is cited to the code that implements it. Where a requirement is not implemented, it is recorded as a backlog item or a residual limitation rather than described as covered. Nothing here asserts that any observed asset is safe, solvent, compliant, or suitable, and nothing here claims an independent attestation, audit, or legal opinion that Touchstone has not obtained.

1. What Touchstone is trusted to say

Touchstone claims exactly one class of thing: that it retrieved exact bytes from a first-party endpoint reached from an allowlisted URL at the recorded retrieval time, that a stated control was evaluated against those bytes deterministically, and that the result was signed and published. It does not claim the issuer is honest, that the published figures are accurate, or that an asset is sound.

Note the retrieval time is Touchstone's own: it is supplied by the caller or read from the local clock (touchstone/sources.py:216). It is not an authenticated publication timestamp from the issuer, and no source in the portfolio provides one.

A consumer relying on Touchstone inherits the trust assumptions in section 2. Those assumptions are the product, so they are enumerated rather than minimised.

2. Trust boundaries

Keys at B6, B7, B8 and B9 are required to be four distinct identities. Amended 2026-08-15 by PLAN-T6: the separation is now enforced rather than stated. A deployment manifest must state all four role addresses and cannot declare a publisher that is also the deployer or the operations address (touchstone/deployment.py); the publisher key must derive exactly the declared publisher address; a run refuses to start if the reporting seed and the publisher key are the same secret when both are present on one host — on a split-host deployment neither can see the other, so that particular collision is an operator responsibility rather than an enforced property; and preflight refuses to publish if the registry's owner() is the publisher, or if the publisher belongs to a different publisherIdentity lineage than the manifest declares. No unlocked-account path remains in the publishing code on any network — deployment and owner-administration calls still use an unlocked signer under Hardhat, which is an operator action rather than an unattended one. What is not enforced is custody: see the revised R-5 and docs/KEY-MANAGEMENT.md.

3. Threats and current disposition

Legend: Implemented (control exists and is tested) · Backlog (a named item in docs/PHASE-1-PLAN.md that will implement it) · Residual (accepted, documented, not mitigated in Phase 1). Backlog items are written PLAN-Tn to keep them distinct from the threat identifiers T1–T27 used in this section.

Evidence acquisition

Compilation

Evaluation and state

Publication

Operations and presentation

4. State semantics that this model depends on

These distinctions are load-bearing and must not be collapsed:

• SOURCE_ERROR is an operational event, not an asset judgement. Touchstone failing to retrieve evidence says nothing about the issuer. Absent a contradicted result it preserves the last evidence-derived state until that evidence's own deadline expires; a contradiction is evaluated first (touchstone/controls.py:280) and still yields INCONSISTENT.
• STALE means the evidence deadline passed, not that anything is wrong with the asset.
• INCONSISTENT requires a genuine predicate conflict between attributable observations — never a retrieval failure, never a missing field, never an ordinary value movement.
• UNVERIFIABLE is a success mode. Abstention is preferred over a confident claim; a first epoch with no confirming capture reports UNVERIFIABLE by design.

5. Roadmap requirement traceability

5.1 Aug 16 security requirements

5.2 Immediate (hackathon) security ladder

6. Residual limitations

These are accepted for Phase 1 and stated publicly rather than mitigated.

• R-1 — Byte-span provenance is not structurally bound to adapter output. Control Language v0 stores evidence_span as an observation-specific raw substring. Compilation proves only that those bytes occur in the artifact and in the provider excerpt (touchstone/compiler.py:325); source/adapter compatibility is validated separately (touchstone/compiler.py:379). It does not prove the occurrence is unique, nor that it denotes the field and typed value the deterministic adapter actually consumed. Duplicate or decoy occurrences, formatting changes, and ordinary observation rollover can therefore produce ambiguous provenance or unnecessary control-identity churn. Strict source schemas and adapter allowlisting reduce evaluation risk but do not provide structural evidence binding. A dedicated future item must add an adapter-bound structural locator (preferably a JSON Pointer against an adapter-defined logical record) requiring exactly one resolution of the expected type, agreement between the resolved value/date and the adapter's typed observation, and storage of the resolved pointer, raw span, value, date and evidence digest in epoch provenance rather than durable control identity — with compiler, evaluator and verifier agreement and offline re-resolution.
• R-2 — The confirmation window is empirical, not proven. Cross-capture confirmation shows only that a row was identical at two capture instants (touchstone/evaluate.py:361); a row revised and restored between them is indistinguishable from one never touched, and nothing establishes that an older row is never revised later. The approved control set declares no minimum row age at all — the retired hand-written controls used two business days, derived from those same two captures, but the compiler did not propose it and approval may not add it, so confirmation is now the only safeguard on this path. The business-day count ignores exchange and bank holidays.
• R-3 — Parser isolation bounds runtime, not compromise. Normalisation runs in a spawned worker with a wall-clock timeout. There is no seccomp, container, namespace or capability restriction, and the worker retains the privileges of the service account. Critically, the worker's result is returned to the parent over a multiprocessing connection (touchstone/normalize/ustb.py:295) whose receive path deserialises the object the child sent. A worker that an adversary has genuinely compromised can therefore act on the parent across that channel; the process boundary limits a misbehaving parser and a runaway one, not a controlled one. Closing this requires a restricted transport carrying only plain data, plus OS-level confinement.
• R-4 — Evidence-store integrity is detection, not prevention, and nothing anchors it externally. The hash-chained index detects modification of stored artifacts or entries. An actor with write access who rewrites objects and recomputes the entire chain is not detected. The transparency log is not an independent check on this: it is another local JSON-lines file (touchstone/translog.py:42) with the same trust properties, and while it can produce signed checkpoints, those are only returned to the caller — there is no publication, distribution or external pinning path for them. The only genuinely external record is what has been published onchain, and that is a root, not the evidence.
• R-5 — Keys are separated but not custodied. Revised 2026-08-15 by PLAN-T6. The three EVM role addresses are distinct and enforced wherever an EVM key is loaded or used; the Ed25519 reporter is separated by construction but its secret is only proved distinct from the publisher's where both sit on one host. So the original form of this residual is narrowed rather than closed. What remains is custody: both runtime keys are plain environment variables on their host, with no HSM, KMS, passphrase at rest, threshold or multisig. Anything that can read the process environment can publish. The mitigation is scope — the publisher key can only append reports, never revoke, rotate or rewrite — and recovery is the deployer calling rotatePublisher. The deployer key itself is a single key whose loss or theft is unrecoverable, because the registry has no owner-rotation path. Compromise detection does not exist: nothing watches for a publication from an unexpected publisher or a report signed by a retired key. PLAN-T7 and PLAN-T8 have both closed without building it, so no open item owns it; it is a standing residual. See docs/KEY-MANAGEMENT.md.
• R-6 — Verification bundles carry no evidence artifacts and no chain state. Narrowed 2026-08-17: bundle v4 carries the compilation artifacts each control cites and the approval ledger, so provenance and the human approval decision are both checkable offline. What a bundle still holds is the signed report, its canonical bytes, the control records, the evidence references and the published key. An offline verifier can therefore confirm the signature, recompute the control-set and evidence roots, and check internal consistency — and nothing more. It contains no registry state, no transparency log and no evidence-store index, so it cannot confirm the report was published onchain, cannot verify the log's hash chain, and cannot replay normalisation or prove that a reported row occurs inside an artifact it does not carry. Evidence remains digest-only — that is the part v4 did not change, and the limitation the report's own caveats state.
• R-7 — TLS is trusted without pinning. Evidence integrity in transit rests on the platform certificate store.
• R-9 — Control approval is unattributed. Closed for the live ledger 2026-08-19; role separation remains open. Approval used to be a field on the control record set by whoever edits the control set (B14), with no approver identity and nothing signing the decision. The live approval ledger is now version 2: every entry — declined entries included — carries an EIP-712 signature over the exact compiler proposal, the decision, a reason code and the signing timestamp, and validation refuses a version-2 ledger with any unsigned entry, verifies every signature on every load, and binds each signed decision to the one candidate its compilation actually accepted, so a signed decline cannot be repurposed for a different control. All ten decisions recover one approver, 0x537873b087654395CB0A487B50d0bFBe15fA16Bc. Signatures are timestamped at signing — 2026-08-19, not the decision dates they attest — because a backdated signature would be manufactured history. Reports published before this commit to the version-1 unsigned ledger by digest, and their bundles verify unchanged, unsigned and honestly so, forever. What R-9 still holds open: there is no separation between the person proposing a control and the person approving it, and the compiler's confidence gate cannot substitute for that, because the confidence value is supplied by the model itself (T12).
• R-11 — Compilation is bound to evaluation. Closed 2026-08-16. These were two disconnected paths: compilation validated a candidate and emitted a proposed record, evaluation admitted any record whose approval_state read approved, and the compiler_provenance_digests a report carried were checked by both the builder and the offline verifier only as well-formed hexadecimal. Nothing required an evaluated control to have come from a compilation, to match one, or to be reachable from any digest. The compiler's validation was therefore advisory to whoever curated the control set.

Three things closed it. The binding exists: ControlRecord carries compilation_sha256, part of canonical_bytes() and so of the control-set root a consumer contract pins. A proposal must carry none — the digest is over the artifact containing the proposal — and approval attaches it. It is enforced: report construction resolves each artifact, hashes it, finds the accepted candidate, and requires the approved record to differ only in approval_state and compilation_sha256, naming any other edited field. It is independently checkable: a v3 verification bundle carries the artifacts themselves, and the offline verifier resolves them in memory, hashes them against the digests they are filed under, requires the set to equal the report's provenance exactly, and repeats the binding — with no filesystem and no access to the publisher's ledger.

The hand-written control set that predated this is retired. It cited real spans and evaluated correctly, but nothing had compiled it, so a report claiming compiler provenance for it claimed something untrue. The approved set is eight candidates a model proposed from the issuer's own bytes; two further accepted candidates were declined by a human, recorded with reasons in data/compilations/APPROVALS.json, and cannot be relabelled approved.

What remained was R-9, and its unattributed half closed 2026-08-19. The ledger now records not only what was approved, when, and why a candidate was declined, but by whom: every decision carries the approver's EIP-712 signature over the exact proposal it decides. "AI proposes, deterministic systems decide" holds for the compile-to-evaluate path, and who approves is now a question the ledger answers with a recoverable address — what it does not yet answer is whether the proposer and the approver are different people.

• R-10 — Time is taken from the host clock, with only a one-sided chain check. Retrieval timestamps, freshness deadlines and the 24-hour confirmation separation all derive from the local clock (B15). The chain catches one direction: the registry rejects a future observedAt relative to block.timestamp (contracts/contracts/TouchstoneRegistry.sol:257), and AssetGate measures observation age against the same chain time. That check is one-sided and delay-sensitive: it rejects only an observedAt still ahead of chain time when the transaction executes, so publication delay masks a moderately fast clock. Source-asserted dates are not ignored either — freshness requires observed_on <= now (touchstone/evaluate.py:332) and value rows dated after now cannot be selected (touchstone/evaluate.py:361) — so a slow clock does not silently accept a future-dated row; it excludes that row and falls back to an older qualifying one, or abstains when none exists. What is missing is two-sided validation, any cross-check for purely offchain decisions, and a monotonic guard against the clock moving backwards between epochs.
• R-12 — Independent RPC confirmation is scoped to the Registry V2 publisher. That path requires two independently operated providers, compares the reads used for preflight and reconciliation, and fails closed on disagreement or partial availability. Browser, SDK and operator tools that use one endpoint still inherit that endpoint's view; no light- client proof exists.
• R-8 — Source retrieval is single-region. The production observer retrieves all three USTB sources from the shared VPS every 15 minutes. Cross-region retrieval and a second host remain unverified.
• R-13 — Writing evidence is upstream of publishing, and the observer writes evidence. The continuous observer (scripts/run_observer.py) is described elsewhere as the process that "can do least": it holds no key, imports no signer or publisher, and since 2026-08-18 runs as its own Unix identity. That is all true and it is not the same as saying a compromise of it is bounded to public artifacts.

It appends to the same evidence store the daily service reads, which is deliberate — that is how a qualifying confirmation predecessor comes to exist. But retrieved_at is supplied by the caller and only format-checked (touchstone/evidence.py:432); nothing binds it to the instant bytes actually arrived, and nothing binds the bytes to the issuer beyond the fetch policy at the moment of retrieval. So code running as the observer identity could append a fabricated payload with a backdated capture time, and the next epoch's confirmation_capture would select it as a qualifying predecessor (touchstone/epoch.py:182). A value control comparing the current row against that fabricated row would find them identical and report SATISFIED — and the asset could reach CONFIRMED on evidence that was never retrieved.

The observer therefore cannot publish, but it can determine what a publication concludes. Any claim that separating it from the publisher bounds the damage should be read narrowly: it bounds key exposure, not conclusion integrity.

Partial mitigations that exist today: the evidence index is a hash chain, so an insertion cannot be hidden after the fact; the bundle names the confirmation capture it evaluated against, so a reader can see which artifact was relied on; and the archive retains both. None of these prevent the write — they make it visible afterwards to someone who looks.

A future item should constrain retrieved_at at the store boundary to the writer's own clock within a tolerance, which would remove retroactive fabrication and leave only the slower, more visible kind that has to wait out the confirmation interval in real time. It is not implemented, because tests and fixture paths construct histories at arbitrary instants and the constraint needs a considered exemption rather than a flag.

7. Explicitly out of scope for Phase 1

The Phase 3 formal threat model, independent smart-contract audit, external pipeline security review, incident-response runbook, multi-region deployment, supply-chain controls and reproducible builds are not part of this document and are not claimed. Multi-publisher quorum, challenge mechanics and any staking or slashing design are Phase 4 and do not exist.