Skip to main content

9. Threat Model

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

9.1 Purpose

This chapter is the canonical threat model for Enkrypted Chat on the website. It supersedes informal “zero server” claims and consolidates themes from in-house security-audit and threat-model materials in the p2p repository.

9.2 Adversaries in scope

AdversaryCapabilityIn scope
Passive network observerTraffic analysis, metadataYes
Active network attackerMITM on non-crypto pathsYes
Malicious peerSend malformed ciphertext, protocol abuseYes
Compromised signaling serverSDP/ICE manipulation, presence trackingYes
Malicious CDN / federated hostServe trojaned JavaScriptYes
State-level / APTResource-rich compromiseYes (design consideration)

9.3 Primary assets

AssetSensitivityLoss impact
Message plaintextCriticalConfidentiality breach
Signal/MLS private keysCriticalSession compromise
File contentsCriticalData exfiltration
Local OPFS vaultHighDevice compromise
Peer IDs & contact graphMediumMetadata deanonymization
Federated module integrityCriticalFull platform compromise

9.4 Threat scenarios and mitigations

9.4.1 Signaling MITM

Threat: Attacker on signaling path substitutes SDP to redirect media/data to themselves.

Mitigations:

  • Use WSS and trusted self-hosted broker.
  • Future: bind identity keys to signaling (TOFU/QR — not v1 spec).
  • Application E2EE limits impact on content if session keys already established; initial handshake is highest risk.

9.4.2 Malicious JavaScript supply chain

Threat: CDN or federation host serves backdoored bundle.

Mitigations:

  • Self-host all remotes (Chapter 8).
  • CSP, SRI where applicable.
  • Subresource integrity review on deploy.

9.4.3 Malicious peer

Threat: Peer sends invalid frames to crash or confuse parser.

Mitigations:

  • Strict decryption failure handling (no plaintext on error).
  • Input validation on envelopes.
  • Fuzzing and audit (planned).

9.4.4 TURN traffic analysis

Threat: Relay operator correlates timing and volume.

Mitigations:

  • Direct P2P when possible.
  • User-operated TURN.
  • VPN (user responsibility).

9.4.5 Local device compromise

Threat: Malware reads OPFS or memory keys.

Mitigations:

  • At-rest encryption (WIP).
  • OS-level device security (out of app scope).

9.5 STRIDE summary

CategoryExampleControl
SpoofingFake peer ID on brokerPeer ID is not authenticated globally — limitation
TamperingCiphertext bit flipAEAD at cascade + transport
RepudiationDeniable messagesSignal-style deniability (layer-dependent)
Information disclosureMetadata at TURNDisclosure + user config
Denial of serviceFlood data channelRate limits (partial)
ElevationN/A browser sandboxBrowser isolation

9.6 Audit and verification status

  • Independent security audit: Not yet completed; arrangements in progress.
  • In-house audit docs: Available in p2p/security-audit/ (engineering reference).
  • Formal verification: Signal core — see formal verification; does not cover full web stack.

9.7 Residual risk statement

Even if all mitigations work as designed, Enkrypted Chat MAY NOT protect against:

  • Compromised endpoint (browser extension, malware)
  • Sophisticated traffic analysis on TURN/VPN exit
  • Social engineering of peer IDs
  • Undiscovered implementation vulnerabilities

Users with high-threat models SHOULD wait for independent audit results or deploy self-hosted infrastructure with expert review.