Technical documentation

Security Architecture

Station Chat uses several independent security layers rather than one blanket claim of “encrypted.” This page explains what protects identity, mesh traffic, stored data and private conversations — clearly enough for a security team to evaluate.

P-256 device identityHKDF-SHA-256AES-256-GCMLocal-first design
Identity
Prove the device
P-256 identity with challenge-response verification.
Transport
Protect the mesh
Authenticated sessions with directional AES-256-GCM keys.
Storage
Protect what is saved
Sensitive persisted state is encrypted independently at rest.
Architecture at a glance

Two separate concerns, not one chain.

It is tempting to read Station Chat's security as one continuous chain — a device's identity key leading directly into the encryption that protects mesh traffic. That is not how it works. Identity and mesh-session protection are independent mechanisms.

Station identity

P-256 device identity
↓
Challenge-response verification
Proves a returning device is the same identity it previously established.

Mesh session protection

Authenticated peer session
↓
HKDF-SHA-256
↓
Directional AES-256-GCM keys
↓
Encrypted, replay-resistant traffic
Protects traffic sent between authenticated stations.
Important distinction: a device's P-256 identity is not an input to the keys that encrypt mesh traffic. Mesh-session protection starts from the credential the organisation's trusted stations already share.
Layered protection

Each layer has one clear job.

Rather than calling everything “encryption,” Station Chat separates device identity, transport protection, local storage and optional conversation-level privacy.

Station identity

Every desktop station or Stable Mobile device has its own P-256 key pair. On reconnect, it proves possession of its private key through challenge-response verification. A conflicting key is rejected rather than silently accepted.

P-256Challenge-responseIdentity conflict protection

Mesh session protection

Trusted stations mutually authenticate, derive a session key with HKDF-SHA-256, then use separate AES-256-GCM keys for each traffic direction. Strict counters reject replayed or out-of-order messages, and authenticated sessions do not downgrade to plaintext.

HKDF-SHA-256Directional keysReplay resistance

Encrypted local storage

Chat history, configuration and other sensitive Station Chat state stored on disk are protected with AES-256-GCM using storage keys independent from mesh-session keys.

AES-256-GCMAt restIndependent keys

Optional DM end-to-end encryption

All messages already cross the authenticated mesh. Supported direct-message conversations can add a separate, opt-in end-to-end encryption layer so private content remains unreadable to intermediary stations.

OptionalDirect messagesAdditional layer
Trust is explicit

New stations do not simply appear and become trusted.

Station enrollment and approval

A new station receives the organisation credential only after mutual cryptographic proof with an already-trusted station and explicit administrator approval. Enrollment can happen through the mobile QR workflow or directly from an already-licensed desktop station. Administrators can also require newly discovered stations to remain pending until manually reviewed.

Mutual proofAdmin approvalDesktop-to-desktop enrollmentPending review
Local-first by design

Core chat stays local. Internet use is specific and limited.

Group chat, direct messages, files and voice between connected stations travel directly over the permitted local or routed network. Station Chat works within your firewall, VLAN and routing policy — it does not try to bypass them.

Works on your network

  • Group and direct messaging
  • File and voice sharing between connected stations
  • Same-subnet discovery
  • Routed-network connectivity where your network permits it

Internet used when needed

  • Initial license activation
  • Software updates
  • Stable Mobile locating a station
  • Phone push-notification delivery
Common questions

Frequently asked.

Does Station Chat use AES-256-GCM?

Yes. AES-256-GCM authenticated encryption protects both station-to-station mesh traffic and Station Chat's own local data at rest — two separate uses of the same algorithm, with independently derived keys for each.

How are Station Chat mesh connections encrypted?

Two stations that share the same organisation credential derive a session key using HKDF-SHA-256, then use separate directional AES-256-GCM keys for each direction of traffic. A strictly enforced counter prevents replay, and an authenticated connection will not accept unencrypted traffic afterward.

Is station identity the same thing as mesh session encryption?

No. They are separate layers. P-256 identity proves an individual device's identity. Mesh-session encryption protects traffic between stations that already share the organisation credential. Neither one derives the other.

Does Station Chat require internet to send messages?

No. Core station-to-station messaging happens directly over the local or permitted routed network. Internet connectivity is used only for specific features such as initial activation, updates, Stable Mobile station location and push delivery.

Can a new device or station just join without approval?

No. Credential provisioning follows mutual cryptographic proof and explicit administrator approval. Newly discovered stations can also be held for manual review before being trusted.

Are private direct messages encrypted differently from group chat?

Both use the authenticated encrypted mesh. Supported direct messages can additionally enable a separate end-to-end encryption layer for the private conversation.