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
RFC 9116-compliant, machine-readable security contact record.
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.
Encryption and protocols
The protocols in use, not a label. The full threat model, known limits, and design decisions are documented on the technical architecture page.
Internet messaging (messages, voice notes, attachments)
Signal protocol (libsignal): Double Ratchet with post-quantum PQXDH key agreement, providing forward secrecy. For compatibility with older clients, an authenticated ECIES envelope (ECDH P-256 + HKDF-SHA-256 + AES-256-GCM) is used; that path does not provide forward secrecy, and downgrade attempts are rejected once a Signal session is established.
Voice and video calls (one-to-one)
WebRTC DTLS-SRTP. For one-to-one calls, signaling never crosses the server in plaintext — it travels inside end-to-end encrypted message envelopes — and the TURN relay cannot decrypt media. Calls on authorized agency channels use a separate path whose signaling passes through membership-gated panel infrastructure.
Nearby (Bluetooth) messaging
AES-256-GCM (96-bit IV, 128-bit auth tag) for QR-paired contacts. Authorized responder flows use ephemeral ECDH P-256 + HKDF-SHA-256 session keys and ECDSA P-256 role certificates validated offline.
Identity and verification
The legacy P-256 identity key is held in hardware-backed AndroidKeyStore on supported devices. The Signal identity key runs in software for ratchet operations and is stored encrypted at rest under a Keystore key — a deliberate design trade-off for forward secrecy. Contacts can be verified by comparing 60-digit safety numbers.
What is not end-to-end encrypted
The SOS report to authorized response panels — deliberately readable so teams can act on it — and delivery/signaling metadata (identifiers, timestamps, IPs). We do not hide this; the details live in the technical architecture and the privacy policy.
Review the full threat model in the technical architecture →
Service providers and hosting
We work with the following third-party service providers (subprocessors) to deliver the service. End-to-end encrypted content cannot be read by these providers; this page is updated when the list changes.
| Provider | Purpose | Location |
|---|---|---|
| Google Firebase (Google LLC) | Authentication, database, storage, cloud functions, notifications, website hosting, analytics, and crash reporting | USA (us-central1) |
| Cloudflare, Inc. | TURN media relay for internet calls | Global anycast network (US-based) |
| MapTiler AG | Map tile delivery | Switzerland (global CDN) |
| CARTO | Base map tiles for the web dashboard maps | Global CDN |
| Google Play · Apple App Store | App distribution and updates | Global |
What we don't have yet
We won't claim what we don't have. As of today:
- We have not yet published an independent security audit or penetration-test report; it is the top trust investment on our roadmap.
- We hold no ISO 27001 or SOC 2 certification.
- We do not run a paid bug bounty program; the responsible disclosure process is defined on the security page.
This page makes no new claims; it only gathers existing, verifiable resources in one place.