proxmox/docs/dbis-rail/DBIS_RAIL_SECURITY_THREAT_MODEL_V1.md

DBIS Rail Security Threat Model v1

Network: DBIS Mainnet (ChainID 138)
Document type: Security threat assessment
Companion documents: DBIS Rail Technical Spec v1, DBIS Rail Rulebook v1

---

1. Scope

1.1 Assets protected

• GRU (and linked c token) supply integrity:* Unauthorized mint must be impossible without a valid Mint Authorization satisfying signer quorum and router policy.
• Settlement audit trail: Immutability and correctness of SettlementRecorded and MintExecuted events; binding of messageId, isoHash, and accountingRef to ledger and ISO evidence.
• Participant and signer registries: Integrity of allowlists; only authorized participants receive mints; only allowlisted signers contribute to valid authorizations.
• Policy enforcement: Per-message and per-corridor caps, time windows, and replay protection are enforced on-chain.

1.2 Trust boundaries

• On-chain / off-chain: The chain does not parse ISO-20022; it accepts only compact MintAuth structs and signatures. Finality of fiat/ledger is determined off-chain; the chain enforces authorization integrity and policy.
• Validator layer / application layer: QBFT validators produce blocks; DBIS Rail contracts (RootRegistry, ParticipantRegistry, SignerRegistry, SettlementRouter, GRU_MintController) execute in those blocks. Compromise of the application layer does not imply compromise of consensus; compromise of consensus can affect availability and ordering.
• Signer set / ISO Gateway: Signers produce ECDSA signatures over MintAuth; the ISO Gateway (or relayer) assembles evidence, computes isoHash and accountingRef, and submits to the router. Compromise of the Gateway can lead to incorrect or malicious authorizations if signers sign without independent verification; the chain does not verify ledger or compliance correctness, only signature and policy.

1.3 Assumptions

• QBFT permissioned validators: The validator set is permissioned and operated under DBIS (or designated) control. We assume Byzantine fault tolerance within the stated threshold (e.g., < 1/3 malicious); we do not assume permissionless or economically secured consensus.
• EIP-712 and ECDSA: Signatures over MintAuth use EIP-712 typed data and standard ECDSA. We assume no compromise of the elliptic curve or hash functions used.
• Off-chain ISO Gateway and ledger: The ISO Gateway, ledger domain, and compliance systems are in the regulated/operational domain. The threat model treats their compromise as an off-chain threat (Section 3.F); the chain cannot detect misclassification of good funds or forged accountingRef if the evidence bundle and ledger are compromised before signing.
• Single chain: MintAuth is bound to chainId 138 and a specific verifyingContract. Cross-chain replay is out of scope for same-MintAuth reuse; multi-chain deployment would require a separate threat analysis.
• No optional v1.5+ features: Signer effective/revoked block semantics are recommended in the Rulebook but not assumed in this v1 model; quorum and time window are the primary signer-related mitigations.

---

2. System Trust Model

2.1 Trust domains

Domain	Trust level	Description
Validator layer	Byzantine tolerant (QBFT)	Block production and ordering. Up to f faulty validators (e.g., f < n/3) tolerated; no finality loss. Validators do not execute DBIS Rail logic beyond inclusion in blocks.
Signer layer	Threshold enforced	Mint authorization requires a quorum of allowlisted signers (e.g., 3-of-5 with COMPLIANCE mandatory). Trust: signers are independent and keys are protected; compromise of enough signers breaks the model.
ISO Gateway	Regulated domain	Produces MintAuth inputs (messageId, isoHash, accountingRef, fundsStatus, etc.) and runs compliance. Trust: Gateway and ledger are correct and not compromised; Rulebook is followed.
Settlement router contract	Deterministic	Enforces signature verification, replay protection, time window, policy caps, participant allowlist. Trust: correct implementation and no reentrancy/overflow bugs; admin keys not abused.
GRU Mint Controller	Deterministic	Mints only when called by SettlementRouter with validated MintAuth. Trust: only router can call mint; no direct mint path; upgrade path is governed.
Registries (Root, Participant, Signer)	Admin-controlled	Hold component addresses and allowlists. Trust: admin and governance (multisig/timelock) do not collude to open backdoors or bypass policy.

2.2 Explicit trust separation

• Validators do not sign Mint Authorizations; they only order transactions. A malicious validator can censor or reorder but cannot mint without a valid MintAuth.
• Signers do not produce blocks; they only sign MintAuth. Compromise of signers can lead to unauthorized authorizations; compromise of validators does not by itself create new GRU.
• Router does not decide fiat finality; it enforces that authorizations are properly signed and within policy. Misclassification of funds (e.g., OFF_LEDGER_FINAL used when not justified) is an off-chain/operational failure, not a router bug.
• Mint Controller does not validate signatures; it trusts the router. The single point of enforcement for “who can mint” is the router’s access control to the mint path.

---

3. Threat Categories

3.A Authorization layer attacks

Threat	Description
Signature forgery	Attacker produces a valid ECDSA signature over MintAuth without holding a signer key.
Signature replay	Reuse of a previously submitted MintAuth (same messageId) to mint again.
Cross-chain replay	Reuse of a MintAuth on another chain (e.g., same messageId on a fork or different chainId).
VerifyingContract spoofing	MintAuth signed for a different contract or chain is submitted to the router (e.g., wrong chainId or verifyingContract).
Expired auth reuse	Submission of a MintAuth after expiresAt or before notBefore.
Signer compromise	One or more signer keys are stolen or coerced; attacker obtains enough signatures to meet quorum.
Quorum manipulation	Attacker causes the set of signers to satisfy quorum with fewer than intended independent parties (e.g., one entity controlling multiple signer keys).
Category bypass	Authorization accepted with signer set that does not include required category (e.g., COMPLIANCE) or does not meet category mask rules.

Mitigations:

• EIP-712 domain separation: chainId and verifyingContract are part of the signed payload; signatures for other chains or contracts do not verify on this router.
• messageId replay lock: Router maintains usedMessageIds; second submission of same messageId reverts. One-time use per messageId.
• Time window: Router checks block.timestamp within [notBefore, expiresAt]; expired or not-yet-valid auths revert.
• SignerRegistry and quorum: Only allowlisted signers count; required number of signatures and required category mask (e.g., COMPLIANCE + 2 of OPS/CUSTODY/RISK/AUDITOR) enforced on-chain.
• Signer effective/revoked block (v1.5+): Rulebook recommends signer effective-from and revoked-at block; when implemented, router rejects signatures from signers outside the effective window.
• Operational: Key hygiene, HSM or secure enclave for signer keys, separation of signer roles from Gateway operators.

---

3.B Ledger / accounting attacks

Threat	Description
Fake accountingRef	Attacker invents an accountingRef that does not correspond to a real ledger posting, or reuses one from another context.
Off-ledger misclassification	Funds not yet final (or not final on the declared rail) are marked ON_LEDGER_FINAL or OFF_LEDGER_FINAL to obtain a Mint Authorization.
Good funds misrepresentation	Reversal window not elapsed, or exception/dispute present, but MintAuth is still issued.
Duplicate ledger posting	Same underlying settlement is posted twice and two Mint Auths are issued (double mint).
Partial settlement submission	Only part of a batch or obligation is posted; MintAuth is issued for full amount or wrong recipients.

Mitigations:

• Deterministic accountingRef: Rulebook defines accountingRef = keccak256(ledgerSystemId, journalId, batchNumber, postingTimestamp, reserveAccountId). Audit can verify that on-chain accountingRef matches a unique ledger posting; invented or reused refs do not match any valid posting.
• Rulebook good funds matrix: Operational requirement that MintAuth is issued only when the correct finality trigger for the rail type and FundsStatus is met; reversal windows and exception handling are policy-enforced before signing.
• Evidence bundle hashed into isoHash: The canonical ISO (or equivalent) bundle is hashed; isoHash on-chain ties the authorization to that bundle. Operational procedures require bundle to reflect actual finality and posting; tampering or misclassification is detectable in audit.
• Operational reconciliation: Rulebook requires reconciliation between ledger, Gateway, and on-chain state; discrepancies and duplicate postings must be caught before or after submission and handled by incident procedures.
• One-to-one accountingRef–MintAuth: Rulebook states each accountingRef corresponds to at most one MintAuth unless a defined exception exists; reduces double-mint from duplicate posting.

---

3.C Settlement router attacks

Threat	Description
Reentrancy	Attacker causes router to re-enter during submitMintAuth (e.g., via callback from recipient or mint path) and execute logic twice.
Overflows	Integer overflow in amount aggregation or corridor usage leading to cap bypass or incorrect state.
Multi-recipient edge case	Mismatch between recipients and amounts; wrong recipient gets wrong amount or length check bypassed.
Policy cap bypass	Per-message or daily corridor cap exceeded by splitting, wrapping, or exploiting rounding.
Paused state bypass	Mint or settlement executed while router (or mint controller) is paused.
Corridor limit bypass	Daily or aggregate corridor usage not correctly incremented or checked.

Mitigations:

• CEI (Checks-Effects-Interactions): All state updates (usedMessageIds, corridor usage) before external call to Mint Controller; no reentrancy into router state from mint path.
• ReentrancyGuard: Use nonReentrant modifier on submitMintAuth where applicable.
• Strict array length equality: Require recipients.length == amounts.length and validate before any use; revert on mismatch.
• Caps enforced before mint: Compute total amount and corridor usage; revert if maxAmountPerMessage or corridorDailyCap exceeded; only then call mint controller.
• Paused modifiers: Router and Mint Controller check paused flag at entry; ROUTER_ADMIN can pause both; no settlement or mint when paused.
• Safe math / Solidity 0.8+: Use checked arithmetic to prevent overflows in aggregation and corridor counters.
• Audit and tests: Unit and integration tests for multi-recipient, cap boundary, and pause behavior.

---

3.D Mint controller attacks

Threat	Description
Direct mint bypass	Actor other than SettlementRouter calls mint (e.g., owner, MINTER_ROLE on token, or public mint function).
Role escalation	Attacker gains MINTER_ROLE or equivalent on the token or Diamond facet and mints without going through router.
Diamond facet misconfiguration	GRU mint facet is callable by other contracts or EOAs; or router address not correctly set as sole caller.
Proxy upgrade takeover	Upgrade of Mint Controller or token implementation to a malicious version that mints to attacker or disables router check.

Mitigations:

• Only SettlementRouter can mint: Mint Controller’s mintFromAuthorization checks msg.sender == settlementRouter; no other path to mint. Token or Diamond mint facet must be restricted to Mint Controller (or router) only.
• Revoke owner mint: Any direct owner-mint or default MINTER_ROLE on GRU/c* tokens must be removed or permanently revoked; sole mint path is router → Mint Controller.
• Governance timelock: Upgrades to Mint Controller, router, or critical facets use timelock and multisig so that a single compromised key cannot push a malicious implementation.
• Upgrade and config event logging: Emit events on upgrade and on settlementRouter address change so that monitoring and governance can detect unauthorized changes.
• Deployment checklist: Verify that no token or facet exposes a mint (or equivalent) function to the public or to any address other than the Mint Controller.

---

3.E Validator layer attacks

Threat	Description
Validator collusion	More than f (e.g., ≥ n/3) validators collude to produce incorrect blocks or break finality.
Censorship	Validators refuse to include DBIS Rail transactions (e.g., submitMintAuth) to disrupt settlement.
Chain halt	Validators stop producing blocks so that no new settlements can be recorded.
Reorg attempts	Attacker with sufficient hash power or validator control attempts to reorg blocks containing settlement transactions to double-spend or revert mints.
Validator key compromise	One or more validator keys are stolen; attacker can sign blocks (within QBFT rules) or attempt to join the set.

Mitigations:

• QBFT finality: Once a block is finalized, it is not reverted under normal QBFT assumptions. Reorg of finalized blocks would require violation of the consensus protocol.
• Documented validator governance: Validator set and rotation are documented (operationally for v1); multi-operator or multi-party control reduces single-point control.
• Emergency pause: If chain halts or censorship is detected, ROUTER_ADMIN can pause router and mint controller; no new mints until chain and governance are restored.
• Permissioning: Besu permissions (permissions-nodes-config-file, permissions-accounts-config-file) restrict who can validate; compromise of a non-validator node does not by itself allow block production.
• Monitoring: Block production and finality monitored; alerts on extended no-finality or censorship patterns.

---

3.F Off-chain threats

Threat	Description
ISO Gateway compromise	Attacker controls or compromises the Gateway; produces MintAuth with fake isoHash, wrong accountingRef, or misclassified fundsStatus; obtains signer signatures (e.g., via social engineering or compromised signer workflow).
Signer key theft	Attacker steals signer private keys (e.g., from HSM or key store) and signs MintAuth without legitimate settlement.
Insider collusion	Multiple insiders (e.g., Gateway operators + signers) collude to issue authorizations for non-existent or invalid settlements.
Compliance system failure	Sanctions/AML/KYC checks are bypassed or misconfigured; prohibited party or transaction receives a Mint Authorization.
Accounting system compromise	Ledger or posting system is tampered so that accountingRef points to a fabricated or altered posting.

Mitigations:

• HSM or secure enclave for signers: Signer keys stored and used in HSM or TEE; reduces theft and use by Gateway operators.
• Role separation: Signers are distinct from Gateway operators; signers verify (or have independent view of) settlement and compliance before signing; Rulebook requires preconditions to be met before signers sign.
• Quorum design: 3-of-5 with COMPLIANCE mandatory ensures at least three independent sign-offs and that compliance is never bypassed by a single role.
• Signer revocation procedure: Rulebook defines revocation and in-flight handling; compromised signer is removed and pending auths re-evaluated.
• Monitoring and audit logs: Gateway, ledger, and signer actions logged; mapping messageId ↔ evidence ↔ accountingRef retained; anomalies and exceptions investigated.
• Compliance and audit: Regular audit of Rulebook adherence, good funds matrix application, and evidence bundle construction; compliance controls tested independently.

---

4. Risk Severity Classification

4.1 Severity levels

• Critical: Unauthorized mint or permanent loss of funds/supply integrity; or complete bypass of authorization or policy. Requires immediate mitigation and may warrant pause.
• High: Significant abuse possible (e.g., large unauthorized mint, systemic misclassification) but with containment or detection; or single point of failure that could be exploited.
• Medium: Limited scope (e.g., one messageId replay, one signer compromise without quorum) or depends on multiple failures; or availability impact without direct mint abuse.
• Low: Theoretical or requires unrealistic assumptions; or operational nuisance with clear procedure.

4.2 Threat severity table

Threat	Severity	Reason
Signer quorum compromise (enough keys to meet 3-of-5)	Critical	Enables unauthorized MintAuth and thus unauthorized mint.
ISO Gateway + signer collusion (bypass good funds)	Critical	Can issue valid MintAuth for non-final or fake settlement; chain cannot detect.
Direct mint bypass (token or Mint Controller)	Critical	GRU can be minted without any MintAuth; breaks rail integrity.
messageId replay (if not enforced)	Critical	Same MintAuth executed twice; double mint.
Signature forgery (break ECDSA or EIP-712)	Critical	Attacker could forge valid signatures; treat as cryptographically infeasible but severity is critical if possible.
Fake accountingRef accepted without audit	High	Audit and Rulebook mitigate; if ledger and Gateway both compromised, fake ref can support unauthorized auth.
Good funds misrepresentation (e.g., ACH before return window)	High	Operational/Rulebook failure; can lead to mint against reversible settlement.
Reentrancy or overflow in router	High	Could allow double mint or cap bypass if not implemented correctly.
Router or Mint Controller upgrade to malicious implementation	High	Governance and timelock mitigate; single key compromise could push bad upgrade if governance is weak.
Single signer compromise (insufficient for quorum)	Medium	Cannot by itself produce valid MintAuth; must combine with other signers or social engineering.
Single validator compromise	Medium	QBFT tolerates f faulty; one validator cannot break finality.
Censorship of settlement transactions	Medium	Availability impact; no direct mint; pause and operational response.
Expired or wrong-chain MintAuth submitted	Low	Reverts on-chain; no effect if checks are correct.
Category bypass (e.g., no COMPLIANCE signer)	Low	Reverts if SignerRegistry and router enforce category mask.

---

5. Residual Risk

The following are intentionally trusted in this model. They are not verified on-chain; their failure is an operational or off-chain risk.

• ISO Gateway correctness: The Gateway correctly applies the Rulebook good funds matrix, builds the evidence bundle, computes isoHash and accountingRef per the deterministic rule, and does not issue MintAuth until preconditions are satisfied. The chain does not verify ledger or compliance state.
• Ledger integrity: The core (or designated) ledger correctly records postings, and accountingRef is produced only for completed, compliant postings. No tampering or fabrication of postings.
• Compliance process integrity: KYC, AML, sanctions, and jurisdiction checks are correctly applied and only passing transactions receive signer approval. No bypass or misconfiguration.
• Validator majority honesty: At least 2/3 (or the QBFT threshold) of validators follow the protocol. Finality is maintained; no reorg of finalized blocks.
• Signer independence and key security: Signers are distinct entities/roles; they do not sign without verifying that preconditions are met; private keys are protected (HSM, procedures). Compromise of fewer than quorum signers does not yield a valid MintAuth.
• Admin and governance: ROOT_ADMIN, PARTICIPANT_ADMIN, SIGNER_ADMIN, ROUTER_ADMIN are not abused; multisig or timelock is used for upgrades and critical config; no backdoor deployment or role grant to attacker.

Institutional implication: Residual risk is documented so that auditors and counterparts understand that the chain enforces authorization integrity and policy, not fiat finality or compliance correctness. The Rulebook and operational controls are the mitigation for residual risk; the Threat Model does not assume they are perfect but states that their failure is outside the on-chain threat perimeter.

---

6. Versioning and Review Cycle

• Version: This document is DBIS Rail Security Threat Model v1.
• Review frequency: At least annual review; update when design or deployment changes materially affect threats or mitigations.
• Triggered review: Revisit and update the threat model when:
  • Signer quorum or category rules change (e.g., 2-of-3, 4-of-7, or new category).
  • A new corridor or product type is added (new policy or cap structure).
  • Validator model or governance changes (e.g., on-chain validator rotation).
  • New contracts or facets are added to the DBIS Rail (e.g., new registry or router feature).
  • A security incident or audit finding indicates a new threat or ineffective mitigation.
• Ownership: Security or risk function maintains the document; changes are approved per DBIS governance (e.g., CISO, risk committee, or delegated owner).
• Publication: Current version is published with the other DBIS Rail docs (e.g., docs/dbis-rail/); superseded versions retained for audit.

---

Document control

Field	Value
Title	DBIS Rail Security Threat Model v1
Network	DBIS Mainnet (ChainID 138)
Companions	Technical Spec v1, Rulebook v1
Version	1
Status	Active