Arquitectura técnica móvil

Contenido

Esta página explica cómo la aplicación móvil de Crisis Connect establece confianza, transporta mensajes y llamadas cifrados de extremo a extremo mientras hay internet, sigue funcionando mediante Bluetooth directo cuando las redes caen y promueve al personal de respuesta a rutas seguras.

Código abiertoemirhan-duman/Crisis-Connect

BLE + RFCOMM

Ruta predeterminada de incidente

Wi-Fi Aware + GATT

Capas de extensión controladas

AES-GCM + ECDH

Perfil de confianza seguro

Android 1.0.4 · iOS 1.1.0

Versiones públicas de tienda

Crisis Connect es un sistema de comunicación de emergencia que prioriza el funcionamiento sin conexión. Mientras hay internet ofrece mensajería cifrada de extremo a extremo, además de llamadas de voz y video; cuando fallan o se saturan internet y la infraestructura celular, la misma aplicación sigue funcionando mediante las radios de corto alcance de teléfonos cercanos. La arquitectura base de Android mantiene la ruta de incidente en Bluetooth local, construye la capa en línea sobre envolventes cifrados de extremo a extremo, añade capas de expansión solo cuando la política lo permite y trata la nube como un plano de entrega y confianza que nunca ve contenido en texto claro.

Resumen del sistema

Ruta de mensajes sin conexión primero: Los dispositivos cercanos se descubren mediante Bluetooth y luego intercambian cargas seguras a través de transporte local punto a punto, sin depender de internet

Capa en línea: Mientras hay internet, los mensajes viajan como envolventes cifrados de extremo a extremo, las llamadas uno a uno usan WebRTC y los reportes SOS llegan a paneles de respuesta autorizados

Inicio explícito de confianza: Los contactos conocidos se aprovisionan fuera de banda con QR, mientras que el Modo Rescate solo promueve a personal de respuesta verificado a un chat bidireccional seguro

Modelo de expansión controlada: Existen malla de personal autorizado y coordinación pública amplia, pero son independientes, tienen controles de acceso y deliberadamente no se consideran la ruta predeterminada

La nube no ve el contenido: Los servicios de backend gestionan la emisión de certificados, distribución de anclas de confianza, sincronización de telemetría y entrega de envolventes cifrados; nunca pueden leer el contenido cifrado de extremo a extremo

Modelo operativo

Supuestos, alcance y límite de capacidad actual

Crisis Connect está diseñado para ser útil en ambos estados: mensajería y llamadas cotidianas cifradas de extremo a extremo mientras hay internet, y coordinación local que sigue funcionando cuando las redes de área amplia caen. El peso de las decisiones de arquitectura está en ese segundo momento: los teléfonos cercanos todavía funcionan y los operadores necesitan una capa de coordinación local controlada, no ilimitada.

Supuesto de prioridad sin conexión: La aplicación está diseñada para incidentes en que internet y el servicio celular no están disponibles o se saturan, pero los teléfonos cercanos aún tienen batería y radios utilizables.

Cliente preinstalado: La participación civil supone que una versión compatible de la aplicación ya está instalada antes de perder conectividad, o que aún puede distribuirse mediante un flujo local aprobado mientras siga siendo posible instalarla.

Envolvente de radio local: La comunicación se basa en la proximidad. Bluetooth es la ruta predeterminada, mientras que Wi-Fi Aware se reserva para sesiones de malla de personal autorizado en dispositivos compatibles.

Conjunto de capacidades actual: Texto seguro y actualizaciones de ubicación, voz opcional punto a punto, Modo Rescate, chat de malla para personal autorizado, mensajería por internet cifrada de extremo a extremo, llamadas de voz y video WebRTC y sincronización opcional de telemetría de Crisis Link forman parte del alcance actual.

Postura de contención de rumores: La mensajería civil se limita de forma predeterminada a contactos conocidos, el SOS está abierto al descubrimiento pero verificado para el chat seguro, y la coordinación pública amplia sigue siendo voluntaria y acotada.

Principios de diseño

Local antes que la nube

El sistema está diseñado para funcionar por completo sin internet. La capa en línea complementa la ruta de emergencia sin conexión en lugar de sustituirla; las cargas de emergencia por proximidad permanecen en rutas de radio de dispositivo a dispositivo.

Directo antes que malla

El comportamiento predeterminado es Bluetooth punto a punto. Los modos de mayor alcance solo se añaden bajo controles explícitos de rol, capacidad y operador.

Ejecución acotada

El diseño asume energía limitada y condiciones de campo inestables, por lo que los límites de cola, reintento, servicios en primer plano y alcance de una sola llamada de voz son intencionales.

La confianza es explícita

Los contactos solo se habilitan después de un inicio QR y una prueba criptográfica de actividad, y los flujos seguros del personal de respuesta requieren verificación respaldada por certificado.

Pila principal de radio

Descubrimiento y control BLE sobre transporte de carga RFCOMM

La ruta predeterminada de incidente combina dos capas Bluetooth con tareas diferentes. BLE gestiona el descubrimiento ligero, la señalización de servicio y los intercambios de control de rescate, mientras que Bluetooth Classic RFCOMM transporta el tráfico punto a punto más pesado de texto, ubicación, multimedia y voz opcional.

Capa de descubrimiento y control

BLE (GAP/GATT)

Señalización de presencia, intercambios cortos de control, anuncio del Modo Rescate y descubrimiento de bajo consumo

Descubrimiento de pares de bajo consumo y difusión de presencia local para dispositivos cercanos

Intercambios de autenticación y control que preparan sesiones seguras antes de transferir cargas pesadas

Comportamiento de baliza SOS y señalización a nivel de servicio para flujos del Modo Rescate

Capa de transporte de carga

Bluetooth Classic RFCOMM/SPP

Transporte punto a punto fiable para texto, ubicación, multimedia y voz opcional

Sesiones directas de mayor rendimiento entre pares cercanos tras lograr el descubrimiento

Transferencia segura de mensajes, imágenes, archivos y voz mediante un protocolo definido por la aplicación

La compatibilidad puede incluir alternativas de socket seguras o inseguras, por lo que la seguridad de los mensajes se aplica por encima del socket

Entorno operativo: El alcance indicativo es de unos 50-150 m en línea de visión abierta, 30-80 m en entorno urbano o con obstáculos mixtos, 10-30 m en interiores y 5-20 m con obstrucción tipo escombros. Como el alcance y el comportamiento del socket varían entre dispositivos, la confidencialidad se establece en la capa de aplicación y no se presupone solo por el modo RFCOMM.

Extensiones controladas

Cómo la base se amplía más allá de Bluetooth directo

El sistema amplía deliberadamente su alcance en capas cuidadosamente separadas. Tanto la malla segura de personal de respuesta como la coordinación pública amplia son funciones reales de la base, pero existen bajo reglas distintas de confianza, activación y gobernanza.

Malla de personal de respuesta autorizado

La línea de lanzamiento de Android incluye una extensión opcional de chat grupal seguro mediante Wi-Fi Aware para roles autorizados de administración y equipos de campo. Permanece desactivada a menos que se superen las comprobaciones de certificado de rol y capacidad de plataforma.

Canal público GATT voluntario

Puede activarse una malla GATT pública independiente desde Configuración avanzada para chat general y anuncios cercanos. Tiene alcance amplio de forma deliberada y debe tratarse como tráfico de coordinación no confidencial.

Controles explícitos de activación

La malla de personal de respuesta requiere un rol local válido y hardware compatible. La malla pública permanece desactivada salvo que la persona active explícitamente el modo de malla pública.

Controles acotados contra abuso

El perfil declarado de canal público fija el máximo de saltos en 4 y aplica una ventana de marcas de tiempo, presupuesto de inundación por fuente, límites de tamaño de mensaje, supresión de duplicados y una cola de retransmisión acotada.

Inicio de confianza

Aprovisionamiento QR antes del incidente

Los contactos conocidos se incorporan antes de un incidente mediante intercambio QR. El objetivo es sacar el establecimiento de confianza de la ruta de emergencia para que el primer contacto no dependa de internet activo ni de un inicio improvisado de claves dentro de la banda.

Aprovisionamiento fuera de banda: El intercambio QR contiene el material de confianza necesario para activar contactos conocidos y reduce el trabajo de inicio durante el incidente.

Aceptación flexible de cargas: La base de Android acepta JSON canónico `dcs://{...}`, variantes JSON codificadas como URI y cargas heredadas delimitadas por barras verticales para reducir fallos en terreno.

Política de descubrimiento: El emparejamiento usa una ventana principal de nombre de dispositivo de 15 segundos, una ventana de candidatos alternativa de 8 segundos y una validación desafío-respuesta de 10 segundos tras el emparejamiento.

Activación operativa: Un contacto no se marca como listo solo porque el escaneo QR tuvo éxito. Primero deben completarse el emparejamiento a nivel de sistema operativo y la confirmación cifrada de actividad.

Este flujo es práctico para un conjunto de confianza acotado, como una familia, un equipo de respuesta o un inventario de dispositivos administrados. No es un modelo de emparejamiento improvisado a escala poblacional, y la implementación civil supone que la aplicación se instaló antes de perder conectividad.

Modelo de identidad y confianza

PSK para contactos y certificados para personal de respuesta

Crisis Connect usa rutas de confianza distintas para relaciones distintas. Los contactos conocidos y el personal de respuesta verificado no comparten el mismo modelo de inicio, autorización ni recuperación.

Ruta segura de contactos conocidos

Los contactos aprovisionados mediante QR usan secretos compartidos previamente y cifrado autenticado en la ruta segura designada. En el perfil base reforzado, los fotogramas de negociación ya no llevan material de claves dentro de la banda.

Autenticación del personal de respuesta

Las interacciones de rescate validan sin conexión certificados de rol ECDSA con una clave pública de autoridad anclada, comprobando firma, UID del propietario, ámbito de rol y ventana de validez antes de la promoción segura.

Elegibilidad para malla

Las sesiones autorizadas de malla Wi-Fi Aware requieren un certificado de rol local válido y compatibilidad de plataforma. Los intentos de unión no autorizados se rechazan antes de activar el chat de malla.

Ciclo de vida de claves y certificados

Los certificados de rol tienen corta duración en la base (perfil actual del emisor: TTL de 72 horas). Las claves de identidad local residen en AndroidKeyStore, el resto del material sensible se protege en almacenamiento cifrado y un estado de personal de respuesta ausente o vencido obliga a renovar o volver a aprovisionar.

Ciclo de vida del mensaje

Del descubrimiento al avance de ACK

Esta sección cubre el ciclo de vida de las rutas seguras de proximidad (Bluetooth); la mensajería por internet se trata en la sección Capa en línea. En la ruta de proximidad, los datos se cifran en el dispositivo emisor y se descifran en el receptor. Si un par está sin conexión o temporalmente fuera de alcance, la entrega espera un enlace local en lugar de salir por un relé en la nube.

01El descubrimiento BLE y la señalización de control indican la disponibilidad del par y preparan la sesión local.

02La configuración del enlace RFCOMM abre el transporte de mayor rendimiento usado para texto, ubicación, contenido multimedia y voz opcional.

03La activación de contactos conocidos usa fotogramas desafío-respuesta `HSK_REQ` y `HSK_ACK`; la sesión solo está activa tras superar la validación con tiempo límite.

04Los fotogramas `SEC_MSG` llevan cargas cifradas por el emisor identificadas por UUID de mensaje, IV y texto cifrado; el receptor verifica AEAD antes de la persistencia local.

05El avance de `ACK` mueve los mensajes en cola por los estados entregado y leído sin duplicar registros persistidos por UUID.

06Las transferencias de voz, imágenes y archivos cambian a familias de registros JSON tipados con fragmentación, ventanas de reintento y comprobaciones de integridad al finalizar.

07Las reglas de reproducción, duplicados e idempotencia se basan en la unicidad de UUID, cachés acotadas y comportamiento de rechazo en el receptor, en vez de suponer un enlace perfecto.

08El canal general GATT público está lógicamente separado de estas rutas seguras designadas y no debe tratarse como transporte confidencial.

Postura del protocolo: En la base de Android, el tráfico RFCOMM son registros UTF-8 delimitados por salto de línea, con líneas de control delimitadas por barras verticales y familias JSON tipadas para flujos más ricos de multimedia o control de llamadas.

Ruta de voz

Opus sobre Bluetooth punto a punto

La voz es opcional y deliberadamente conservadora. Funciona como transmisión entre pares en tiempo real sobre el transporte punto a punto, se cifra antes de enviarse y debe evaluarse tanto frente a la batería como a la estabilidad de radiofrecuencia.

Perfil de voz

CodecOpus

Frecuencia de muestreo16 kHz

Trama / paquete10 ms x 5 = ~50 ms

Objetivos de tasa de bits20 kbps WB / 16 kbps NB

Búfer de fluctuación20-50 ms (30 ms default)

Objetivo de búfer~70-100 ms

Secuencia de llamada

01El audio se captura, codifica con Opus, cifra y envía por el enlace RFCOMM activo en lugar de una pila multimedia de internet independiente.

02El alcance base supone una sesión de voz activa por enlace punto a punto; varias llamadas de voz simultáneas en un dispositivo quedan fuera de alcance.

03Un bucle de control de un segundo puede alternar entre perfiles de banda ancha y estrecha, con una pausa de seis segundos y ACK de configuración negociados antes de aplicar cambios de perfil.

04La evidencia piloto debe informar tiempo de establecimiento de llamada, pérdida, distribución de latencia e impacto incremental en batería bajo condiciones de escenario definidas, no solo continuidad anecdótica.

Política adaptativa

La implementación baja de WB a NB cuando aumentan los tiempos de escritura, se repiten insuficiencias o se vuelve inestable la profundidad de fluctuación; solo vuelve a subir tras una recuperación sostenida. Es una política de continuidad acotada, no una garantía universal de calidad de servicio.

Capa en línea

Mensajería y llamadas cifradas de extremo a extremo mientras hay internet

Con conexión a internet, Crisis Connect funciona como una aplicación de mensajería de uso diario: chat cifrado de extremo a extremo, llamadas de voz y video y reportes SOS que llegan a paneles de respuesta autorizados. Esta capa no sustituye a la arquitectura sin conexión; se sitúa encima bajo el mismo principio: el contenido se cifra en el dispositivo y los servidores solo gestionan envolventes cifrados y los metadatos necesarios para la entrega.

Mensajería cifrada de extremo a extremo

Los mensajes, notas de voz y adjuntos salen del dispositivo únicamente como envolventes cifrados de extremo a extremo; los servidores no pueden abrirlos. Cuando ambos lados lo admiten, la sesión usa el protocolo Signal mediante libsignal (Double Ratchet y acuerdo de claves PQXDH poscuántico) con secreto hacia adelante. Una envolvente ECIES autenticada (ECDH P-256 + HKDF-SHA-256 + AES-256-GCM) cubre a clientes antiguos; no ofrece secreto hacia adelante y, una vez que existe una sesión Signal, se rechazan los intentos de degradar a ese formato. La clave de identidad P-256 heredada reside en AndroidKeyStore respaldado por hardware en dispositivos compatibles; la clave de identidad Signal se guarda cifrada en reposo bajo una clave Keystore. Los contactos se pueden verificar con un número de seguridad de 60 dígitos.

Llamadas de voz y video WebRTC

Las llamadas uno a uno usan WebRTC: audio Opus, video de cámara de hasta 720p y uso compartido de pantalla. El contenido multimedia se cifra con DTLS-SRTP, y la señalización SDP e ICE tampoco cruza el servidor en texto claro: viaja dentro de envolventes de mensajes cifrados de extremo a extremo. Cuando no es posible una conexión directa, el contenido cifrado se enruta mediante el relé Cloudflare TURN; las credenciales TURN se generan en el servidor con vida corta y, si el servicio no está disponible, la llamada vuelve a conectividad directa mediante STUN.

SOS por internet

Con internet disponible, el SOS sigue dos rutas separadas. El informe enviado a paneles de respuesta autorizados contiene ubicación, precisión, nivel de batería y país, y deliberadamente no se cifra de extremo a extremo para que los paneles puedan leerlo. La alerta SOS y las actualizaciones de ubicación en vivo enviadas a tus contactos de emergencia viajan como envolventes cifrados de extremo a extremo, como cualquier otro mensaje. Sin conectividad el informe queda en cola y se envía al volver internet; la baliza SOS BLE sigue funcionando como ruta principal sin conexión en todos los casos.

La selección de transporte es automática: si hay un enlace Bluetooth con el par, el mensaje toma la ruta local; de lo contrario usa internet; si ninguno está disponible, espera en la cola de almacenar y reenviar y el mismo chat continúa como una conversación. El límite honesto: el contenido permanece cifrado de extremo a extremo, pero los servidores procesan metadatos de entrega y señalización (identificadores de emisor y receptor, marcas de tiempo, direcciones IP); las copias de envolventes confirmados se eliminan y los no entregados se depuran tras un período acotado.

Modo Rescate

Difusión SOS, verificación de personal de respuesta y promoción a chat seguro

El Modo Rescate separa deliberadamente la capacidad de descubrimiento de la confianza. Se puede encontrar a una víctima sin emparejamiento previo, pero el chat de rescate bidireccional seguro comienza solo después de superar la verificación del personal de respuesta.

01 Signal

Emisión de balizas SOS

El SOS activado por la persona coloca el dispositivo en estado local de emergencia y emite anuncios BLE conectables para el servicio de rescate `0xCC00`.
El contenido del anuncio se mantiene mínimo en la base: la señal de radio expone capacidad de descubrimiento a nivel de servicio, no una identidad autenticada completa.
La difusión SOS está diseñada para mejorar el descubrimiento de personal de respuesta cercano durante barridos por sector cuando las redes de área amplia no funcionan.
El costo de privacidad es explícito: la capacidad de descubrimiento aumenta en modo SOS, por lo que importan el consentimiento, un estado claro en la interfaz y controles de frecuencia.

02 Verify

Verificación del personal de respuesta

Tras conectar, la persona de respuesta y la víctima intercambian desafío y respuesta de autenticación en `0xCC10` y `0xCC11`, y derivan una clave de sesión ECDH efímera.
La prueba de rol cifrada llega en `0xCC20` y debe incluir referencia de certificado, ámbito de rol, hora de emisión y vencimiento.
La validación comprueba firma, ancla de confianza, vinculación de transcripción, vencimiento y autorización de rol antes de permitir una promoción segura.
Las pruebas vencidas, malformadas o de ámbito incorrecto se rechazan en la puerta en lugar de degradarse a chat de rescate.

03 Connect

Chat de rescate seguro

Solo tras una verificación correcta la víctima emite `OK` en `0xCC21`, abriendo la ruta segura.
El chat de rescate bidireccional cifrado continúa entonces en `0xCC30` y `0xCC31` con semántica ACK `DELIVERED` y `READ`.
Las restricciones de la base actual incluyen tamaño acotado de paquete de prueba de rol, fragmentación consciente de MTU y una envolvente de paquetes de chat seguro grande pero finita.
Los clientes no verificados nunca alcanzan el canal de escritura seguro; la puerta de promoción es un límite estricto, no una interfaz meramente orientativa.

La propiedad de seguridad central es que el Modo Rescate no equipara descubrimiento con confianza. El descubrimiento cercano está lo bastante abierto para encontrar víctimas; el chat de rescate seguro no.

Servicios en segundo plano

Ejecuciones en primer plano y alcance de plataforma

La ejecución institucional validada principal sigue siendo la arquitectura de servicios de Android. Hay disponible públicamente un cliente iOS independiente con mensajería centrada en BLE y lógica de rescate controlada por personal de respuesta, pero la evidencia de implementación de nivel profesional debe revisarse todavía para cada plataforma.

SVC-01

RfcommForegroundService

Mantiene el receptor de transporte clásico, la señalización de llamadas y los ciclos de vida de transferencia de multimedia o archivos para sesiones directas cercanas.

SVC-02

GattSOSServerService

Aloja el difusor SOS del Modo Rescate y el punto de interacción segura con personal de respuesta usado por víctimas en flujos de rescate BLE.

SVC-03

GattRescueClientService + MeshAwareService

Gestiona sesiones de rescate BLE del lado de personal de respuesta y, cuando se autoriza, descubrimiento y autenticación de malla Wi-Fi Aware con comportamiento de reconexión acotado.

SVC-04

CrisisLink, herramientas sin conexión y nota sobre iOS

CrisisLinkForegroundService vacía la telemetría en cola tras una recuperación de internet validada, OfflineDownloadService gestiona regiones de mapas sin conexión y el cliente iOS independiente es real, pero aún tiene sus propios controles de preparación pendientes.

Criptografía y modelo de amenazas

Garantías de capa de aplicación ante condiciones de radio inestables

El comportamiento de los sockets Bluetooth y las condiciones de radiofrecuencia varían entre dispositivos, por lo que las garantías de ruta segura se definen en la capa de aplicación. El perfil criptográfico, los supuestos de amenaza y el modelo de custodia de claves son partes explícitas de la arquitectura.

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: The authorized Wi-Fi Aware mesh uses a shared group key; the rescue (GATT) secure-chat handshake derives per-peer session keys via ephemeral ECDH P-256 plus HKDF-SHA-256 and encrypts chat over AES-256-GCM with 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_attested_signing_key`), 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

Internet message envelope: The preferred path for internet messages is the Signal protocol via libsignal (Double Ratchet + post-quantum PQXDH); the compatibility envelope uses ECDH P-256 + HKDF-SHA-256 + AES-256-GCM with AAD bound to sender, recipient, and conversation, and downgrades to the legacy format are rejected once a Signal session exists.

LAYER 08

Call media and TURN: WebRTC calls use DTLS-SRTP encrypted media with call signaling carried inside end-to-end encrypted envelopes; TURN relay only forwards encrypted packets, and credentials are minted server-side with short lifetimes.

LAYER 09

Threat model: The design assumes passive RF eavesdropping plus active replay, spoofing, jamming, device flooding, and cloud-control-plane disruption attempts. On the internet path, servers and relay infrastructure are treated as untrusted for content: plaintext never reaches a server, while delivery metadata remains visible.

LAYER 010

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

La defensa en profundidad aquí implica cifrado en el dispositivo emisor, verificación en el receptor, controles explícitos de rol y una política de metadatos acotada. No elimina el impacto de privacidad de ser detectable por radio.

Privacidad y gobernanza

Metadatos, control de rumores y responsabilidad operativa

La seguridad operativa en desastres depende tanto de un flujo de información acotado como del cifrado. Las decisiones de política, la disciplina de metadatos y la trazabilidad de evidencia son aquí parte de la arquitectura técnica.

Higiene de la información

La comunicación civil predeterminada permanece entre contactos aprovisionados previamente, el descubrimiento SOS está separado del chat seguro y GATT público debe reservar las instrucciones oficiales para formatos de anuncio validados por personal de respuesta.

Política de metadatos en el aire

Las emisiones de incorporación están limitadas en el tiempo, la preparación habitual evita identificadores estables legibles por humanos, el modo SOS expone deliberadamente el UUID del servicio de rescate y la malla pública revela de forma inherente etiquetas de emisor y metadatos de saltos.

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

Outside the proximity emergency path; encrypted envelopes only on the online path

Crisis Connect can run fully offline for contact-to-contact proximity communication. Cloud services do two jobs: trust establishment with operational telemetry support, and encrypted-envelope delivery for internet messaging. At no point can servers open end-to-end encrypted content, and the proximity emergency path keeps working without the cloud.

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.

Delivery

Encrypted-envelope delivery: For internet messaging, the backend stores only encrypted envelopes and routing metadata so messages can reach recipients who are offline; server copies are dropped once delivery is acknowledged, and undelivered envelopes are purged after a bounded TTL.

Trust-plane split: Proximity 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, telemetry synchronization, and encrypted-envelope delivery for internet messages.

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 institutional deployment evidence centers on the Android release line; iOS is publicly available but still needs its own responder-grade readiness evidence.

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

The online layer depends on internet infrastructure; when it fails, that path closes and the app falls back to the proximity Bluetooth path. That is why adding contacts before an incident still matters.

On the internet path, content stays end-to-end encrypted, but delivery, signaling, and relay metadata — identifiers, timestamps, IP addresses — is processed by servers and TURN infrastructure.

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

Everyday end-to-end encrypted messaging plus voice and video calls with distant loved ones while the internet is up

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

Internet-connected victims whose SOS reports are routed to authorized response panels

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: while the internet is up, content travels in end-to-end encrypted envelopes and servers stay blind to it; when networks fail, direct Bluetooth is the default incident path, trust is bootstrapped out of band, secure responder flows are certificate-gated, and the cloud stays outside the proximity emergency path. The system is suitable for evidence-driven institutional pilots around the Android release line, while broader responder-grade rollout should wait for field validation against the declared acceptance gates.

Código abierto

Código fuente e implementación

La arquitectura base de Android y la línea actual de lanzamiento público, incluido el transporte Bluetooth sin conexión como prioridad, la lógica de promoción del Modo Rescate y el plano criptográfico de confianza, se publican abiertamente para su revisión y reproducibilidad.

emirhan-duman/Crisis-Connect

AGPL-3.0Issues

Ver repositorio