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.