Skip to content

Threat_Model.md

Latest commit

 

History

History
89 lines (72 loc) · 4.81 KB

Threat_Model.md

File metadata and controls

89 lines (72 loc) · 4.81 KB
Raw

Threat Model: Fastcomcorp ZINA v1.1.x

Project: Fastcomcorp libzina (Post-Quantum Secure Messaging) Status: Formal Model for Reviewers Last Updated: February 24, 2026

1. Introduction

This document outlines the security architecture and threat model for ZINA. It defines the trust boundaries, high-value assets, and the capabilities of various adversaries. It provides reviewers with a structured view of how ZINA defends against both classical and future quantum-computing threats.

2. Security Assets (What we protect)

Asset Category Description
Message Content Confidentiality The plaintext of user communications.
User Identity Privacy Long-term identity keys (X448, Falcon-512) and social graph.
Forward Secrecy Integrity Protection of past messages if current keys are compromised.
Post-Compromise Security Resilience The ability of the protocol to recover security after key theft.
Metadata Protection Privacy Routing information, device IDs, and message timestamps.
Attachment Integrity Integrity Assurance that files haven't been tampered with in storage.

3. Adversary Model

We evaluate ZINA against four distinct adversary classes:

A. Passive Network Adversary ("The Global Watcher")

  • Capability: Eavesdrops on all network traffic between peers and relays.
  • Goal: Decrypt content or mapping social graphs through traffic analysis.
  • ZINA Defense: PQ-Handshake and Hybrid Double Ratchet ensure all traffic is encrypted with AEAD.

B. Active Network Adversary ("The Man-in-the-Middle")

  • Capability: Can drop, modify, inject, or replay messages. Can attempt protocol downgrades.
  • Goal: Impersonate peers or force sessions into weaker (v1/v2) crypto states.
  • ZINA Defense: Ed448/Falcon-signed ratchets and Sticky Versioning prevent unauthorized downgrades or key injections.

C. Compromised Infrastructure ("The Malicious Relay")

  • Capability: Controls the transport or persistent storage servers (CDNs/Relays).
  • Goal: Link sender/receiver IDs or access attachments.
  • ZINA Defense: Header Obfuscation conceals the social graph from relays. Out-of-band file encryption ensures relays only hold encrypted blobs.

D. Future Quantum Adversary ("Harvest-Now, Decrypt-Later")

  • Capability: Records current traffic to decrypt it once cryptographically relevant quantum computers (CRQC) exist.
  • Goal: Retrospective decryption of classical DH exchanges.
  • ZINA Defense: ML-KEM-768 integration in every handshake and sparse ratchet ensures that recorded traffic remains secure against future Shor-algorithm attacks.

4. Trust Boundaries & Data Flow

graph TD
    subgraph "Local Trust Zone (Peer A)"
        UA[User Application]
        ZEA[Zina Engine]
        DBA[(SQLite Store)]
    end

    subgraph "Untrusted Zone (Network)"
        RL[Message Relay]
        CDN[File Storage]
    end

    subgraph "Local Trust Zone (Peer B)"
        UB[User Application]
        ZEB[Zina Engine]
        DBB[(SQLite Store)]
    end

    UA -- plaintext --> ZEA
    ZEA -- encrypted envelope --> RL
    RL -- encrypted envelope --> ZEB
    ZEB -- plaintext --> UB
    
    ZEA -- "encrypted blobs (v3)" --> CDN
    ZEB -- "download/decrypt" --> CDN
    
    ZEA -.-> DBA
    ZEB -.-> DBB
Loading

5. Threat Summary & Mitigations (STRIDE)

Threat Type Potential Vector ZINA Mitigation Strategy
Spoofing Forged ratchet keys Authenticated Ratchet: Every ratchet key is signed with Ed448/Falcon (FIPS 204).
Tampering Modified ciphertext AEAD (AES-256-GCM): All payloads and metadata use authenticated encryption with AAD binding.
Repudiation Identity misuse Hybrid Handshake: Identity keys are bound to the session via DH5 and PQ-KEM shared secrets.
Info Disclosure Social graph leak Header Obfuscation: Routing metadata is encrypted under a session-derived protection key.
DoS Fuzzing/Malformed proto Protocol Hardening: Strict Protobuf parsing and dedicated fuzzing suite for core logic.
Elevation Protocol Downgrade Sticky Versioning: Established v3 sessions explicitly block demotion to v1/v2 legacy modes.

6. Known Limitations & Residual Risks

  • Traffic Analysis: While headers are obfuscated, message timing and volume patterns (e.g., typing indicators) may still leak metadata to sophisticated observers.
  • Endpoint Compromise: If the host device (OS) is compromised at the root level, SQLite stores and memory can be dumped, bypassing cryptographic protections.
  • Manual Verification: SAS (Short Authentication Strings) or manual fingerprint verification is required to establish the initial "Root of Trust" against a MITM during the very first exchange.