Centro de confianza
Respaldamos nuestras afirmaciones de seguridad con recursos verificables, no con insignias. Esta página reúne nuestras políticas, el estado del sistema en vivo, la arquitectura técnica y los proveedores con quienes trabajamos, y declara claramente lo que aún no tenemos.
Recursos de verificación
Para comprobar una afirmación, no leas texto de marketing: consulta las fuentes de abajo.
Divulgación de vulnerabilidades
Alcance, principios de puerto seguro y proceso privado de reporte.
Estado del sistema en vivo
Estado actual del servicio e historial de disponibilidad de 90 días.
Arquitectura técnica
Detalles de cifrado, modelo de amenazas y límites conocidos tanto de la conexión Bluetooth sin conexión como de la capa de internet.
Política de privacidad
Qué datos se almacenan dónde, cuándo se comparten y cómo se eliminan.
security.txt
Cumplimiento con RFC 9116, registro de contacto de seguridad legible por máquina.
Código de fuente abierta
El cliente móvil está en GitHub bajo AGPL-3.0; las afirmaciones se pueden auditar directamente desde el código.
Contactar al equipo de seguridad
Canal directo para hallazgos de seguridad: security@crisisconnect.network
Nuestras prácticas de seguridad
- La mensajería está cifrada de extremo a extremo en ambas conexiones compatibles: los mensajes por internet viajan como envoltorios cifrados que el servidor no puede leer, y los mensajes Bluetooth van directamente de dispositivo a dispositivo.
- En la mensajería civil cercana habitual, el historial de mensajes no se replica en un servidor central; los datos permanecen principalmente en tu dispositivo.
- El código fuente del cliente móvil es público bajo la licencia AGPL-3.0; las afirmaciones de cifrado se pueden revisar de forma independiente.
- Un registro security.txt conforme a RFC 9116 y una política publicada de divulgación de vulnerabilidades dan a los investigadores una vía de reporte definida.
- El estado del sistema se publica en una página de estado en vivo alimentada por extremos públicos.
- No hay anuncios, modelo de ingresos basado en seguimiento ni venta de datos.
Cifrado y protocolos
Los protocolos en uso, no una etiqueta. El modelo de amenazas completo, los límites conocidos y las decisiones de diseño están documentados en la página de arquitectura técnica.
Mensajería en Internet (mensajes, notas de voz, archivos adjuntos)
Protocolo Signal (libsignal): Doble Ratchet con acuerdo de claves PQXDH post-cuántico, que proporciona confidencialidad. Para la compatibilidad con clientes más antiguos, se utiliza un sobre ECIES autenticado (ECDH P-256 + HKDF-SHA-256 + AES-256-GCM); esta ruta no proporciona confidencialidad y los intentos de degradación se rechazan una vez que se ha establecido una sesión de Signal.
Llamadas de voz y video (uno a uno)
WebRTC DTLS-SRTP. Para las llamadas, la señalización nunca cruza el servidor en texto plano: viaja dentro de envoltorios de mensajes cifrados de extremo a extremo, y TURN no puede descifrar los medios. Las llamadas en canales autorizados utilizan una ruta separada cuyo funcionamiento pasa por la infraestructura del panel con control de membresía.
Cercano (Bluetooth)
AES-256-GCM (IV de 96 bits, etiqueta de autenticación de 128 bits) para contactos emparejados mediante QR. Los flujos autorizados utilizan claves de sesión efímeras ECDH P-256 + HKDF-SHA-256 y certificados de rol ECDSA P-256 validados fuera de línea.
Identidad y verificación
La clave de identidad P-256 heredada se almacena en AndroidKeyStore con respaldo de hardware en dispositivos compatibles. La clave de identidad de Signal funciona en software para las operaciones de ratchet y se almacena cifrada en reposo bajo una clave de Keystore: esta es una decisión de diseño deliberada para la confidencialidad. Los contactos pueden verificarse comparando números de seguridad de 60 dígitos.
Qué no está cifrado de extremo a extremo
El informe SOS a los paneles de respuesta autorizados: intencionalmente legible para que los equipos puedan actuar sobre él, y los datos de entrega/señalización (identificadores, marcas de tiempo, direcciones IP). No lo ocultamos; los detalles se encuentran en la arquitectura técnica y la política de privacidad.
Revise el modelo de amenazas completo en la arquitectura técnica →
Proveedores y alojamiento
Colaboramos con los siguientes proveedores de servicios de terceros (subprocesadores) para ofrecer el servicio. El contenido cifrado de extremo a extremo no puede ser leído por estos proveedores; esta página se actualiza cuando cambia la lista.
| Proveedor | Propósito | Ubicación |
|---|---|---|
| Google Firebase (Google LLC) | Autenticación, base de datos, almacenamiento, funciones en la nube, notificaciones, alojamiento web, análisis y informes de fallos | EE. UU. (us-central1) |
| Cloudflare, Inc. | Relé TURN para llamadas por internet | Red global de anycast (con sede en EE. UU.) |
| MapTiler AG | Entrega de mosaicos de mapa | Suiza (CDN global) |
| CARTO | Mosaicos de mapa base para los mapas del panel web | CDN global |
| Google Play · Apple App Store | Distribución y actualizaciones de aplicaciones | Global |
Lo que aún no tenemos
No afirmaremos lo que no tenemos. Hasta la fecha:
- Aún no hemos publicado un informe independiente de auditoría de seguridad o prueba de penetración; es la principal inversión en confianza en nuestro plan de desarrollo.
- No poseemos certificaciones ISO 27001 ni SOC 2.
- No ejecutamos un programa de recompensas por vulnerabilidades pagado; el proceso de divulgación responsable está definido en la página de seguridad.
Esta página no hace ninguna nueva afirmación; solo recopila los recursos existentes y verificables en un solo lugar.