Skip to content

threat-model.md

Latest commit

 

History

History
159 lines (142 loc) · 6.77 KB

threat-model.md

File metadata and controls

159 lines (142 loc) · 6.77 KB
Raw

BCX Threat Model

Status: planning document

BCX models verifiable causal accountability for consequential operations across many carriers, ledgers, storage systems, and offline bundles. Its goal is to prove what participants observed, declared, verified, enforced, acknowledged, settled, and receipted. It does not prove a human or organization had an honest internal motive.

In Scope

  • Forged causal parentage.
  • Replay of valid operations.
  • Tampering with signed invocation metadata.
  • False broadening of delegated authority.
  • Silent HTTP downgrade.
  • Recursive WHY query abuse.
  • Cross-domain disclosure mistakes.
  • Confusing declared purpose with verified fact.
  • Gateway claims about effects it cannot observe.
  • Missing, redacted, contradictory, or unreachable evidence.
  • Native binding confusion between HTTP, blockchain, storage, and offline evidence.
  • Settlement finality overclaims.
  • Cross-profile downgrade or replay.
  • Provider format errors, crashes, resource abuse, and capability misreporting.
  • Compromised admitted providers as trusted-boundary failures.
  • Resource-amplification inputs that force expensive verification paths.
  • Threshold witness equivocation or disjoint-quorum finality claims.
  • Forged or replayed verification receipts.
  • Replay-store poisoning before authentication.
  • Crash windows between replay commitment, admission, native side effects, and effect receipts.
  • Concurrent, skipped, backward, or unauthorized lifecycle transitions.
  • Admission rejection mislabeled as effect failure.
  • Duplicate delivery creating a new effect attempt.
  • Retry amplification through unlimited effect attempts.
  • Retrying after policy or revocation roots changed without rechecking admission authority.
  • Retrying after trusted time, statement validity, key validity, capability, delegation, audience, scope, budget, recovery-rule, or completion-rule epoch changed without re-evaluating authority.
  • Completion-rule substitution, weaker-rule downgrade, wrong policy epoch, or missing completion-rule evidence.
  • Retry and reconciliation of an indeterminate attempt treated as the same operation.
  • Admission-level indeterminate resolution jumping directly to effect execution.
  • Effect-level indeterminate resolution manufacturing admission after the fact.
  • Profile completion rules that overclaim finality or ignore pending attempts, compensation, reorg, or receipt invalidation.
  • Effect-attempt state hiding operation-level evidence from another attempt.
  • Reused, overflowed, or unbound effect-attempt identifiers.
  • Portable lifecycle proof claims made from unauthenticated local journal data.
  • Omitted, reordered, truncated, forked, or stale transition-history evidence presented as current lifecycle finality.
  • Lost lifecycle history after effect evidence is reorged, contradicted, compensated, rolled back, or invalidated.
  • Stale contextual verification-cache reuse.
  • Unauthenticated orphan-quota bypass.

Out Of Scope

  • Proving internal human intent.
  • Revoking information already copied into uncontrolled systems.
  • Making a compromised endpoint honest.
  • Replacing TLS, QUIC, OS access controls, HSMs, or database authorization.
  • Proving legal compliance without reviewed policy and legal packs.
  • Providing anonymity when deployments require real identity by policy.
  • Replacing Ethereum, Cardano, Bitcoin, XRP, SCITT, OpenTelemetry, or other underlying systems.
  • Proving that an underlying chain or service is honest beyond its configured finality and evidence model.
  • Tolerating arbitrary false cryptographic success from a compromised admitted primitive provider through v1.0.0.
  • Guaranteeing generic exactly-once execution across HTTP services, databases, blockchains, or other native carriers.
  • Treating a mutable operation status alone as complete evidence history.
  • Treating a portable transition event as the current lifecycle head without checkpoint, trusted receipt, witness, or equivalent profile head evidence.
  • Treating Completed as irreversible rather than completion evidenced under a named profile policy and checkpoint or evaluation point.
  • Evaluating completion without the canonical completion-rule ID, policy epoch, and committed rule preimage used by admission and completion evidence.

Security Claims

BCX may claim:

  • this participant signed this declaration,
  • this receiver observed this invocation,
  • an authorized evaluator attested that this policy digest governed this decision,
  • a reproducible or proven policy-decision mode demonstrates stronger evaluation evidence,
  • this effect receipt was signed by this executor,
  • this checkpoint was witnessed or settled under a named profile policy,
  • this edge has a named assurance level.

BCX must not claim:

  • the declared purpose was psychologically true,
  • a gateway observed a database commit without integration evidence,
  • an Ethereum, Cardano, Bitcoin, XRP, or other settlement receipt proves an offchain business purpose was honest,
  • a missing parent does not exist,
  • a redacted explanation is complete,
  • an HTTP wrapper or blockchain transaction is proof by itself,
  • a sender-provided verification receipt suppresses required local verification unless local policy explicitly trusts that verifier role,
  • missing effect evidence after admission proves that the effect failed or succeeded,
  • subsequent reorg, rollback, compensation, contradiction, or receipt invalidation evidence erases the earlier observation,
  • a failed latest attempt means an earlier observed or receipted attempt did not occur,
  • a previously admitted operation authorizes new effect attempts after time-varying authority has expired or changed.

Privacy Risks

BCX can become a surveillance graph if implemented carelessly. The protocol must support:

  • no universal identity,
  • pairwise event identifiers,
  • hiding commitments for low-entropy private values,
  • selective disclosure,
  • encrypted evidence,
  • predicate proofs,
  • bounded WHY queries,
  • public anonymous reads outside consequential profiles.

Abuse Controls

Every WHY query must be authenticated and bounded by:

  • audit capability,
  • query purpose,
  • maximum depth,
  • maximum nodes,
  • maximum response bytes,
  • disclosure policy,
  • trust-domain rules,
  • verification budget and cost-schedule rules,
  • provider assurance policy,
  • receipt replay boundaries,
  • replay-store authentication-before-commit policy,
  • operation lifecycle and recovery-model policy,
  • append-only lifecycle journal and transition-authority policy,
  • explicit attempt-creation, attempt-limit, and transition-event commitment policy,
  • journal-head freshness and transition-chain completeness policy,
  • completion-rule identity and retry-time authority re-evaluation policy,
  • cacheability-by-outcome policy,
  • unauthenticated source quota policy,
  • threshold quorum-intersection policy.