Mobile Technical Architecture

Contents

This page explains how the Crisis Connect Android app establishes trust, moves messages offline, promotes responders into secure paths, and keeps cloud services out of emergency content relay.

BLE + RFCOMM

Default Incident Path

Wi-Fi Aware + GATT

Controlled Extension Layers

AES-GCM + ECDH

Secure Trust Profile

Android v0.9.7

Current Android Version

Crisis Connect is an offline-first emergency communication system for the period when internet and cellular infrastructure are unavailable or overloaded but nearby phones still have power and short-range radios. The Android v0.9.7 implementation keeps the primary incident path on local Bluetooth, adds tightly controlled expansion layers only when policy allows them, and treats cloud services as a trust and telemetry plane rather than as a message relay backend.

System Summary

Offline-first message path: Nearby devices discover each other over Bluetooth, then exchange secure payloads over a local point-to-point transport without relying on the internet

Explicit trust bootstrap: Known contacts are provisioned out of band with QR, while Rescue Mode promotes only verified responders into secure two-way chat

Controlled expansion model: Authorized responder mesh and broad public coordination exist, but they are separate, gated, and intentionally not treated as the default path

Cloud kept out of message relay: Optional backend services support certificate issuance, trust-anchor distribution, and Crisis Link telemetry sync rather than carrying emergency chat traffic

Operating Model

Assumptions, scope, and current capability boundary

Crisis Connect is built for a very specific failure window: wide-area networks are down, nearby phones still work, and operators need a local coordination layer that is conservative by default rather than unlimited by design.

Offline-first assumption: The app is designed for incidents where internet and cellular service are unavailable or overloaded, but nearby smartphones still have battery and usable radios.

Pre-installed client: Civilian participation assumes a compatible app build is already installed before connectivity loss, or can still be distributed through an approved local workflow while installation remains possible.

Local-radio envelope: Communication is proximity-based. Bluetooth is the default path, while Wi-Fi Aware is reserved for authorized responder mesh sessions on supported devices.

Current capability set: Secure text and location updates, optional point-to-point voice, Rescue Mode, authorized responder mesh chat, and optional Crisis Link telemetry synchronization sit inside the current scope.

Rumor-containment posture: Civilian messaging defaults to known contacts, SOS is open for discovery but verified for secure chat, and broad public coordination stays opt-in and bounded.

Design Principles

Local Before Cloud

Emergency payloads stay on device-to-device radio paths. Cloud services, when present, support trust and telemetry rather than message relay.

Direct Before Mesh

Default behavior is point-to-point Bluetooth. Higher-reach modes are layered on only under explicit role, capability, and operator controls.

Bounded Runtime

The design assumes constrained power and unstable field conditions, so queue caps, retry bounds, foreground services, and single-call voice scope are intentional.

Trust Is Explicit

Contacts become operational only after QR bootstrap plus cryptographic liveness, and responder-secure flows require certificate-backed verification.

Primary Radio Stack

BLE discovery and control above RFCOMM payload transport

The default incident path combines two Bluetooth layers with different jobs. BLE handles lightweight discovery, service signaling, and rescue control exchanges, while Bluetooth Classic RFCOMM carries the heavier point-to-point payload traffic for text, location, media, and optional voice.

Discovery and Control Layer

BLE (GAP/GATT)

Presence signaling, short control exchanges, Rescue Mode advertisement, and low-power discovery

Low-power peer discovery and local presence broadcasting for nearby devices

Authentication and control exchanges that prepare secure sessions before heavy payload transfer

SOS beacon behavior and service-level signaling for Rescue Mode workflows

Payload Transport Layer

Bluetooth Classic RFCOMM/SPP

Reliable point-to-point transport for text, location, media, and optional voice

Higher-throughput direct sessions between nearby peers once discovery succeeds

Secure message, image, file, and voice transfer over an application-defined protocol

Compatibility may include secure or insecure socket fallbacks, so message security is enforced above the socket

Operating envelope: Indicative range is roughly 50-150 m in open line of sight, 30-80 m in urban or mixed obstacles, 10-30 m indoors, and 5-20 m in rubble-like obstruction. Because both range and socket behavior vary across devices, confidentiality is anchored at the application layer rather than assumed from RFCOMM mode alone.

Controlled Extensions

How the baseline expands beyond direct Bluetooth

The system deliberately expands scope in carefully separated layers. Secure responder mesh and broad public coordination are both real features in the baseline, but they exist under different trust, activation, and governance rules.

Authorized Responder Mesh

Android v0.9.7 adds an optional secure group-chat extension over Wi-Fi Aware for authorized admin and fieldteam roles. It stays disabled unless both role-certificate and platform-capability checks pass.

Opt-in Public GATT Channel

A separate Public GATT mesh can be enabled from Advanced Settings for nearby general chat and announcements. It is intentionally broad-reach and must be treated as non-confidential coordination traffic.

Explicit Activation Gates

Responder mesh requires valid local role posture and supported hardware. Public mesh stays off unless the user explicitly enables Public mesh mode.

Bounded Abuse Controls

The declared public-channel profile freezes hop ceiling at 4, enforces a timestamp window, per-source flood budget, message-size limits, duplicate suppression, and a bounded relay queue.

Trust Bootstrap

QR provisioning before the incident

Known contacts are onboarded before an incident through QR exchange. The goal is to move trust establishment out of the emergency path so first contact does not depend on live internet or improvised in-band key bootstrap.

Out-of-band provisioning: QR exchange carries the trust material needed for known-contact activation, reducing bootstrap work during the actual incident.

Flexible payload acceptance: The Android baseline accepts canonical `dcs://{...}` JSON, URI-encoded JSON variants, and legacy pipe-delimited payloads to reduce field failure.

Discovery policy: Pairing uses a 15-second primary device-name window, an 8-second fallback candidate window, and a 10-second post-pairing challenge-response gate.

Operational activation: A contact is not marked ready just because the QR scan succeeded. OS-level pairing and encrypted liveness confirmation must both pass first.

This workflow is practical for a bounded trust set such as family, a response team, or a managed device roster. It is not a population-scale ad hoc pairing model, and civilian deployment assumes the app is installed before connectivity loss.

Identity and Trust Model

PSKs for contacts, certificates for responders

Crisis Connect uses different trust paths for different relationships. Known contacts and verified responders do not share the same bootstrap, authorization, or recovery model.

Known-Contact Secure Path

QR-provisioned contacts use pre-shared secrets and authenticated encryption on the designated secure path. In the hardened v0.9.7 profile, handshake frames no longer carry key material in-band.

Responder Authentication

Rescue interactions validate ECDSA role certificates offline against a pinned authority public key, checking signature, owner UID, role scope, and validity window before secure promotion.

Mesh Eligibility

Authorized Wi-Fi Aware mesh sessions require both a valid local role certificate and platform support. Unauthorized join attempts are rejected before mesh chat activation.

Key and Certificate Lifecycle

Role certificates are short-lived in the baseline (current issuer profile: 72-hour TTL). Local identity keys live in AndroidKeyStore, other sensitive material is protected in encrypted storage, and missing or expired responder posture forces refresh or reprovisioning.

Message Lifecycle

From discovery to ACK progression

Secure paths encrypt on the sender device and decrypt on the receiver device. If a peer is offline or temporarily out of range, delivery waits for a local link rather than escaping to cloud relay.

01BLE discovery and control signaling indicate peer availability and prepare the local session.

02RFCOMM link setup opens the higher-throughput transport used for text, location, media, and optional voice.

03Known-contact activation uses `HSK_REQ` and `HSK_ACK` challenge-response frames; the session is live only after timeout-bounded validation succeeds.

04`SEC_MSG` frames carry sender-encrypted payloads identified by message UUID, IV, and cipher text; the receiver verifies AEAD before local persistence.

05`ACK` progression advances queued messages through delivered and read semantics without duplicating UUID-persisted records.

06Voice, image, and file transfers switch to typed JSON record families with chunking, retry windows, and end-of-transfer integrity checks.

07Replay, duplicate, and idempotence rules rely on UUID uniqueness, bounded caches, and receiver-side reject behavior rather than assuming a perfect link.

08The Public GATT general channel is logically separate from these designated secure paths and should not be treated as confidential transport.

Protocol posture: In the Android v0.9.7 baseline, RFCOMM traffic is newline-delimited UTF-8 records with both pipe-delimited control lines and typed JSON families for richer media or call-control flows.

Voice Path

Opus over point-to-point Bluetooth

Voice is optional and intentionally conservative. It runs as real-time peer-to-peer streaming over the point-to-point transport, is encrypted before transmission, and must be judged against both battery and RF stability.

Voice Profile

CodecOpus

Sampling Rate16 kHz

Frame / Packet10 ms x 5 = ~50 ms

Bitrate Targets20 kbps WB / 16 kbps NB

Jitter Buffer20-50 ms (30 ms default)

Buffering Target~70-100 ms

Call Sequence

01Audio is captured, encoded with Opus, encrypted, and sent over the active RFCOMM link rather than through a separate internet media stack.

02Baseline scope assumes one active voice session per point-to-point link; multiple concurrent voice calls on one device are out of scope.

03A one-second control loop can switch between wideband and narrowband profiles, with a six-second cooldown and negotiated config ACKs before profile changes take effect.

04Pilot evidence must report call setup time, loss, latency distribution, and incremental battery impact under named scenario conditions rather than only anecdotal continuity.

Adaptive Policy

The implementation downgrades from WB to NB when write times rise, underruns recur, or jitter depth becomes unstable; it upgrades again only after sustained recovery. This is a bounded continuity policy, not a universal QoS guarantee.

Rescue Mode

SOS broadcast, responder verification, secure chat promotion

Rescue Mode intentionally separates discoverability from trust. A victim can be found without prior pairing, but secure two-way rescue chat begins only after responder verification passes.

01 Signal

SOS Beaconing

User-triggered SOS places the device into a local distress state and emits connectable BLE advertisements for Rescue service `0xCC00`.
Advertisement content stays minimal in the baseline: the radio signal exposes service-level discoverability rather than a full authenticated identity.
SOS broadcast is designed to improve nearby responder discovery during sector sweeps when wide-area networks are down.
The privacy cost is explicit: discoverability increases in SOS mode, so consent, clear UI state, and rate controls matter.

02 Verify

Responder Verification

After connection, responder and victim exchange auth challenge and response on `0xCC10` and `0xCC11` and derive an ephemeral ECDH session key.
Encrypted role proof arrives on `0xCC20` and must include certificate reference, role scope, issuance time, and expiry.
Validation checks signature, trust anchor, transcript binding, expiry, and role authorization before any secure promotion is allowed.
Expired, malformed, or wrong-scope proofs are rejected at the gate rather than downgraded into rescue chat.

03 Connect

Secure Rescue Chat

Only after successful verification does the victim emit `OK` on `0xCC21`, opening the secure path.
Encrypted two-way rescue chat then proceeds on `0xCC30` and `0xCC31` with `DELIVERED` and `READ` ACK semantics.
Current baseline constraints include bounded role-proof packet size, MTU-aware chunking, and a large but finite secure-chat packet envelope.
Unverified clients never reach the secure write channel; the promotion gate is a hard boundary, not advisory UI.

The core security property is that Rescue Mode does not equate discoverability with trust. Nearby discovery is open enough to find victims; secure rescue chat is not.

Background Services

Foreground runtimes and platform scope

The primary runtime today is Android foreground services. A separate iOS client also exists with BLE-centric messaging and responder-gated rescue logic, but the current deployment scope remains centered on Android v0.9.7.

SVC-01

RfcommForegroundService

Maintains the classic transport listener, call signaling, and media or file transfer lifecycles for direct nearby sessions.

SVC-02

GattSOSServerService

Hosts the Rescue Mode SOS broadcaster and the secure responder interaction endpoint used by victims in BLE rescue flows.

SVC-03

GattRescueClientService + MeshAwareService

Handles responder-side BLE rescue sessions and, when authorized, Wi-Fi Aware mesh discovery and authentication with bounded reconnect behavior.

SVC-04

CrisisLink, Offline Tools, and iOS Note

CrisisLinkForegroundService flushes queued telemetry after validated internet recovery, OfflineDownloadService manages offline map regions, and the separate iOS client remains real but still behind its own readiness gates.

Cryptography and Threat Model

App-layer guarantees above unstable radio conditions

Bluetooth socket behavior and RF conditions vary across devices, so secure-path guarantees are defined at the application layer. The cryptographic profile, threat assumptions, and key custody model are explicit parts of the architecture.

LAYER 01

Contact secure path: QR-provisioned contacts use AES-256-GCM with 96-bit IVs and 128-bit tags; hardened handshake frames no longer carry key material in-band.

LAYER 02

Responder certificates: Rescue Mode validates ECDSA P-256 role certificates offline against a pinned authority public key before secure-chat promotion.

LAYER 03

Responder mesh keys: Authorized Wi-Fi Aware peers derive per-peer session keys with ephemeral ECDH P-256 plus HKDF-SHA-256, then encrypt chat with AES-256-GCM and message-bound AAD.

LAYER 04

Nonce and replay policy: CSPRNG-generated IVs, bounded packets-per-key, restart or re-handshake refresh, replay caches, and UUID idempotence are required to keep AES-GCM safe operationally.

LAYER 05

Key custody: Device identity signing keys live under AndroidKeyStore (`dcs_device_identity`), while sensitive symmetric material is stored in encrypted preferences and backup remains disabled.

LAYER 06

Public-channel boundary: Public GATT packets may carry an AES-GCM envelope for integrity and format hardening, but the channel is still treated as non-confidential public coordination traffic.

LAYER 07

Threat model: The design assumes passive RF eavesdropping plus active replay, spoofing, jamming, device flooding, and cloud-control-plane disruption attempts.

LAYER 08

Explicit exclusions: Full OS compromise, user coercion, and nationwide-scale RF jamming remain out of scope, so deployment claims should not imply protection there.

Defense in depth here means sender-device encryption, receiver-side verification, explicit role gates, and bounded metadata policy. It does not erase the privacy impact of being discoverable on radio.

Privacy and Governance

Metadata, rumor control, and operating ownership

Operational safety in disasters depends as much on bounded information flow as on encryption. Policy decisions, metadata discipline, and evidence traceability are part of the technical architecture here.

Information Hygiene

Default civilian communication stays within pre-provisioned contacts, SOS discovery is separated from secure chat, and Public GATT should reserve official instructions for responder-validated announcement formats.

On-Air Metadata Policy

Onboarding broadcasts are time-bounded, routine readiness avoids stable human-readable identifiers, SOS mode intentionally exposes the Rescue service UUID, and public mesh inherently reveals sender labels and hop metadata.

Retention and Anonymization

Message persistence uses UUID-based records, call-event history is trimmed to bounded windows, sensitive keys stay in encrypted local storage, and pilot logs should pseudonymize device IDs and quantize location.

Control Ownership

Operating authorities need explicit owners for certificate issuance, denylist cadence, key rollover, emergency revocation, and the evidence artifacts used in Go or No-Go review.

The trusted-announcement posture on Public GATT is a governance contract more than a closed product guarantee today; downgrade evidence and parser coverage still remain open review items.

Cloud-Assisted Trust Plane

Out of message path by design

Crisis Connect can run fully offline for contact-to-contact communication. When authorities operate cloud services, those systems support trust establishment and operational telemetry, not emergency message relay.

Identity

Identity and issuance: Authorities can issue responder role certificates, rotate keys, and integrate the trust workflow with institutional IAM or a self-hosted IdP such as Keycloak.

Verification

Offline verification support: Devices store trust anchors and policy bundles locally so responder verification can continue without live cloud reachability; denylist snapshots are a deployment extension for connectivity windows.

Setup

Crisis Link telemetry: Authorized responders may queue and later synchronize rescue telemetry snapshots when internet returns, but this channel does not carry emergency chat payloads.

Trust-plane split: Emergency content stays on BLE, RFCOMM, Wi-Fi Aware, or the opt-in Public GATT channel,

while cloud systems handle certificate lifecycle, trust-anchor distribution, and telemetry synchronization.

Production deployments should keep signing keys outside source code and behind HSM, KMS, or Secret Manager-style controls.

Pilot Evidence and Acceptance Gates

What must be measured before broader rollout

Architecture claims here should be judged against field evidence rather than protocol intent alone. Pilot approval should be based on scenario data, not on design intent.

Message delivery success: At least 95% within 30 seconds in indoor or urban scenarios and 85% in rubble-like conditions.

Text latency: End-to-end message latency P95 should stay at or below 5 seconds across planned operating envelopes.

Voice envelope: Median one-way latency should be at or below 150 ms with sustained packet loss at or below 3% during active calls.

Power impact: Standby discovery and active transport or voice drain must stay within mission-defined limits; current Pixel 7a standby evidence is supplemental, not gate-closing.

Responder workflow: SOS, role proof, secure message exchange, and authorized mesh activation should pass 100% of scripted validation scenarios.

Public-channel abuse containment: Malformed or out-of-window public packets should be dropped before relay at >=99%, and unverified responder announcements must never render as trusted alerts.

Recommended Pilot Sequence

Closed responder pilot: Start with a trained device fleet and validate credential issuance, Rescue Mode, background-service behavior, and role-gated mesh activation.

Scenario matrix: Run indoor, urban, open-area, and rubble-like drills with fixed distance bins, RSSI bins, clock-handling notes, and explicit voice continuity or loss traces.

Governance review: Freeze public-channel parameters, document revocation and rollover runbooks, map claims to evidence artifacts, and only then consider phased broader deployment.

Current Evidence Posture

Bluetooth remains proximity-based; coverage is limited by environment, obstruction, hardware, and OS power policy.

The system supports local sector coordination, not guaranteed reach to every victim under all debris conditions.

Default civilian flows depend on direct local links; mesh modes require compatible hardware, explicit enablement, and local-radio proximity.

Public GATT mesh is opt-in, disabled by default, and not recommended as an always-on setting for every user profile.

Sensitive operational content should stay on designated secure paths or role-gated responder channels rather than on broad public coordination surfaces.

Unbounded unmanaged relay or store-and-forward behavior remains out of scope for the validated baseline.

Current validated deployment scope centers on Android v0.9.7; iOS work is real but still carries additional readiness gates.

Device, OS, and OEM battery-management variation can materially change behavior, so pilots must measure fleets rather than assume one-phone results generalize.

SafetyCrisis Connect does not replace official emergency services. When any wide-area path is available, users should still attempt the local emergency number such as 112, 911, or the nationally designated equivalent.

Deployment Scenarios

Pre-provisioned family, team, or roster communication using QR-established trusted contacts

Offline local messaging and location sharing during off-grid travel or remote field work

Earthquake or infrastructure-collapse sweeps where victims expose SOS beacons and responders verify before secure chat

Responder-only secure group chat over Wi-Fi Aware on supported Android hardware

Broad nearby coordination and general announcements through the opt-in Public GATT mesh when explicitly enabled

Voice calls over direct Bluetooth links when the RF and power envelope permits

Offline map download, local survival or utility tools, and emergency-readiness workflows on supported mobile clients

Optional Crisis Link telemetry synchronization to institutional backends after validated internet recovery

Architectural Outcome

Crisis Connect's mobile architecture is intentionally conservative: direct Bluetooth is the default incident path, trust is bootstrapped out of band, secure responder flows are certificate-gated, and cloud services stay outside the emergency message path. The system is suitable for evidence-driven institutional pilots around Android v0.9.7, but broader rollout should wait for field validation against the declared acceptance gates.