Skip to main content

VIP-THREAT-001

VeriSeal Threat & Adversarial Model​

Version: 2.0
Status: Normative Security Profile
Classification: Public Security Specification

1. Scope

This document defines the formal adversarial and threat model applicable to:

  • VIP-STD-001 (Integrity Core)
  • VIP-STD-002 (Ledger Profile)
  • VIP-STD-003 (Signature Profile)
  • VIP-STD-004 (Time Anchoring Profile)
  • VIP-STF-005 (Verification & Conformance Framework)

This document defines:

  • Security objectives
  • Asset classification
  • Adversary capabilities
  • Attack surfaces
  • Formal security claims
  • Residual risks

2. Security Objectives

The VeriSeal Integrity Framework aims to guarantee:

  1. Deterministic integrity
  2. Tamper detection
  3. Structural immutability
  4. Cryptographic authenticity (if signature profile used)
  5. Ledger continuity
  6. Independent time corroboration (if anchoring profile used)

The framework explicitly does NOT guarantee:

  • Truthfulness of content
  • Identity validation (unless external system used)
  • Legal enforceability
  • Semantic correctness
  • Content legitimacy

VeriSeal is an integrity framework, not a truth system.

3. Assets

The following assets are security-critical:

  • Canonical proof object
  • Deterministic proof_hash
  • Ledger entry
  • previous_entry_hash continuity
  • Signature material
  • Anchoring reference
  • Verification metadata

Integrity of these assets MUST be preserved.

4. Adversary Classes

4.1 Passive Observer​

Capabilities:

  • Full read access
  • Traffic observation

Cannot:

  • Modify stored data

4.2 Active Modifier​

Capabilities:

  • Attempt record modification
  • Attempt record substitution
  • Attempt ledger reordering

4.3 Cryptographic Attacker​

Capabilities:

  • Attempt hash collision
  • Attempt signature forgery
  • Attempt anchor forgery
  • Attempt replay

Bounded by classical cryptographic assumptions.

4.4 Insider Adversary​

Capabilities:

  • Modify records before sealing
  • Compromise private keys
  • Manipulate storage layer

Mitigation is operational, not protocol-level.

5. Threat Categories

5.1 Serialization Attacks​

Attack: Manipulating field ordering or encoding to change hash.

Mitigation:

  • Strict canonicalization (VIP-STD-001)
  • Byte-level determinism
  • Deterministic hashing

5.2 Hash Substitution​

Attack: Replacing proof_hash with alternative value.

Mitigation:

  • Deterministic recomputation
  • Signature binding (VIP-STD-003)

5.3 Ledger Reordering​

Attack: Reordering entries to manipulate chronology.

Mitigation:

  • previous_entry_hash chaining
  • Deterministic ledger verification

5.4 Replay Attacks​

Attack: Reusing valid proof in unintended context.

Mitigation:

  • Unique proof_id
  • Context binding
  • Time anchoring (optional)

5.5 Signature Attacks​

Includes:

  • Forgery
  • Malleability
  • Weak randomness

Mitigation:

  • Deterministic signing (RFC 6979)
  • Low-S normalization (ECDSA)
  • Ed25519 preferred
  • Secure key management (implementation requirement)

5.6 Anchor Forgery​

Attack: Providing fabricated external time references.

Mitigation:

  • Publicly verifiable anchoring systems
  • Independent recomputation
  • Multi-anchor strategies (optional)

6. Trust Boundaries

Trust boundaries exist between:

  1. Proof generation
  2. Ledger storage
  3. Signature authority
  4. Anchor authority
  5. Verification actor

The protocol assumes:

  • Independent verifier
  • Public anchor transparency
  • Secure key custody

7. Formal Security Claims

Under classical cryptographic assumptions:

If:

  • SHA-256 remains collision resistant
  • ECDSA / Ed25519 remain secure
  • RSA factoring remains computationally infeasible

Then:

  • Tampering is detectable
  • Ledger rewriting is detectable
  • Signature forgery is infeasible
  • Anchor falsification is detectable

These guarantees degrade proportionally if assumptions fail.

8. Residual Risks

The framework does not eliminate:

  • Private key compromise
  • Weak entropy in signature generation
  • Implementation bugs
  • Storage corruption
  • Insider manipulation before sealing
  • Denial-of-service attacks

These are outside protocol guarantees.

9. Denial of Service

The protocol does not provide:

  • Storage exhaustion protection
  • Anchor endpoint availability guarantees
  • Network flooding resistance

Operational mitigation required.

10. Post-Quantum Considerations

Version 2.0 does not provide post-quantum security.

Future revisions MAY include:

  • Hash agility
  • PQ signature algorithms
  • Hybrid signature modes

11. Conclusion

The VeriSeal framework provides deterministic tamper detection under classical cryptographic assumptions.

Security guarantees depend on:

  • Strict canonicalization
  • Deterministic hashing
  • Correct ledger chaining
  • Secure key management
  • Publicly verifiable anchoring

Implementation discipline is mandatory.

VeriSeal defines integrity guarantees — not trust guarantees.