Threat Model

This document is intended for security researchers, auditors, and contributors. It provides a structured analysis of the attack surface, adversary capabilities, cryptographic guarantees, and residual risks for the Connect proximity-based decentralized social application.

The analysis is grounded in the concrete architecture described elsewhere in this research: Ed25519 identity keypairs, NFC/QR-bootstrapped trust, BLE-based proximity discovery, Signal Protocol (Double Ratchet) for 1-to-1 sessions, MLS (RFC 9420) for groups, append-only encrypted local feeds, and an optional Tor relay layer.

1. Scope and Trust Boundaries

In Scope

The following components and interactions are within scope of this threat model:

Out of Scope

The following are explicitly out of scope, with rationale:

Trust Boundary Diagram

  ┌─────────────────────────────────────────────────────────────────────┐
  │                        DEVICE BOUNDARY                              │
  │                                                                      │
  │   ┌──────────────┐     ┌──────────────────┐    ┌─────────────────┐ │
  │   │  Key Store   │     │  Message Store   │    │  Contact Store  │ │
  │   │  (OS keystore│     │  (encrypted      │    │  (encrypted,    │ │
  │   │   / secure   │     │   append-only    │    │   local-only)   │ │
  │   │   enclave)   │     │   feed DB)       │    │                 │ │
  │   └──────┬───────┘     └──────────────────┘    └─────────────────┘ │
  │          │                                                           │
  │   ┌──────▼─────────────────────────────────────────────────────┐   │
  │   │                    Application Logic                        │   │
  │   │  (Double Ratchet state, MLS group state, feed validation)   │   │
  │   └──────┬─────────────────────────────────────────────────────┘   │
  │          │                                                           │
  └──────────┼──────────────────────────────────────────────────────────┘
             │  TRANSPORT BOUNDARY
  ┌──────────┼──────────────────────────────────────────────────────────┐
  │          │                                                           │
  │   ┌──────▼──────┐   ┌──────────────┐   ┌──────────────────────┐   │
  │   │  BLE Radio  │   │  NFC Radio   │   │  WiFi Radio          │   │
  │   │  (rotating  │   │  (~10cm tap) │   │  (WiFi Direct /      │   │
  │   │   beacons,  │   │              │   │   WiFi Aware)        │   │
  │   │   ~30m)     │   │              │   │                      │   │
  │   └──────┬──────┘   └──────┬───────┘   └──────────┬───────────┘   │
  │          │                 │                        │               │
  └──────────┼─────────────────┼────────────────────────┼──────────────┘
             │                 │                        │
  ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─
             │                 │              CONTACT    │  BOUNDARY
  ┌──────────▼─────────────────▼────────────────────────▼──────────────┐
  │                      PEER DEVICES                                    │
  │  (authenticated contacts — encrypted channel, content still private) │
  └──────────────────────────────┬──────────────────────────────────────┘
                                 │  (opt-in only)
  ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
                      INTERNET / RELAY BOUNDARY
  ┌──────────────────────────────▼──────────────────────────────────────┐
  │                      TOR NETWORK (opt-in)                           │
  │   Guard node → Middle node → Exit/Rendezvous → Hidden service       │
  │   (cannot see message content; may observe traffic timing/volume)   │
  └─────────────────────────────────────────────────────────────────────┘

Threat Surface Map

Each boundary above has a distinct exposure profile:

Boundary Exposed to Primary Risk
Device interior OS, apps with device access Key extraction, data exfiltration
BLE radio Any nearby device with BLE scanner Traffic analysis, relay attacks, fingerprinting
NFC radio Device within ~10cm MITM (extremely difficult), coercion
WiFi radio Devices within WiFi range Traffic volume analysis, SSID leakage
Contact boundary Authenticated peer devices Compromised contact, feed enumeration
Internet / Tor Network operators, relay operators Traffic correlation, timing analysis

2. Adversary Types

2.1 Passive Observer

Profile: An attacker in physical proximity with commodity hardware — a BLE sniffer (e.g., Ubertooth One, nRF52840 dongle), a WiFi packet capture device, or a dedicated radio scanner. May also be a party conducting mass BLE advertisement harvesting in a public space.

Capabilities:

Motivation: Surveillance of individual movement patterns, commercial tracking (retail analytics, ad targeting), or intelligence collection. May be operating automated infrastructure (e.g., Bluetooth tracking arrays in transit systems).

Realistic threat scenarios:

2.2 Active Local Attacker

Profile: An attacker within BLE or WiFi range who can not only observe but also transmit — sending crafted packets, replaying captured frames, or running a rogue BLE peripheral. May use tools like Wireshark, BTLEJuice, or custom firmware on BLE development boards.

Capabilities:

Motivation: Targeted attack on a specific individual, research into the protocol's security, bypassing proximity requirements to interact with a device from a distance.

Realistic threat scenarios:

2.3 Compromised Contact

Profile: A legitimate contact — someone who performed an NFC tap or QR exchange with the target in person — who has subsequently become hostile. This could be a trusted person who has been coerced, had their device compromised, or who was a malicious actor from the beginning.

Capabilities:

Motivation: Personal grievance, law enforcement cooperation, intelligence agency asset, opportunistic abuse of access.

Realistic threat scenarios:

2.4 Infrastructure Adversary

Profile: An entity with visibility into network traffic: an Internet Service Provider, a CDN operator, a Tor relay operator, or a government entity with access to backbone routing infrastructure. Only relevant when the app is operating in online (Tor) mode.

Capabilities (online mode only):

Capabilities (offline mode):

Motivation: Mass surveillance, targeted surveillance of specific individuals, lawful intercept compliance.

Realistic threat scenarios:

2.5 State-Level Adversary

Profile: A national intelligence agency or law enforcement body with broad capabilities: physical access to devices through border crossings or arrests, the ability to serve legal orders, traffic correlation across multiple vantage points, and potentially the resources to attempt cryptanalytic attacks on weakened implementations.

Capabilities:

Motivation: National security investigations, political surveillance, transnational crime investigation, suppression of dissent.

Realistic threat scenarios:

2.6 Device Theft / Loss

Profile: An attacker who has physical possession of a lost or stolen device, but does not have the user's PIN, password, or biometric credential. The device may be locked or unlocked.

Capabilities (locked device):

Capabilities (unlocked device):

Motivation: Opportunistic (resale), targeted (surveillance), accidental.

Realistic threat scenarios:

3. Attack Surface by Layer

3.1 Physical / Trust Establishment Layer

This is the most security-critical layer because it is where long-term identity binding occurs. An attacker who can subvert trust establishment can impersonate a user to their contacts from that point forward.

NFC MITM (Man-in-the-Middle)

Feasibility: Extremely Low in Practice

An NFC MITM would require an attacker to simultaneously:

  1. Intercept the outbound NDEF frame from Device A before it reaches Device B
  2. Substitute a modified or attacker-controlled payload
  3. Forward a crafted response back to Device A — all within the NFC handshake timing window

The fundamental constraint is NFC's operating range: ~4–10cm. To relay an NFC session, the attacker needs hardware physically adjacent to both devices simultaneously. Research by Hancke (2005) and subsequent work has demonstrated NFC relay attacks using custom hardware, but these require the attacker to be essentially touching both devices. In a real-world trust establishment scenario (two people choosing to tap phones), the social and physical geometry makes this attack implausible rather than impossible.

Additionally, the cryptographic protocol defends against MITM even if relay were achieved: both parties compute an X3DH shared secret using each other's authenticated public keys. An attacker who relays the key exchange without substituting their own key gains nothing — they are transparent to the cryptography. An attacker who substitutes their own key is detected if users perform a key fingerprint comparison (recommended UX).

Remaining risk: The app should display a key fingerprint (short authentication string) after the NFC tap, matching the pattern used by Signal's Safety Numbers. Users who compare fingerprints out-of-band detect any MITM. This UX step is not enforced by the protocol and remains a social control.

QR Code Relay Attack

Feasibility: Low to Moderate

A QR code encodes the same payload as the NFC tap: Ed25519 public key, ephemeral DH key, and application identifier. The attack scenario:

  1. Attacker photographs or screen-records the target's displayed QR code
  2. Attacker displays the captured QR code to a second victim, who scans it
  3. The second victim establishes a trust relationship with the attacker instead of the intended target

The QR code is typically displayed for only a few seconds during the explicit scanning ceremony, reducing the window for capture. However, a high-resolution photo taken from a distance (social engineering: "let me take a photo of you") could capture a sufficient image.

Mitigations:

Coercion (Forced Trust Establishment)

Feasibility: Moderate (social/physical attack)

An attacker could physically force or socially coerce a user to perform an NFC tap against the attacker's device. This is not a protocol vulnerability — the protocol has no mechanism to distinguish a voluntary tap from a coerced one.

The defense is social and physical: the tap requires deliberate physical action (bringing devices together), and the app should require explicit confirmation after the tap ("Add [name] as a contact?") rather than auto-completing the exchange. A "duress mode" — where a separate PIN causes the app to complete the tap without storing the contact — is a potential mitigation for high-risk users, similar to the duress password concept in full-disk encryption.

Physical Device Compromise During Tap

Feasibility: Low

An attacker could attempt to interfere with the device hardware during the tap — for example, inserting a USB data exfiltration tool (e.g., O.MG cable) while the phone is charging and the user is distracted. This is a device-level attack (out of scope) but worth noting as a threat scenario for high-risk individuals. The mitigation is standard device hygiene: do not use untrusted charging hardware.

3.2 BLE Discovery Layer

BLE Relay Attacks (Fake Proximity)

Feasibility: Moderate (requires coordinated attacker)

A BLE relay attack forwards BLE frames in real time between two locations, making Device B believe Device A is physically nearby when it is not. This is directly analogous to the relay attacks demonstrated against keyless entry systems. The NCC Group's 2022 research demonstrated BLE relay attacks against the Tesla Model 3 keyless entry system with commodity hardware (two Raspberry Pi units and commercial BLE dongles), achieving sub-75ms relay latency — within the proximity-check window of many implementations.

In the context of this application, the threat model is:

Why this is partially mitigated:

Residual risk: A relay attack in which the attacker controls both the contact's device and a BLE relay can cause the victim's device to sync with the contact's device from a distance, bypassing the proximity requirement for message sync. This is a privacy and usability concern (unexpected sync behavior) but does not compromise message content — the E2E encryption is between the two legitimate endpoint devices.

Mitigation options:

BLE Tracking and Fingerprinting

Feasibility: Moderate

Modern devices rotate their BLE MAC addresses periodically (iOS: every 15 minutes; Android: varies by manufacturer, typically 15–30 minutes). However, several side-channels can relink rotated MACs to the same device:

  1. Advertisement payload continuity: If the app advertises a fixed service UUID or any constant content between MAC rotations, the UUID alone serves as a tracking identifier. The app must rotate all advertisement content at the same time as the MAC.
  2. Timing correlation: If advertisement intervals have a distinctive pattern or if the transition between two MACs occurs at a predictable moment, an observer who captures both can link them.
  3. Device fingerprinting: BLE chipset-level timing jitter, clock drift, and transmission characteristics create a physical-layer fingerprint. This has been demonstrated in academic research (e.g., Becker et al., "Tracking anonymized Bluetooth devices," 2019). This is not mitigable at the application layer — it requires OS or hardware-level randomization.
  4. iOS background advertising stripping: iOS strips the app's service UUID from background BLE advertisements, reducing the identifier surface but also degrading functionality.

Mitigations in scope:

Any information included in a BLE advertisement is visible to all nearby scanners before authentication. The advertisement payload must therefore contain no identifying information. The correct design is:

Advertisement payload (pre-authentication, visible to all):
  - A random or rotating service UUID (no fixed app identifier in the UUID itself)
  - A rotating nonce or ephemeral value
  - No public key, no contact ID, no app name string

GATT exchange (post-connection, before mutual auth, visible to attacker):
  - A challenge-response handshake using shared contact keys
  - Only if the remote device demonstrates knowledge of a shared secret
    does identity information pass over the channel

Leaking the app's service UUID in advertisements is equivalent to broadcasting "this is a Connect app user" to all nearby scanners, enabling enumeration of app users in a physical space.

Wormhole Attack via BLE Mesh

Feasibility: Low

In a mesh scenario where devices forward BLE beacons for contacts-of-contacts (not currently in scope for this design), a wormhole attack would allow an attacker to tunnel packets from one part of the mesh to another, creating a false adjacency in the network graph. Since this design explicitly does not implement friends-of-friends replication or BLE mesh forwarding by default, the wormhole attack surface is not present in the current architecture.

If mesh capabilities are added in the future, wormhole defenses (geographic leashes, timing leashes, directional antennas) should be evaluated.

Denial of Service (BLE Jamming)

Feasibility: High (with commodity hardware)

The 2.4 GHz ISM band used by BLE is shared with WiFi (channels 1, 6, 11) and other devices (microwave ovens, Zigbee, etc.). Targeted BLE jamming with a software-defined radio (SDR) can disrupt BLE communications in a specific area.

Impact assessment: BLE jamming prevents message sync but does not compromise data confidentiality or integrity. Messages are locally stored and will sync the next time the devices are in range without interference. This is a denial-of-service against availability, not a security breach. The hash-chain integrity of feeds means that even if a jamming attacker injects corrupted data during a partial transmission, the receiving device will reject it upon verification.

3.3 Cryptographic / Session Layer

Key Compromise (Device Theft, Malware)

If an attacker obtains the device's long-term Ed25519 private key — either through physical access to an unlocked device, OS malware, or forensic extraction — the following is true:

Forward Secrecy Guarantees (Double Ratchet)

The Double Ratchet algorithm provides forward secrecy through two mechanisms:

1. Symmetric-key ratchet (KDF chain):
   After each message is sent or received, the chain key advances:
     chain_key_n+1 = KDF(chain_key_n, "ratchet")
     message_key_n = KDF(chain_key_n, "message")
   The message key is used once and then deleted.
   Compromising chain_key_n reveals nothing about chain_key_n-1 (KDF is one-way).

2. Diffie-Hellman ratchet:
   Periodically, a new DH key pair is generated and exchanged.
   The new DH output is fed into the root KDF, resetting the chain.
   This provides break-in recovery: even if chain_key_n is compromised,
   the next DH ratchet step restores security.

What forward secrecy guarantees:

What forward secrecy does NOT guarantee:

Post-Compromise Security (Break-in Recovery)

Post-compromise security (also called "future secrecy" in some literature) is the property that, after a key compromise, security is automatically restored once a new DH ratchet step occurs. The Double Ratchet provides this by design.

Recovery timeline:

  T=0   Attacker obtains current session state (chain key, DH key)
  T=1   Alice sends Bob a message — includes her new ephemeral DH public key
  T=2   Bob receives the message and performs a DH ratchet step
        - New root key derived from the DH exchange
        - Attacker, who does not have Bob's new DH private key,
          cannot derive the new root key
        - All subsequent messages are outside the attacker's visibility

This is a strong property: even if an attacker has a persistent read on the session state at one moment, they lose that access after the next natural DH ratchet exchange. The key question is how often DH ratchet steps occur — in the Double Ratchet, every message exchange in the opposite direction triggers a new DH ratchet, so the window is one round-trip.

MLS Group Add/Remove Security

MLS (RFC 9420) provides the following guarantees for group membership changes:

Adding a member:

Removing a member:

Commit attacks:

Group membership and social graph:

Ratchet State Corruption

If the Double Ratchet state is corrupted (e.g., a partial write during message processing, a crash, or storage corruption), the session may become unrecoverable. This is not a security vulnerability per se but has security implications:

3.4 Data / Feed Layer

Feed Tampering

The append-only feed uses a hash chain to ensure integrity: each message contains the hash of the previous message, and the chain is anchored to the user's identity by an Ed25519 signature.

  message_n = {
    prev_hash:   SHA-256(message_n-1),
    sequence:    n,
    content:     ciphertext,
    timestamp:   Unix time,
    author_sig:  Ed25519-Sign(identity_key, prev_hash || sequence || content || timestamp)
  }

An attacker who does not possess the author's Ed25519 private key cannot produce a valid signature over a tampered message. A validator rejects any message with an invalid signature or a prev_hash that does not match the preceding message. This makes feed tampering by third parties provably impossible given the cryptographic assumptions.

Exception: The author themselves can produce invalid chains (equivocation — issuing two different messages with the same sequence number and prev_hash but different content). This is a specific threat in systems where a single author communicates with multiple disconnected parties. A legitimate user will not do this accidentally; a malicious user might create a fork (send message M to Alice, and a different message M' to Bob, both with the same prev_hash). Recipients in different network partitions would receive inconsistent views of the feed. This is the "double-spend" problem applied to feeds, and mitigating it requires either a central sequencer (undesirable) or a gossip-based consistency protocol among contacts.

Feed Replay

An attacker could capture a valid feed message and re-inject it at a later time. The sequence number and prev_hash fields prevent this: a replayed message has a sequence number and prev_hash that do not match the current head of the chain. Recipients who maintain their local copy of the feed will reject any message that does not correctly extend the chain.

Edge case: If a recipient has not yet received some messages (gap in their local copy), they may not be able to detect a replay of older messages that fills the gap with the correct sequence numbers. Message timestamps and the requirement to process messages in order mitigate but do not fully eliminate this.

Feed Enumeration

A contact who has access to the feed can enumerate all entries shared with them. This is by design — the feed is shared. The security question is whether contacts can learn more than intended:

Storage Compromise (Device Seized)

If the device is seized by authorities or a thief and the storage is extracted:

3.5 Online Relay Layer (Opt-in Tor)

This section applies only when the user has enabled online mode. In offline-only mode, this entire attack surface does not exist.

Tor Deanonymization Risks

Tor provides anonymity by routing traffic through at least three relays, preventing any single relay from knowing both the sender and the recipient. However, Tor's anonymity is probabilistic and conditional:

Relay Correlation Attacks

The most powerful class of attack against Tor is traffic correlation: matching the timing and volume of traffic entering and leaving the Tor network at two points. This does not require breaking any cryptography and is limited by the attacker's network vantage points.

Against this application:

Hidden Service Enumeration

Tor hidden services (.onion addresses) are derived from public keys and are not registered in any central directory. An .onion address by itself does not reveal the operator's identity. However:

Guard Node Compromise

In Tor, the guard node is the first relay in the circuit — the one that sees the client's real IP address. The Tor client keeps a small set of persistent guard nodes ("entry guards") to reduce the risk of eventually connecting through a malicious guard.

4. STRIDE Analysis

The following table maps STRIDE threat categories across each application layer.

Status key: M = Mitigated | P = Partial mitigation | R = Residual risk

Threat Layer Description Status Notes
Spoofing Trust establishment Attacker impersonates a contact during NFC/QR M Ed25519 signatures; key fingerprint comparison
Spoofing BLE discovery Attacker replays beacon to impersonate known contact M Cryptographic GATT handshake required post-discovery
Spoofing Session layer Attacker forges messages in an active session M Double Ratchet message authentication
Spoofing Feed layer Attacker injects fake feed entries M Ed25519 author signature over hash chain
Spoofing MLS groups Attacker claims to be a group member M Group membership keyed to MLS ratchet tree
Tamper BLE transport Attacker flips bits in BLE GATT frames M AEAD encryption provides integrity
Tamper Feed layer Attacker modifies stored feed entries M Hash chain + signature invalidates tampered entries
Tamper Ratchet state Attacker corrupts local session state P Detection via MAC failure; recovery requires new key exchange
Tamper App binary Attacker replaces the app with a trojanized version R Out of scope (OS/app store security); signing mitigates partially
Repudiation Message delivery Sender denies sending a message P Ed25519 signature provides cryptographic authorship; deniability is limited
Repudiation Feed entries Author denies posting P Signature is non-repudiable; key compromise creates ambiguity
Repudiation Group actions Member denies add/remove action M MLS commit is signed; audit log in group history
Info Disclosure BLE advertisement Device identity leaked in advertisements P Rotating beacons; chipset fingerprinting not mitigable at app layer
Info Disclosure BLE GATT Message content leaked pre-authentication M Authentication required before any contact-identifying data exchanged
Info Disclosure Session content Message content intercepted in transit M Double Ratchet AEAD encryption
Info Disclosure Feed storage Stored messages read by attacker P App-level database encryption; OS FDE; residual: unlocked device
Info Disclosure Social graph Contact list extracted P Local-only storage; residual: device compromise, compromised contact
Info Disclosure Tor relay Message content seen by relay M E2E encryption; relay sees only ciphertext
Info Disclosure Tor traffic timing Communication pattern inferred by correlation R Cover traffic mitigates; full elimination not achievable
Denial of Service BLE layer Jamming disrupts sync R Accepted; does not compromise data; messages sync when interference clears
Denial of Service BLE GATT Malformed GATT frames crash parser P Strict input validation required in implementation
Denial of Service Feed layer Infinite feed growth fills storage P Pruning strategy needed; hash chain integrity prevents corruption DoS
Denial of Service Tor relay Relay becomes unavailable R Tor network resilience; local offline mode unaffected
Elevation of Privilege Trust establishment Attacker forces addition as contact R Physical coercion; app confirmation prompt partially mitigates
Elevation of Privilege MLS group Group member gains admin rights M MLS role and proposal validation
Elevation of Privilege OS/app layer App escalates OS privileges via exploit R Out of scope; OS security model
Elevation of Privilege BLE connection Unauthenticated GATT client reads privileged data M Authentication gates all sensitive GATT characteristics

5. What the Architecture Provably Defeats

These are security properties that hold by structural argument — not just by good implementation, but by the fundamental design of the system.

Mass Surveillance (Offline Mode)

In offline mode, no IP packets are transmitted. There is no ISP to subpoena, no DNS query to log, no CDN to serve legal orders to. An infrastructure adversary — even a nation-state with full backbone visibility — has zero traffic to analyze. The attack surface for mass surveillance collapses entirely.

This is not a matter of good policy or legal compliance — it is a structural property. The system cannot be mass-surveilled in offline mode because there is no network traffic to observe.

Social Graph Extraction

No central graph exists. The complete social graph of the application's users is never assembled in any one place. Each device holds only its own contact list (encrypted, local). There is no friend-of-friend traversal, no directory, no graph database. An adversary who compromises a single device learns only that device's contacts — a local subgraph, not the global network.

An adversary who compromises every device learns the complete graph, but this requires attacking each device individually. There is no single point of extraction equivalent to compromising a social network's database.

Message Content Interception

End-to-end encryption with the Double Ratchet means that any party who intercepts ciphertext in transit — whether on a BLE channel, a WiFi channel, or the Tor network — receives only random-looking bytes. Without the recipient's private key and the current ratchet state, the ciphertext is computationally indistinguishable from random data (assuming correct AES-256-GCM / ChaCha20-Poly1305 implementation).

Server Compromise

There is no server. An adversary cannot execute a "server compromise" attack because there is no application server to compromise. The design eliminates this entire class of attack by architecture.

Retroactive Surveillance

Forward secrecy (Section 3.3) means that even if an adversary compromises a device today, they cannot decrypt messages sent before the compromise (assuming those chain keys have been deleted). "Harvest now, decrypt later" is ineffective for messages whose keys no longer exist.

Caveat for post-quantum threats: A classical adversary cannot break the current cryptography. A future quantum adversary could attack the key exchange (ECDH/X25519) but not the symmetric encryption (AES-256 remains secure against quantum adversaries with Grover's algorithm doubling the effective key search space). The hybrid PQXDH design (adding ML-KEM-768) provides forward secrecy even against a future quantum adversary for messages sent after PQXDH deployment.

6. What the Architecture Mitigates (but Doesn't Eliminate)

BLE Relay Attacks

Mitigated by: NFC/QR requirement for initial trust establishment. A relay attack on BLE alone cannot introduce a new contact — it requires relaying NFC, which is physically infeasible at useful distances.

Not eliminated: Relay attacks against the BLE sync phase with an already-known contact are possible with coordinated hardware. The impact is bounded: the attacker can cause sync to occur at the wrong physical location, but cannot read the synced content.

Residual: Challenge-response timing mitigates most relay attempts; RSSI-based thresholds reduce but do not eliminate distance amplification.

BLE Fingerprinting

Mitigated by: MAC address rotation (OS-level), advertisement content rotation (app-level), avoiding fixed service UUIDs in pre-authentication advertisements.

Not eliminated: Chipset-level physical-layer fingerprinting (timing jitter, clock drift) cannot be mitigated at the application layer. An adversary with specialized radio hardware and enough observation time may be able to re-link a rotated MAC to a previously seen device. This has been demonstrated in academic settings; the practicality in operational deployments against a motivated adversary is real but requires sustained close-range observation.

Platform Surveillance (iOS/Android OS-Level BLE Scanning)

Mitigated by: The app's rotating beacons and encrypted advertisement content make the payload opaque to the OS vendor.

Not eliminated: iOS and Android have OS-level access to BLE scan results — including which apps trigger scans and at what times. Apple and Google's telemetry systems (if enabled) may log BLE activity metadata. The app can minimize what it puts in advertisements, but it cannot prevent the OS from observing that BLE scanning is occurring and attributing it to the app.

Users who require protection against platform-level surveillance should use a de-Googled Android distribution (e.g., GrapheneOS) with network permissions restricted. This is a user and platform choice, not an application design concern.

Key Revocation in Offline Mode

Mitigated by: Contacts can be manually removed. The revoked contact will not receive new messages.

Not eliminated: In a fully offline scenario, there is no mechanism for a user to broadcast "my device was stolen, do not trust new messages from my old key." Contacts who are not physically reachable cannot be notified. A stolen device can be used to impersonate the user to any contact who does not independently verify the compromise.

7. Residual Risks (Accepted)

These are risks that the architecture acknowledges but cannot eliminate by protocol design alone. They are accepted as part of the system's threat model.

Device-Level Compromise (OS Malware, Forensic Access to Unlocked Device)

An adversary with root-level OS access or physical access to an unlocked device can read all app data, including decrypted messages, key material, and contact lists. No application-layer defense can protect against a fully compromised OS.

Acceptance rationale: Defending against OS-level compromise requires hardware security enclaves (Secure Enclave on iOS, StrongBox on Android) and careful key management. The architecture should leverage these where available (storing long-term keys in hardware-backed keystores), but cannot fully prevent a sophisticated adversary from extracting data from a compromised device.

Mitigation direction: Use OS hardware keystores for long-term keys, implement app-level database encryption with a separate PIN, and recommend that users enable full-disk encryption and strong device passcodes.

Physical Coercion

A user can be compelled — by violence, legal authority, or social pressure — to unlock their device, add a malicious contact, or share their screen. No cryptographic system defends against wrench attacks.

Acceptance rationale: This is a fundamental limitation of any security system. Mitigations (duress modes, minimal data retention) can reduce the value of a coerced disclosure but cannot prevent coercion itself.

iOS Background BLE Reliability

iOS imposes significant restrictions on background BLE advertising and scanning. Apps in the background advertise with reduced duty cycle and stripped service UUID data. This means discovery reliability degrades when the app is not in the foreground.

Security impact: None. This is a UX and availability risk, not a security risk. Users who do not have the app foregrounded may miss proximity sync opportunities.

Acceptance rationale: The limitation is platform-imposed and not mitigable without using private Apple APIs. The architecture accepts degraded discovery performance on iOS in exchange for operating within the platform's permission model.

Post-Quantum: Current Classical Cryptography

Current key exchange (X25519, Ed25519) is vulnerable to a sufficiently powerful quantum computer running Shor's algorithm. No cryptographically-relevant quantum computer exists today, and current estimates suggest at least a decade before such capabilities emerge.

Acceptance rationale: The hybrid PQXDH design (adding ML-KEM-768) mitigates the "harvest now, decrypt later" threat for messages exchanged after PQXDH deployment. Classical keys are used in combination with post-quantum keys so that breaking one does not break the other. This provides security parity with Signal's current PQXDH deployment.

The residual risk is: messages exchanged before PQXDH deployment, using only classical keys, are retroactively vulnerable if a quantum adversary harvested the ciphertext and later builds a quantum computer. For most users, this is an acceptable risk given the timeline involved.

Feed Equivocation (No Global Sequencer)

An adversarial author can produce two valid feed forks — different message M and M' with the same sequence number and prev_hash — and distribute them to different contacts. Without a global ordering mechanism, there is no protocol-level way to detect this.

Acceptance rationale: This is a fundamental property of distributed append-only logs without a central sequencer (the same problem SSB faces). The mitigations are: contacts who encounter the same feed in gossip can compare hashes and detect forks; UI can flag inconsistency; and the social consequences of provable equivocation (contacts can identify the author as the source of the fork) provide a deterrence effect. Full elimination would require a central sequencer, which violates the no-server design principle.

8. Security Properties Summary Table

Property Offline Mode Online (Tor) Mode Notes
Message confidentiality Yes Yes Double Ratchet AEAD; Tor adds transport-layer encryption
Message integrity Yes Yes AEAD authentication tag; hash-chain feed integrity
Sender authentication Yes Yes Ed25519 signatures on all feed entries and key exchanges
Forward secrecy Yes Yes Double Ratchet chain key deletion; MLS epoch progression
Post-compromise security Yes Yes DH ratchet step restores security after state compromise
Anonymity from contacts No No Contacts know your public key by design (trust establishment)
Anonymity from network observers Yes Partial Offline: no network traffic. Online: Tor hides IP but traffic correlation is a residual risk
Social graph privacy Yes Partial Offline: graph is local-only. Online: Tor relay cannot see graph; guard node sees connection times
Metadata protection (content timing) Yes Partial Offline: no observable network metadata. Online: Tor timing correlation is a known risk
Metadata protection (social graph) Yes Partial See social graph privacy above
Offline viability Yes N/A Primary design mode; full functionality without internet
Post-quantum resistance Partial Partial Hybrid PQXDH for key exchange; symmetric ciphers are PQ-safe; classical-only for devices without PQXDH update
BLE tracking resistance Partial Partial MAC + content rotation mitigates passive tracking; chipset fingerprinting is a residual risk
Feed integrity (tamper-evident) Yes Yes Hash chain + Ed25519 signatures are deterministically verifiable
Group forward secrecy (MLS) Yes Yes MLS epoch advancement on member removal excludes ex-members from new epoch keys

9. Audit Readiness

What a Third-Party Auditor Would Focus On

A security audit of this system should prioritize components where implementation errors directly translate to cryptographic breaks — as opposed to areas where the design itself provides the security guarantee.

Priority 1 — Cryptographic integration:

Priority 2 — BLE handshake and session setup:

Priority 3 — Key storage:

Priority 4 — Trust establishment flow:

Priority 5 — Feed integrity:

Components Requiring Most Urgent Review

Ranked by risk and complexity:

  1. Double Ratchet state management — incorrect deletion of message keys or out-of-order handling is the most likely source of forward secrecy failures. Any bug here has direct security consequences.
  2. X3DH / key exchange initialization — the initial key agreement is performed exactly once per contact relationship. A subtle error (wrong AD, wrong KDF input order) silently produces a shared secret that appears to work but is weaker or predictable.
  3. MLS ratchet tree operations — MLS is a complex specification (RFC 9420 is 200+ pages). Correct implementation of the TreeKEM component, blank node handling, and path secret derivation is error-prone.
  4. BLE GATT authentication layer — this is bespoke protocol design and is most likely to contain logic errors that authentication can be bypassed.
  5. OS keystore integration — platform-specific key storage code is often copied from examples that do not enforce hardware-backed storage. Auditors should verify that setIsStrongBoxBacked(true) (Android) and Secure Enclave key generation (iOS) are correctly configured and that the fallback behavior when hardware is unavailable is explicitly designed.

Pre-public alpha (internal audit / threat model review):

Beta / pre-release (code audit):

Post-release (ongoing):

Recommended auditors: Organizations with demonstrated experience in mobile cryptography (Android/iOS Secure Enclave integration), Bluetooth security, and distributed systems security. Relevant prior work would include audits of Signal, Briar, Matrix, or IETF MLS implementations.

This threat model reflects the architecture as of April 2026. It should be reviewed and updated when: the cryptographic stack changes (new algorithms, new library versions), the transport layer changes (new proximity technologies added), the trust model changes (e.g., adding remote follow capability), or a significant new vulnerability in a dependency is disclosed.