Contenido
Arquitectura técnica móvil

Arquitectura técnica móvil

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
01

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.
02

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.

03

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.
04

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.
05

Inicio de confianza

Establecer confianza antes o durante un corte
Los contactos pueden establecer confianza local por QR durante un corte. Prepararse reduce la presión, pero no es requisito del protocolo. Los números verificados añaden el directorio en línea y el emparejamiento local Cerca tras una verificación previa.
QR sin internet: dos teléfonos cercanos intercambian datos locales de sesión y cifrado por QR, y verifican y guardan el contacto por Bluetooth; no hay cuenta, SMS, SIM ni consulta al servidor.
Contactos en línea: ambos verifican sus números con internet y el directorio añade al usuario detectable sin QR.
Cerca sin conexión: tras verificar antes ambos números, el intercambio local usa de forma privada el número elegido, no lo difunde y no necesita internet activo.
Activación: la identidad solo se guarda cuando pasan las comprobaciones criptográficas y del enlace local aplicables.
QR es la vía local universal y funciona durante el corte. Las vías telefónicas requieren verificación previa de ambos; el directorio necesita conexión actual y Cerca no.
06

Modelo de identidad y confianza

Confianza QR local, búsqueda telefónica verificada y certificados 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 pueden establecer confianza por QR sin cuenta, verificación telefónica ni internet. El directorio en línea requiere números verificados; Cerca reutiliza números verificados antes para emparejar localmente por Bluetooth sin conexión.

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.
07

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.
08

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.

09

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.
10

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 Emisión de balizas SOS

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 Verificación del personal de respuesta

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 Chat de rescate seguro

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.
11

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.

12

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.
Capa 01
Contacto seguro: Los contactos provisionados con QR utilizan AES-256-GCM con IVs de 96 bits y etiquetas de 128 bits; los marcos de intercambio de claves endurecidos ya no transmiten material de clave en el canal.
Capa 02
Certificados de respuesta: Modo de rescate valida certificados de rol ECDSA P-256 offline contra una clave pública autorizada fijada antes de promover la comunicación segura.
Capa 03
Claves de malla de respuesta: La red Wi-Fi Aware autorizada utiliza una clave de grupo compartida; el intercambio seguro de mensajes (GATT) deriva las claves de sesión por cada par a través de ECDH P-256 efímero más HKDF-SHA-256 y cifra los mensajes con AES-256-GCM con AAD vinculado al remitente, destinatario y conversación, y las actualizaciones a la versión heredada se rechazan una vez que existe una sesión Signal.
Capa 04
Política de no repetición: Se requieren IVs generados por CSPRNG, paquetes limitados por clave, reinicio o re-establecimiento, cachés de no repetición y idempotencia de UUID para mantener la operación segura de AES-GCM.
Capa 05
Custodia de las claves: Las claves de firma de identidad del dispositivo viven en AndroidKeyStore (`dcs_attested_signing_key`), mientras que el material simétrico sensible se almacena en preferencias cifradas y la copia de seguridad está deshabilitada.
Capa 06
Límite de canal público: Los paquetes GATT públicos pueden contener un envoltorio AES-GCM para integridad y endurecimiento del formato, pero el canal sigue siendo tráfico de coordinación pública no confidencial.
Capa 07
Envoltorio de mensaje en Internet: La ruta preferida para los mensajes en Internet es el protocolo Signal a través de libsignal (Double Ratchet + PQXDH post-cuántico); el envoltorio de compatibilidad utiliza ECDH P-256 + HKDF-SHA-256 + AES-256-GCM con AAD vinculado al remitente, destinatario y conversación, y las actualizaciones a la versión heredada se rechazan una vez que existe una sesión Signal.
Capa 08
Medios y TURN: Las llamadas WebRTC utilizan medios DTLS-SRTP cifrados con señalización de llamada dentro de envoltorios de comunicación entre pares; TURN solo retransmite paquetes cifrados, y las credenciales se generan en el servidor con vidas cortas.
Capa 09
Modelo de amenazas: El diseño asume la escucha pasiva por RF más el reenvío activo, suplantación, interferencia, inundación de dispositivos y la interrupción del plano de control en la nube. En la ruta a Internet, los servidores e infraestructura de retransmisión se tratan como no confiables para el contenido: el texto sin formato nunca llega a un servidor, mientras que los metadatos de entrega permanecen visibles.
Capa 010
Exclusiones explícitas: La compensación completa del sistema operativo, la coerción del usuario y el bloqueo de RF a escala nacional quedan fuera del alcance, por lo que las afirmaciones de implementación no deben implicar protección en esas situaciones.
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.
13

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.

Retención y Anonimización

La persistencia de los mensajes utiliza registros basados en UUID, el historial de llamadas se trunca a ventanas limitadas, las claves sensibles permanecen en almacenamiento local cifrado y los registros de piloto deben pseudonimizar los ID de dispositivos y cuantificar la ubicación.

Control de Propiedad

Las autoridades necesitan propietarios explícitos para la emisión de certificados, el ritmo de bloqueo, la rotación de claves, la revocación de emergencia y los artefactos de evidencia utilizados en las revisiones de Go o No-Go.
La postura de anuncio de confianza en Public GATT es un contrato de gobernanza más que una garantía de producto cerrado; la evidencia de degradación y la cobertura del analizador aún son elementos de revisión abiertos.
14

Plano de Confianza Asistido por la Nube

Fuera de la ruta de emergencia de proximidad; solo sobres cifrados en la ruta en línea
Crisis Connect puede funcionar completamente sin conexión para la comunicación de contacto a contacto de proximidad. Los servicios en la nube realizan dos tareas: el establecimiento de confianza con el soporte de telemetría operativa, y la entrega de sobres cifrados para el envío de mensajes en Internet. En ningún momento los servidores pueden abrir contenido de extremo a extremo, y la ruta de emergencia de proximidad sigue funcionando sin la nube.
Identidad e emisión
Las autoridades pueden emitir certificados de rol de respuesta, rotar claves e integrar el flujo de trabajo de confianza con IAM institucional o un IdP autoalojado como Keycloak.
Soporte para verificación sin conexión
Los dispositivos almacenan anclas de confianza y paquetes de políticas localmente para que la verificación de respuesta pueda continuar sin conectividad en vivo; los instantáneas de bloqueo son una extensión de implementación para ventanas de conectividad.
Telemetría de Crisis Link
Los respondientes autorizados pueden hacer cola y sincronizar posteriormente instantáneas de telemetría de rescate cuando se restablece Internet, pero este canal no transporta cargas de chat de emergencia.
Entrega de sobres cifrados
Para el envío de mensajes en Internet, la parte posterior solo almacena sobres cifrados y metadatos de enrutamiento para que los mensajes puedan llegar a destinatarios sin conexión; las copias del servidor se eliminan una vez que se confirma la entrega, y los sobres no entregados se eliminan después de un TTL limitado.
División del plano de confianza: El contenido de emergencia de proximidad permanece en BLE, RFCOMM, Wi-Fi Aware o el canal público GATT opcional;
mientras que los sistemas en la nube manejan el ciclo de vida del certificado, la distribución de anclas de confianza, la sincronización de telemetría y la entrega de sobres cifrados para mensajes en Internet.
Los despliegues de producción deben mantener las claves fuera del código fuente y detrás de controles como HSM, KMS o Secret Manager.
15

Puertas de evidencia y aceptación

¿Qué debe medirse antes de la implementación general?
Las afirmaciones arquitectónicas aquí deben evaluarse en función de las pruebas del campo, y no solo en función de la intención del protocolo. La aprobación del piloto debe basarse en los datos de escenarios, y no en la intención del diseño.
Éxito en la entrega de mensajes: Al menos el 95% dentro de 30 segundos en escenarios interiores o urbanos, y el 85% en condiciones similares a escombros.
Latencia de texto: La latencia de extremo a extremo del mensaje P95 debe permanecer por debajo de los 5 segundos en las envoltorias operativas planificadas.
Envoltorio de voz: La latencia promedio de un solo sentido debe estar por debajo de los 150 ms con una pérdida de paquetes sostenida por debajo del 3% durante las llamadas activas.
Impacto en la energía: El descubrimiento y el transporte o la voz activos deben permanecer dentro de los límites definidos por la misión; la evidencia actual de Pixel 7a sobre el modo de espera es complementaria, no un cierre definitivo.
Flujo de trabajo del socorrista: SOS, prueba de rol, intercambio seguro de mensajes y activación de malla autorizada deben pasar el 100% de los escenarios de validación escritos.
Contención del abuso en canales públicos: Los paquetes públicos malformados o fuera de ventana deben descartarse antes de la retransmisión al >=99%, y las declaraciones no verificadas de socorristas nunca deben aparecer como alertas confiables.

Secuencia recomendada para el piloto

01
Piloto de respuesta cerrado: Comience con una flota de dispositivos capacitados y valide la emisión de credenciales, el modo de rescate, el comportamiento del servicio en segundo plano y la activación de malla controlada por roles.
02
Matriz de escenarios: Realice simulaciones interiores, urbanas, abiertas y similares a escombros con contenedores fijos de distancia, contenedores RSSI, notas sobre el manejo del reloj y trazas explícitas de continuidad o pérdida de voz.
03
Revisión de gobierno: Congelar los parámetros del canal público, documentar los procedimientos de revocación y activación, mapear las afirmaciones a artefactos de evidencia, y solo entonces considerar la implementación generalizada gradual.

Situación actual de evidencia

A partir del 2 de junio de 2026, las versiones disponibles en la tienda son Android 1.0.4 e iOS 1.1.0. La evidencia básica de Android de marzo de 2026 permanece como evidencia complementaria sobre el modo de espera y la voz con pruebas locales que pasan, mientras que varias puertas institucionales aún permanecen en revisión o pendientes, y no cerradas por completo. La postura institucional correcta es el uso controlado del piloto, y no una implementación general sin restricciones.
16

Abriendo Brechas Técnicas

Dónde los revisores deben hacer preguntas difíciles
La implementación actual de Android es explícita sobre lo que está implementado, lo que está gobernado operacionalmente y lo que aún necesita evidencia para cerrar. Estos son los puntos críticos más importantes.

Revocación sin conexión

¿Cómo revoca el sistema la confianza del responsable cuando no hay internet disponible?
Situación Actual
La implementación actual de Android se basa en certificados de rol de corta duración, firmas offline o comprobaciones de rol o ventanas de tiempo, y en una actualización obligatoria cuando no queda ningún certificado almacenado.
¿Qué sigue abierto?
La ingestión explícita de CRL o instantánea de lista negra en el dispositivo es un objetivo de despliegue, no un camino de cumplimiento cerrado en la línea base actual.

Alcance de la Red

¿Es Wi-Fi Aware una capa de transporte general para todos los usuarios?
Situación Actual
No. La red mesh Wi-Fi Aware segura es una extensión autorizada del responsable para dispositivos Android compatibles, separada del canal público GATT opt-in y nuevamente separada de las sesiones directas de Bluetooth.
¿Qué sigue abierto?
Las instituciones aún necesitan cobertura de capacidades de dispositivo, SOPs del operador y una política clara sobre cuándo habilitar o suprimir la red mesh.

Evidencia de Energía

¿Cierran los números actuales de batería la puerta de energía?
Situación Actual
No. La comparación emparejada Pixel 7a del 15 de marzo de 2026 mostró aproximadamente 14,1 mW de sobrecarga incremental de espera en una ejecución controlada y con alimentación AC, lo cual es solo evidencia complementaria útil.
¿Qué sigue abierto?
El cierre de la puerta aún necesita comparaciones de línea base multi-dispositivo desconectadas bajo condiciones de campo nombradas.

Abuso del Canal Público

¿Son los controles contra el spam y los rumores puramente teóricos?
Situación Actual
No. El perfil del canal público declara límites estrictos para saltos, marcas de tiempo, presupuesto de inundación entrante, profundidad de cola, manejo de duplicados y tamaño de mensaje, y la lógica relacionada está parcialmente representada en pruebas locales.
¿Qué sigue abierto?
Lo que sigue abierto es evidencia a nivel de paquete y prueba de degradación de anuncios confiables vinculada al flujo de cierre declarado C-06 o T-08.

Rango y Envolvente de Voz

¿Qué envoltorio de rendimiento está realmente evidenciado hoy?
Situación Actual
El conjunto actual de evidencia incluye bandas indicativas de rango, además de pruebas complementarias de dispositivos adyacentes, dos paredes y voz ajustada por reloj, lo que fortalece las afirmaciones de viabilidad sin cerrarlas completamente.
¿Qué sigue abierto?
La aprobación de nivel de revisor aún necesita trazas multi-dispositivo con rangos binados, RF degradado, con latencia, pérdida y caída sincronizadas informadas.

Evidencia de la Capa en Línea

¿Se aplica la misma barra de evidencia a la capa en línea?
Situación Actual
Los mensajes y llamadas punto a punto por internet se basan en componentes maduros y ampliamente revisados: libsignal, WebRTC y Cloudflare TURN con credenciales de corta duración. Los formatos de envoltorio, el rechazo de degradación y la verificación del número de seguridad están definidos a nivel de código.
¿Qué sigue abierto?
La llamada grupal no está disponible en el producto actualmente: llamadas grupales basadas en MLS (RFC 9420) sobre un SFU están en desarrollo en el código y requieren evidencia verificada por el dispositivo antes de su lanzamiento. También se requiere una auditoría independiente que cubra la capa en línea.
17

Limitaciones y Notas de Seguridad

Lo que el sistema no promete
Bluetooth sigue siendo basado en proximidad; la cobertura está limitada por el entorno, los obstáculos, el hardware y las políticas de energía del SO.
El sistema admite la coordinación sectorial local, pero no garantiza el alcance a todas las víctimas bajo todas las condiciones de escombros.
Los flujos civiles predeterminados dependen de enlaces locales directos; los modos de malla requieren hardware compatible, habilitación explícita y proximidad de radio local.
La red GATT pública es opcional, está desactivada por defecto y no se recomienda como una configuración siempre activa para cada perfil de usuario.
El contenido operativo sensible debe permanecer en las rutas seguras designadas o canales de respuesta controlados por roles, en lugar de en superficies de coordinación públicas amplias.
El comportamiento de retransmisión o almacenamiento y envío sin límites permanece fuera del alcance de la línea base validada.
La evidencia de implementación institucional actual se centra en la línea de lanzamiento de Android; iOS está disponible públicamente pero aún necesita su propia evidencia de preparación para responder.
Las variaciones en el dispositivo, el SO y la gestión de batería del OEM pueden cambiar significativamente el comportamiento, por lo que los pilotos deben medir flotas en lugar de asumir que los resultados de un solo teléfono se generalizan.
El directorio telefónico en línea necesita internet y números previamente verificados para ambos. Esto no bloquea el QR sin internet; tras verificarlos, Cerca también puede emparejar localmente sin conexión.
En la vía de Internet, el contenido permanece cifrado de extremo a extremo, pero los metadatos de entrega, señalización y retransmisión (identificadores, marcas de tiempo, direcciones IP) son procesados por servidores e infraestructura TURN.
SeguridadCrisis Connect no reemplaza a los servicios de emergencia oficiales. Cuando esté disponible cualquier vía de área amplia, los usuarios aún deben intentar el número de emergencia local como 112, 911 o el equivalente nacional designado.
18

Escenarios de Implementación

Mensajería encriptada de extremo a extremo y llamadas de voz y video con seres queridos lejanos mientras el Internet esté activo
Comunicación familiar o de equipo con contactos añadidos localmente por QR antes o durante un corte, o por teléfono verificado cuando se cumplen sus requisitos
Mensajería local y compartición de ubicación sin conexión durante viajes fuera de la red o trabajo en campo remoto
Desplazamientos por terremoto o colapso de infraestructura donde las víctimas exponen señales SOS y los respondientes verifican antes de chatear de forma segura
Víctimas conectadas a Internet cuyos informes SOS se dirigen a paneles de respuesta autorizados
Chat grupal seguro solo para respondedores sobre Wi-Fi Aware en hardware Android compatible
Coordinación y anuncios generales amplios a través de la red GATT pública opt-in cuando está explícitamente habilitada
Llamadas de voz sobre enlaces Bluetooth directos cuando el RF y el envoltorio de energía lo permiten
Descarga de mapas sin conexión, herramientas locales de supervivencia o utilidad y flujos de trabajo de preparación para emergencias en clientes móviles compatibles
Sincronización opcional de telemetría de Crisis Link con sistemas de respaldo institucionales después de la recuperación de Internet validada

Resultado Arquitectónico

La arquitectura móvil de Crisis Connect es intencionalmente conservadora: mientras el Internet esté activo, el contenido viaja en sobres encriptados de extremo a extremo y los servidores permanecen ciegos ante él; cuando fallan las redes, Bluetooth directo es la vía predeterminada del incidente, la confianza se establece fuera de línea, los flujos seguros para respondedores están controlados por certificados y la nube permanece fuera del camino de emergencia de proximidad. El sistema es adecuado para pilotos basados en evidencia institucionales alrededor de la línea de lanzamiento de Android, mientras que una implementación más amplia para responder debe esperar a la validación en el campo contra las puertas de aceptación declaradas.
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.0Incidencias
Ver repositorio
Arquitectura técnica móvil | Crisis Connect