SALT Threat Model

What the seal defends against, what it doesn't, and where the limits lie. Stated explicitly so they survive scrutiny.

Why publish a threat model

A security claim with no boundaries is a security claim that doesn't survive cross-examination. SALT's design intentionally narrows what the seal proves. This document makes that narrowness explicit, so a reviewer can verify SALT's properties without needing to discover the gaps on their own.

The model below describes attacker capabilities, what each can and cannot do against a SALT-sealed archive, and what defensive properties SALT relies on. It is intentionally honest about residual risk.

Threat summary

Threat Defended? How
Modifying any byte of the sealed archive after capture Yes Bundle hash mismatch; TSA timestamp signs the original hash
Replacing one record's data with another's Yes Per-row provenance hash mismatch; affects bundle hash; TSA signature breaks
Forging a Sealed Ledger seal without keys Yes Sealed Ledger holds no signing keys; the seal is from the TSA, not from us
Forging a TSA signature Yes Computationally infeasible without the TSA's private key
Backdating a seal to claim earlier capture time Yes The TSA's genTime is signed; cannot be moved earlier without re-signing
Replaying an old seal against a different archive Yes The TSA token signs a specific hash; any other archive will hash differently
Tampering with the source QBO/QBD data before capture No SALT captures what the source returns; it cannot validate the source itself
Compelling the source platform (Intuit) to return false data No Outside SALT's scope — would require Intuit-level audit
Future cryptographic break of SHA-256 Mitigated Re-sealing under stronger algorithms preserves the original timestamp chain
Compromise of the TSA's private key Mitigated Multi-TSA support possible; ability to add additional independent timestamps over time
Loss or destruction of the user's archive No Custody is the user's responsibility; SALT does not guarantee retention
Unauthorized read access to archive contents (confidentiality) Optional Inner seal covers integrity. Optional outer-layer encryption (user-supplied passphrase) covers confidentiality. Sealed Ledger holds no decryption keys.
Selective omission during capture (records the source has but doesn't return) Mitigated SALT records what the API returns; structural integrity checks surface inconsistencies

Threat model in detail

Attacker capabilities considered

The threat model assumes an attacker may have any combination of the following capabilities:

  • Possession of the sealed archive. The attacker holds the bundle and can modify, replace, or selectively present its contents.
  • Access to the source system before capture. The attacker can edit, delete, or fabricate records inside QuickBooks before SALT runs.
  • Computational resources. The attacker has access to commodity computing power, not nation-state-level resources.
  • Time. The attacker may attempt offline forgery over arbitrary periods.
  • Knowledge of SALT's methodology. The attacker has read this paper and the schema. SALT's security does not depend on secrecy.

The attacker is assumed not to have:

  • The TSA's private key
  • The ability to break SHA-256 cryptanalytically
  • The ability to forge RFC 3161 signatures

What SALT defends against

Post-capture tampering

This is SALT's primary protection. Once the archive is sealed and time-stamped:

  • Any modification to the database file changes its SHA-256 hash, which the TSA token does not match.
  • Any modification to a row's data without a corresponding update to its _raw_json_sha256 creates a row-level mismatch detectable by anyone with sha256sum.
  • Modifying both the row and its provenance hash still changes the bundle hash, breaking the TSA signature.

To successfully tamper, an attacker would need to also forge a new TSA signature — which requires the TSA's private key.

Backdating and replay

The TSA's genTime is part of what the TSA signs. An attacker cannot move the timestamp backwards without invalidating the signature. Likewise, a TSA token signs a specific hash; using it against a different archive produces a verifiable mismatch.

Forgery without TSA key

SALT does not introduce a Sealed Ledger signing key. The cryptographic authority comes from the external TSA, not from us. There is no Sealed Ledger key to compromise, no Sealed Ledger insider attack, no Sealed Ledger key-management failure mode that affects existing seals.

What SALT does not defend against

Confidentiality of archive contents

SALT addresses integrity — proving the data is unchanged since capture. SALT does not, by itself, address confidentiality — preventing unauthorized parties from reading the data. Integrity and confidentiality are independent properties: a properly encrypted archive whose seal is broken is still compromised, and an unencrypted archive whose seal is intact is still defensible as evidence of what was captured.

For engagements where confidentiality matters (most of them), Sealed Ledger delivers bundles under a dual-layer encryption model: an inner seal over the plaintext database (the standard SALT seal), and an outer seal over the encrypted bundle. The outer encryption uses a passphrase the user supplies at delivery time; Sealed Ledger does not retain the passphrase. See the Custody & Handoff document for the operational model and the Verification Guide for the decryption and verification procedure.

Pre-capture source manipulation

This is the most important limit. If a user edits records in QuickBooks Online or QuickBooks Desktop before running SALT, SALT will faithfully capture and seal the modified data. The seal attests to what the source system returned at capture time, not what the source system should have contained.

This limit is structural, not a defect. No software can independently verify the truthfulness of an API response from a third-party platform. Auditors and forensic accountants understand this distinction; SALT's role is to remove every other downstream tampering risk so that the only remaining question is the integrity of the source itself.

Compelled or compromised source platforms

If Intuit (or another source platform) returns falsified data — whether through compromise, legal compulsion, or platform-level error — SALT captures whatever is returned. SALT does not detect platform-level integrity failures.

Custody loss

SALT delivers the bundle to the user. The user is the custodian. Sealed Ledger does not retain copies, does not provide recovery if the bundle is lost, and does not guarantee long-term storage. If the user's storage is destroyed, the archive is gone.

Selective non-presentation

A user holding multiple archives may present only some of them. SALT can prove a presented archive is unmodified, but cannot prove that another archive of the same data does not also exist. This is a custody-of-evidence question, not a cryptographic question.

Mitigated, not eliminated

Future cryptographic compromise

SHA-256 is currently considered cryptographically sound. If a practical break is published in the future, archives sealed today would become unverifiable under the broken algorithm. SALT mitigates this through re-sealing: an existing archive can be hashed under a stronger algorithm (SHA-3, post-quantum hashes) and re-time-stamped, with the original timestamp chain preserved as historical evidence. This is standard practice in long-lived digital archiving.

TSA private key compromise

If a TSA's private key is compromised, signatures issued by that TSA become forgeable retroactively. SALT mitigates this by:

  • Supporting multiple TSAs (FreeTSA as default, commercial and EIDAS-qualified TSAs as options)
  • Allowing an existing archive to be re-time-stamped by additional TSAs to add independent attestation
  • Recording the TSA identity in the seal, making the trust chain auditable

Selective capture omission

If the source platform omits records that exist (intentionally or by error), SALT cannot detect the omission directly — it only sees what the API returned. However, structural integrity checks ran at capture time (debits = credits, transaction-index counts match, linked-transaction targets resolve) surface inconsistencies that often correlate with selective omission. A reviewer evaluating an archive checks the _integrity_checks table for any failures.

Defensive properties SALT depends on

SALT's security claims rest on the following assumptions, listed in decreasing order of confidence:

  • SHA-256 is collision-resistant. Widely accepted as of 2026; mitigated through re-sealing if broken.
  • RFC 3161 time-stamping is unforgeable without the TSA's private key. Standard cryptographic assumption.
  • The TSA operates honestly during the issuance window. An honest TSA refuses to issue tokens with backdated genTime values.
  • The TSA's published certificate is authentic. SALT bundles the certificate at capture time; reviewers verify against the bundled certificate, eliminating dependency on later TSA availability.
  • The archive's possessor handles it without modification. Custody breaks if a chain-of-custody record cannot be maintained, but the seal itself remains verifiable independently.

Out of scope

The following are deliberately not part of SALT's threat model:

  • Authentication of the user who initiated capture (handled by source platform OAuth)
  • Confidentiality of archive contents (encryption at rest is the user's responsibility once delivered)
  • Legal admissibility (a property of jurisdictions, courts, and case-by-case rulings — not a technical property)
  • Audit acceptance (a property of auditing firms and engagement standards — SALT enables, does not guarantee)

Reviewer summary

A reviewer evaluating SALT's appropriateness for a particular use case should ask:

  • Is post-capture tampering the primary risk? If yes, SALT addresses it directly and well.
  • Is pre-capture source integrity already established by other means? (Bank statement reconciliation, prior tax filings, third-party records.) If yes, SALT complements those and provides the freeze-frame protection they cannot.
  • Is the user the appropriate custodian? If yes, the non-custodial delivery model is a feature. If a third-party custodian is required (e.g., a litigation hold), the bundle should be delivered to that custodian directly.
  • Is the retention horizon decades or longer? If yes, plan for re-sealing as cryptographic standards evolve.

For most engagement contexts — migration, cleanup, audit defense, dispute resolution — SALT's defenses cover the threat surface that matters and disclose what they don't cover. That combination is what makes the seal defensible.

This document is published as a draft and may be revised. Substantive changes are versioned; reviewers should reference the document version recorded alongside any specific archive.