The problem
Today's security systems treat identity, encryption, location, and physical proximity as separate concerns. Your device can prove it's genuine, but not where it is. Your messaging app can encrypt messages, but can't stop someone from reading them on a plane after they've left the building. Location services can tell where you are, but can't verify you're a real device or that you're actually near the people you're talking to.
Each of these signals is useful on its own. But none of them are bound together, and attackers exploit the gaps between them: GPS spoofing, credential theft, relay attacks, device emulation.
Loxation closes all of those gaps at once.
The innovation: location-scoped identity
The core insight is deceptively simple. Instead of treating "where you are" as a metadata tag that can be spoofed or ignored, Loxation makes your physical location a constitutive part of your cryptographic identity.
Every device that uses Loxation has a compound identity: deviceId:locationId. The deviceId comes from hardware attestation (Apple Secure Enclave, Android StrongBox, or TPM). The locationId comes from a verified location check.
This means the same physical phone at a downtown bar is a different cryptographic entity than the same phone at home. Different identity, different keys, different group memberships. And since all encryption keys are derived from this compound identity, the keys literally cannot exist outside the location boundary.
When you leave a venue, your keys don't get "revoked" or "suspended." They become mathematically underivable. There's nothing to steal, nothing to exfiltrate, nothing to intercept. The cryptographic room closes behind you.
When you return, the compound identity re-forms, the keys re-derive deterministically from the same group state, and you're back in the room. No server re-issues anything. No new key exchange. The math just works.
Four pillars, one trust object
Loxation binds four independent trust signals into a single cryptographically signed object called the Trust-State Object (TSO). Every cryptographic operation — decrypting a message, joining a group, rotating a key — requires a valid TSO. No exceptions.
Device Attestation
Hardware-backed proof that the device is genuine and unmodified, via Apple App Attest, Android Play Integrity, or TPM. The attestation key is embedded directly into MLS credentials.
Compound MLS Identity
Your identity in the MLS group (RFC 9420) is deviceId:locationId — a different member at each location, with distinct leaf nodes, distinct keys, and distinct group state.
Proximity Verification
BLE and UWB ranging prove you're physically near other group members. Ephemeral BLE identifiers are cryptographically linked to your MLS identity. Relay attacks fail because physics can't be faked.
Geospatial Constraints
Loxation works everywhere with a global default identity. Venues, businesses, and organizations can register their own locationId — via GPS, BLE beacons, or building footprint — which activates the full Cryptographic Room: location-bound keys, auto-departure, and physical data confinement.
The TSO is signed by the device's hardware-protected key and has a short validity window (30 seconds to 5 minutes). It's never cached to disk. When any signal lapses — your attestation expires, you walk out of range, your bearer token times out — the TSO becomes invalid and all cryptographic operations stop immediately.
What the Trust-State Object contains
Every TSO binds all four trust signals into a single verifiable structure:
attestation_hash: H(device attestation token)
bearer_token_hash: H(server-issued bearer token)
compound_identity: deviceId:locationId
mls_identity_hash: H(leaf node + epoch + credential keys)
proximity_evidence: H(BLE/UWB measurements)
location_id: verified locationId from bearer token
validity_window: [now, now + Δ]
nonce: random (prevents replay)
No single component is sufficient. Device attestation alone doesn't prove location. Location alone doesn't prove device integrity. Proximity alone doesn't bind to identity. The TSO requires all four to be valid simultaneously.
One identity, every protocol
The compound identity doesn't just work for MLS group messaging. It serves as a universal cryptographic root from which Loxation derives keys for every protocol it uses:
MLS Group Messaging
RFC 9420 group key agreement with TreeKEM. Forward secrecy, post-compromise security, groups up to 50,000 members.
Bluetooth Direct Channels
Noise Protocol Framework over BLE. One-to-one encrypted channels where static keys are derived from the compound identity. Messages never leave the room.
Nostr Relay Messaging
NIP-17 private messages with NIP-44 encryption (ChaCha20-Poly1305, secp256k1). Even messages routed through relays are only decryptable at the designated location.
Encrypted Video
Real-time video encrypted with location-scoped keys. The stream is accessible only while participants share the same physical space.
When you leave a location, all protocol-specific keys across every active channel become simultaneously underivable. No per-protocol revocation. No server-side key management. One departure, every door closes.
What this means in practice
For the person using Loxation at a bar on a Friday night, all of this is invisible. They open the app, see who's nearby, and connect. But underneath:
Their device has been attested as genuine by hardware they can't tamper with. Their identity in the group is unique to this specific venue. Their messages are encrypted with keys that can only exist while they're physically present. The people they're talking to have been verified as real devices in the same room. And when they close the app and walk home, everything they said stays behind — cryptographically locked to the place where it happened.
This is not a dating app. It's not a social network. It's a presence layer — and the first one where privacy isn't a promise, it's a mathematical guarantee.
Enterprise applications
The same Trust-State architecture that protects a Friday night out also solves hard enterprise security problems:
Zero-Trust that means it
Share data only with location-authenticated users. Not a hacker on another continent with stolen credentials — a verified device, in a verified room, near verified peers.
Automated Key Rotation
OAuth2 client secrets and API keys rotate via a two-phase (prepare/promote) workflow, distributed through MLS end-to-end encryption. Keys never transit in plaintext.
Active Directory Hardening
Quorum-approved, MLS-secured directory changes with dry-run diffs, staged activation (epochs), and rollback windows across Microsoft AD, Samba, OpenLDAP, and FreeIPA.
Data Confinement
Sensitive documents and communications are cryptographically confined to physical boundaries. Data doesn't just have access controls — it has physics.
Technical documentation
Explore the protocols, specifications, and design decisions behind Loxation:
The room just changed.
Real time. Real place. Real people.