Technical

4. Privacy Architecture and Unlinkability Guarantees

4.1 Overview

Loxation is designed around a foundational principle:

Users must be discoverable only in the moment, without creating lasting digital traces in the physical world.

This section describes how Loxation achieves strong, cryptographically enforced privacy and unlinkability while still providing authenticated device identity, secure transport, and trustworthy group membership. Loxation accomplishes this through a strict separation of identities, ephemeral cryptographic primitives at the BLE layer, and authenticated session establishment using App Attest, Play Integrity, and MLS.

The resulting system ensures that no component—neither Loxation itself, nor passive BLE scanners, nor adversarial mesh participants—can use Loxation’s discovery mechanisms to track a user’s movements, infer social patterns, or correlate presence across contexts.

⸻

4.2 Threat Model

Loxation’s privacy architecture is informed by realistic threats arising in environments where BLE communication is used. The primary adversaries include:

Passive Observers

Actors capable of scanning BLE advertisements in public spaces (e.g., retail stores, vehicles, public kiosks, hobbyist scanners). These observers: • cannot decrypt traffic, • but can timestamp occurrences, • correlate repeated identifiers, • and build movement or social graphs.

Active Local Attackers

Devices in physical proximity capable of: • initiating BLE connections, • attempting replay of handshake messages, • or injecting malformed frames.

Curious-but-Non-Malicious Infrastructure

Networked systems such as access points, scanning gateways, or analytics platforms that log BLE presence data by default.

Malicious Mesh Participants

Nodes that join the BLE mesh but attempt to correlate encrypted traffic metadata.

Crucially, because BLE communication is strictly short-range, MITM attacks are significantly less practical than passive tracking attacks. For Loxation, movement correlation and identity leakage are the primary privacy threats.

⸻

4.3 Privacy Design Principles

The Loxation privacy architecture is anchored by four complementary principles:

Principle 1 — No Persistent Identifiers in BLE

No long-lived identifier is ever placed in BLE beacons or negotiable handshake packets, including: • user IDs • device IDs • attestation tokens • MLS participant identities • long-lived public keys

This eliminates the dominant risk of long-term correlation and physical movement profiling.

Principle 2 — Ephemeral Cryptographic Primitives at the Radio Layer

All broadcast cryptographic material (e.g., Noise static public keys) is: • short-lived, • memory-only, • rotated frequently, • never stored on disk.

This ensures that passive observers cannot correlate two BLE sessions as coming from the same device, even over short time intervals.

Principle 3 — Strong Identity Only Inside Encrypted Channels

Device identity, user identity, and membership credentials are never exposed except: • after Noise session establishment, and • only inside encrypted, authenticated channels.

Identity flows upward—never outward.

Principle 4 — Separation of Discovery and Identity

BLE supports anonymous device discovery. MLS, App Attest, and Play Integrity support authenticated identity. The two layers are bridged only after the encrypted Noise channel is established. They never leak into each other.

⸻

4.4 BLE Layer Privacy: Ephemeral Discovery Identity

BLE advertisements are unencrypted by design. Any data placed in an advert can be passively collected and correlated indefinitely. To prevent physical-world tracking, Loxation uses:

4.4.1 Ephemeral Noise Static Keys

Each BLE advertisement carries an ephemeral Noise static public key, regenerated: • per app run, • per session, • or even per advertisement interval in high-privacy modes.

Benefits: • Each advertisement appears as if it came from a completely different device. • Passive observers cannot link two adverts to the same node. • No metadata persists long enough to construct a movement trail.

4.4.2 No Broadcast Device IDs

Loxation never includes: • deviceId, • app installation ID, • MLS ID, • vendor identifiers

in any BLE advertisement or pre-handshake payload.

4.4.3 BLE Address Privacy

BLE Resolvable Private Addresses (RPAs) are enabled and rotated in sync with the Noise ephemeral keys, ensuring: • advertising address changes, • cryptographic beacon changes, • unlinkability across time.

This dual-rotation creates a strong anonymity set even in highly instrumented environments.

⸻

4.5 Secure Session Establishment

Once two Loxation nodes detect each other via ephemeral adverts, they initiate a Noise-based handshake optimized for privacy:

4.5.1 Noise Handshake With PSK Authentication

Loxation employs Noise NNpsk0/NNpsk2 patterns where: • the ephemeral Noise static is visible during the handshake, • identity is not exposed, • authenticity is guaranteed via a PSK derived from: • App Attest (iOS), • Play Integrity (Android), • MLS group secrets.

The handshake provides: • encryption from the first frame, • replay protection, • strong forward secrecy, • identity confidentiality.

4.5.2 DeviceId Only Revealed After Encryption

A stable deviceId—required for MLS membership, server-side authorization, and state continuity—is transmitted: • only inside the encrypted Noise transport channel, • never at the BLE layer.

This ensures: • passive observers cannot see or correlate deviceIds, • active local attackers cannot extract identity without completing the authenticated handshake, • compromised mesh nodes cannot track neighbors outside authenticated groups.

4.5.3 Periodic Rekeying

Noise symmetric keys are rekeyed every: • N kilobytes, or • N minutes.

This ensures: • ciphertext indistinguishability, • limited exposure window if a device is compromised.

⸻

4.6 Identity Layer: MLS and Attestation

After the encrypted Noise tunnel is established:

4.6.1 App Attest / Play Integrity

Used to: • verify the device is authentic, • ensure the app binary is unmodified, • prevent device impersonation.

Attestation proofs never leave the encrypted channel.

4.6.2 MLS Identity

User and group identities are expressed via MLS keys. These identities are: • long-lived, • authenticated, • and never visible to BLE observers.

By design, MLS identity is only usable inside fully encrypted channels.

⸻

4.7 Privacy Guarantees

Loxation’s design provides the following guarantees:

4.7.1 Unlinkability

Two BLE sightings cannot be determined to originate from the same device—even with perfect BLE logs.

4.7.2 Anti-Tracking

No persistent identifier is exposed: • at the BLE physical layer, • in scattering events, • or through cryptographically stable beacons.

4.7.3 Forward Secrecy

Compromise of a single session does not reveal past movement or past rendezvous.

4.7.4 Resistance to Social Graph Inference

Because no stable identifiers ever appear in public broadcasts, adversaries cannot: • determine proximity events, • map social groups, • or infer relationships.

4.7.5 Privacy-Preserving Discovery

Users remain visible only in real time and never leave residual identifiers that persist beyond the local encounter.

⸻

4.8 Summary

The Loxation privacy architecture provides: • anonymous BLE discovery, • unlinkable cryptographic beacons, • encrypted and authenticated Noise channels, • attested and MLS-backed identity inside secure tunnels, • no persistent identifiers outside encrypted contexts, • no ability for third parties to track or profile users, • strong forward secrecy, • multi-layer identity separation, • resilience against passive and active local adversaries.

This architecture allows Loxation to deliver authenticated, trustworthy communication and discovery without sacrificing physical-world privacy, making it one of the first systems to combine strong attestation with real-time anonymity and movement unlinkability.