Document Classification: Internal — CHLOM Confidential Phase: 0 → 1 Version: 0.1 Owner: CrownThrive, LLC Last Updated: 2025-08-08

Section 1 — Threat Modeling Methodology

• Frameworks: STRIDE (services, APIs, data stores) + LINDDUN (privacy-by-design).
• Process: Decompose → Identify Assets → Define Trust Boundaries → Enumerate Threats → Rate (DREAD-lite) → Plan Mitigations → Validate → Track in backlog.

Artifacts

• /threatmodel/context-diagram.drawio
• /threatmodel/trust-boundaries.drawio
• /threatmodel/abuse-cases.md

Section 2 — Assets & Classifications

Section 3 — Adversary Profiles

• A1 — External Fraudster: aims to pass illegal activity; capabilities: scripting, basic ML evasion.
• A2 — Organized Threat Group: aims to poison features, exfiltrate data; capabilities: zero-days, social engineering.
• A3 — Malicious Insider: aims to access PII/model logic; capabilities: limited privileged access.
• A4 — Supply‑Chain Attacker: aims to inject malware via deps/CI; capabilities: typosquatting, key theft.
• A5 — Protocol/Chain Attacker: aims to exploit verifier/bridge; capabilities: replay/reorg, L2 quirks.

Section 4 — Threat Enumeration (STRIDE/LINDDUN)

Section 5 — Abuse Case Scenarios (Selected)

1. Forged License Renewal: Attacker crafts fake
2. Oracle Replay: Old sanctions snapshot re‑used to lift score.
3. Model Extraction via API: Adaptive queries to infer model.
4. Feature Poisoning (Partner Feed): Malicious partner sends tainted features.
5. Proof Flood (DoS): Massive invalid proofs to exhaust CPU.

Section 6 — Key Management & Rotation Policy

• Key Types: TLS/mTLS, JWT signing, artifact signing, data encryption keys (DEKs), KMS master keys.
• Rotation Cadence: TLS/JWT 90d; DEKs 180d; artifact keys per release.
• Storage: HSM/KMS; never exportable.
• Access: Dual‑control, break‑glass with founder approval; all actions logged.

Section 7 — Circuit & Contract Audit Summaries

• ZK Circuits: Independent review: soundness assumptions, constraint coverage, CRS process, MPC transcript.
• Contracts (TLaaS): State machine checks, access control, pause guards, upgrade paths, gas/weight bounds.
• Artifacts:

Section 8 — Mitigation Plans & Testing

• Security Tests: API fuzzing, property‑based tests on proof parsers, chaos experiments on verifier.
• SAST/DAST/SCA: Every merge; break‑build on criticals.
• Bug Bounty (Phase 1): Scope CE/ZKV/Contracts; payouts tiered.

Section 9 — Incident Response Playbook (IRP)

• Severities: Sev1 (customer impact), Sev2 (degradation), Sev3 (minor), Sev0 (regulator notified).
• On‑Call: 24×7 rotation (SRE primary, Security secondary).
• Golden Runbooks: credential leak, drift spike, proof flood, chain reorg anomaly.
• Comms: Status page, regulator templates, post‑mortem due within 5 biz days.

TLaaS — Contract Spec (Skeleton + Pre‑Fill)

Document Classification: Internal — CHLOM Confidential Phase: 0 → 1 Version: 0.1 Owner: CrownThrive, LLC Last Updated: 2025-08-08

Section 1 — Contract Architecture Diagram

• Modules: License NFT/SFT, Roles, State Machine, Dispute, Compliance Hook, Upgrade Proxy.
• Callers: Issuer, Holder, Regulator, CE oracle.
• Events:

Section 2 — License NFT/SFT Schema

{
  "token_type": "SFT",
  "metadata": {
    "issuer_id": "did:chlom:issuer:...",
    "scope": ["jurisdiction:US-CA", "activity:money_service"],
    "jurisdiction": "US-CA",
    "expiry": "2027-12-31",
    "zk_refs": ["obsidian://circuits/licensevalidity@v1"],
    "policy_bundle_id": "pb-2025-08-01-a",
    "aegis_threshold": 720
  }
}

• Notes:

Section 3 — Issuance Process Flow

1. Issuer submits metadata + proof requirements.
2. CE evaluates applicant → emits AegisScore.
3. If score ≥ threshold and proofs valid, contract mints SFT to Holder.
4. Event

Section 4 — Renewal & Revocation Logic

• Renewal: Requires fresh AegisScore within 30 days + proof bundle; auto‑suspends if absent.
• Revocation: Multisig (Issuer+Regulator) or automatic on policy breach;

Section 5 — Sublicensing & Transfer Rules

• Sublicensing: Allowed if scope permits and policy grants
• Transfer: Only among KYC‑verified wallets; CE hook validates

Section 6 — Dispute Resolution Hooks

• Challenge Window: 14 days after
• Evidence Format: IPFS/S3 pointers with signatures; ZK inclusion proofs optional.
• Arbitration: Governance contract or external ADR; decisions notarized on‑chain.

Section 7 — Governance & Upgradeability

• Proxy Pattern: UUPS or beacon; upgrade gated by DAO + time‑lock.
• Emergency Pause: Guardian key with 24h timelock + public notice.
• Parameterization: Thresholds, scopes, expiries via governance proposals.

ZKP Circuit Book — Obsidian (Template + Pre‑Fill)

Document Classification: Internal — CHLOM Confidential Phase: 0 → 1 Version: 0.1 Owner: CrownThrive, LLC Last Updated: 2025-08-08

Section 1 — Circuit Index

Section 2 — Circuit Template (per circuit)

2.1 Name & Version 2.2 Purpose & Scope 2.3 Algebra & Field (e.g., bls12‑381 scalar field) 2.4 Constraints Overview (high level) 2.5 Public Inputs (non‑PII commitments only) 2.6 Private Inputs (kept in enclave) 2.7 Proving System (Plonkish/Groth16/etc., recursion strategy if any) 2.8 Proof Generation Process (steps, budgets) 2.9 Verification Workflow (pseudocode, budgets) 2.10 Soundness & Completeness Assumptions 2.11 Performance Benchmarks (CPU, mem, proof size) 2.12 Test Vectors (valid/invalid JSON fixtures) 2.13 Audit Checklist (CRS/MPC, toxic waste handling, ceremony notes)

Section 3 — Verification API Contracts

• POST /v1/zk/verify
• Batch Verify:
• Error Cases:

Section 4 — Performance Targets (Phase 0→1)

Section 5 — Operational Notes

• Params Lifecycle: Parameter bundles are versioned and signed; clients must pin exact versions.
• Cache: Verifier caches params; TTL 24h; eviction on security bulletin.
• Telemetry:

Section 6 — Compliance & Privacy

• Public inputs never include raw PII; only commitments/hashes.
• DPIA required for new circuits affecting personal data.
• Audit references stored in WORM with circuitId + version hashes.