Security Threat Model

This threat model defines the security goals, adversaries considered, trust assumptions, and explicit limitations of SecurityNet’s design.

SecurityNet is designed to protect the confidentiality and integrity of communications between explicitly authorised participants.

This document outlines:

  • What SecurityNet protects
  • Who it protects against
  • The architectural assumptions it relies on
  • The threats it does not attempt to mitigate

SecurityNet prioritises controlled, private communication for small, high-trust networks operating without cloud infrastructure.

1. Scope & Security Objectives

Primary Objective

To ensure that:

  • Message and file contents remain confidential
  • Session encryption keys cannot be reused or intercepted
  • Communication cannot be read, stored, or analysed by intermediaries
  • No central system can access user communications


Security Goals

SecurityNet is designed so that:

  • Only explicitly paired participants can communicate
  • Each session uses a unique encryption key
  • Each file transfer uses its own delivery key
  • No message or file content is stored centrally
  • No central metadata database storing communication history exists

SecurityNet assumes a default-deny model: communication must be explicitly permitted.

2. Assets Protected

SecurityNet is designed to protect the following assets:

  • Message contents
  • File contents
  • Session encryption keys
  • Per-file delivery keys
  • Permission pairings between users
  • Session integrity

These assets are never stored centrally.

SecurityNet ID Records

The system database stores:

  • The user’s SecurityNet ID (AES-encrypted at rest)
  • Licensing status information

The database does not store:

  • Message contents
  • File contents
  • Session encryption keys
  • Per-file delivery keys

  • Communication content or session data

  • Communication history

The SecurityNet ID is encrypted at rest and is not exposed during session communication.

3. Adversaries Considered 

SecurityNet is designed to protect against:

Network-Level Observers

  • ISPs
  • Network intermediaries

  • Deep Packet Inspection systems

  • Hosting providers

  • Passive traffic monitors

These entities can observe encrypted traffic but cannot read contents.

Mediator Infrastructure Operators

SecurityNet uses a lightweight mediator to introduce trusted devices. The mediator does not handle file data and does not store session content.

The mediator server:

  • Facilitates encrypted session negotiation
  • Exchanges temporary connection metadata

  • Discards session metadata after connection establishment

The mediator does not:

  • Store message content
  • Store file content

  • Store encryption keys

  • Maintain communication logs

All encryption and decryption occur on endpoint devices.

Unauthorised Users

SecurityNet prevents connection attempts without:

  • Mutual SecurityNet ID pairing

  • License owner authorisation within a licensed network

There is no public discovery mechanism.

4. Threats Explicitly NOT Mitigated

SecurityNet does not claim to protect against:

  • Compromised user devices

  • Malware on endpoints

  • Physical device seizure
  • Global traffic correlation attacks
  • Nation-state mass surveillance capabilities
  • Malicious insiders within an authorised licensed network
  • Traffic timing correlation by global observers remains a theoretical risk.

If an endpoint is compromised, SecurityNet cannot guarantee confidentiality.

5. Trust Assumptions

SecurityNet relies on the following assumptions:

  • User devices are not compromised

  • Cryptographic primitives remain secure

  • TLS infrastructure is not broken
  • Mediator and relay servers do not retain logs
  • Users manually verify pairing identities outside the system

SecurityNet is not anonymous-by-default. It is private-by-design within controlled networks.

6. Network Visibility & Traffic Analysis

External observers can see:

  • That encrypted traffic exists

  • The destination IP address of the mediator server or peer device

They cannot see:

  • Message content

  • Files

  • Encryption keys
  • User identities within sessions
  • Contact lists

Traffic is encrypted and transmitted over TLS, resembling standard HTTPS traffic patterns.

Users requiring additional destination privacy may choose to use a VPN or privacy network as part of their broader network configuration.

7. Architectural Boundaries

SecurityNet separates responsibilities:

  • Website infrastructure (UK hosted)

  • VPS mediator infrastructure (Iceland hosted)

  • Endpoint encryption engines (user devices)

Encrypted content never passes through or is stored by the website infrastructure.

The mediator facilitates session negotiation only.

All content encryption and decryption occurs on endpoint devices.

8. Design Philosophy

SecurityNet is not:

  • A social messaging platform

  • A cloud communication service

  • A metadata-harvesting system

It is a controlled, peer-to-peer encrypted communication environment designed for small, high-trust groups.

SecurityNet minimises central infrastructure to reduce attack surface.