Centre de confiance
Nous étayons nos affirmations de sécurité avec des ressources vérifiables, et non des badges. Cette page rassemble nos politiques, l'état du système en direct, l'architecture technique et les prestataires de services avec lesquels nous travaillons — et indique clairement ce que nous n'avons pas encore.
Ressources de vérification
Pour vérifier une affirmation, ne lisez pas le contenu marketing — consultez les sources ci-dessous.
Divulgation des vulnérabilités
Portée, principes de protection et le processus de signalement privé.
État du système en direct
État actuel du service et historique des 90 derniers jours d'uptime.
Architecture technique
Détails de chiffrement, modèle de menace et limites connues des deux chemins Bluetooth hors ligne et de la couche Internet.
Politique de confidentialité
Quelles données existent où, quand elles sont partagées et comment elles sont supprimées.
security.txt
Enregistrement de contact sécurisé conforme à RFC 9116, lisible par machine.
Code Open Source
Le client mobile est sur GitHub sous AGPL-3.0 ; les affirmations peuvent être vérifiées à partir du code lui-même.
Contactez l'équipe de sécurité
Canal direct pour les signalements de sécurité : security@crisisconnect.network
Nos pratiques de sécurité
- La communication est chiffrée de bout en bout sur les deux chemins pris en charge : les messages Internet voyagent sous forme d'enveloppes chiffrées que le serveur ne peut pas lire, et les messages Bluetooth sont transmis directement entre les appareils.
- Dans la communication locale normale, l'historique des messages n'est pas reflété sur un serveur central ; les données restent principalement sur votre appareil.
- Le code source du client mobile est disponible sous la licence AGPL-3.0 ; les affirmations de chiffrement peuvent être examinées indépendamment.
- Un enregistrement security.txt selon RFC 9116 et une politique de divulgation des vulnérabilités publiée donnent aux chercheurs un chemin de signalement défini.
- L'état du système est publié sur une page d'état en direct alimentée par des points de terminaison publics.
- Il n'y a pas de publicités, aucun modèle de revenus basé sur le suivi ni la vente de données.
Chiffrement et protocoles
Les protocoles utilisés, et non un label. Le modèle de menace complet, les limites connues et les décisions de conception sont documentés sur la page d'architecture technique.
Messagerie Internet (messages, notes vocales, pièces jointes)
Protocole Signal (libsignal) : Double Ratchet avec l'accord de clés PQXDH post-quantique, offrant la confidentialité des données. Pour assurer la compatibilité avec les anciens clients, une enveloppe ECIES authentifiée (ECDH P-256 + HKDF-SHA-256 + AES-256-GCM) est utilisée ; ce chemin ne garantit pas la confidentialité des données et les tentatives de dégradation sont rejetées une fois qu'une session Signal est établie.
Appels vocaux et vidéo (un à un)
WebRTC DTLS-SRTP. Pour les appels un à un, le signalement ne traverse jamais le serveur en texte clair — il se déplace dans des enveloppes de messages chiffrées bout aux bouts — et le relais TURN ne peut pas décrypter les médias. Les appels sur les canaux autorisés utilisent un chemin séparé dont le signalement passe par une infrastructure de panneaux contrôlée par l'adhésion.
Messages à courte portée (Bluetooth)
AES-256-GCM (IV de 96 bits, balise d'authentification de 128 bits) pour les contacts appariés via QR. Les flux autorisés utilisent des clés de session éphémères ECDH P-256 + HKDF-SHA-256 et des certificats de rôle ECDSA P-256 validés hors ligne.
Identité et vérification
La clé d'identité P-256 héritée est stockée dans AndroidKeyStore avec protection matérielle sur les appareils pris en charge. La clé d'identité Signal fonctionne en logiciel pour les opérations de ratcheting et est stockée chiffrée au repos sous une clé Keystore — un compromis de conception délibéré pour la confidentialité. Les contacts peuvent être vérifiés en comparant des numéros de sécurité de 60 chiffres.
Ce qui n'est pas chiffré bout aux bouts
Le rapport SOS vers les panneaux de réponse autorisés — intentionnellement lisible afin que les équipes puissent agir dessus — et les métadonnées de livraison/signalement (identificateurs, horodatages, adresses IP). Nous ne cachons pas cela ; les détails se trouvent dans l'architecture technique et la politique de confidentialité.
Consultez le modèle de menace complet dans l'architecture technique →
Prestataires et hébergement
Nous travaillons avec les fournisseurs de services tiers suivants (sous-traitants) pour fournir le service. Le contenu chiffré bout aux bouts ne peut pas être lu par ces fournisseurs ; cette page est mise à jour lorsque la liste change.
| Fournisseur | Objectif | Emplacement |
|---|---|---|
| Google Firebase (Google LLC) | Authentification, base de données, stockage, fonctions cloud, notifications, hébergement web, analyse et rapports de crash | USA (us-central1) |
| Cloudflare, Inc. | Relais TURN pour les appels internet | Réseau mondial anycast (basé aux États-Unis) |
| MapTiler AG | Livraison de tuiles cartographiques | Suisse (CDN mondiale) |
| CARTO | Tuiles de base pour les cartes du tableau de bord web | CDN mondial |
| Google Play · App Store Apple | Distribution et mises à jour des applications | Global |
Ce que nous n'avons pas encore
Nous ne revendiquons pas ce que nous n'avons pas. À ce jour :
- Nous n'avons pas encore publié de rapport d'audit de sécurité ou de test de pénétration indépendant ; c'est l'investissement en confiance prioritaire sur notre feuille de route.
- Nous ne détenons aucune certification ISO 27001 ou SOC 2.
- Nous n'exécutons pas un programme de récompenses pour les bogues ; le processus de divulgation responsable est défini sur la page de sécurité.
Cette page ne fait aucune nouvelle déclaration ; elle rassemble uniquement des ressources existantes et vérifiables en un seul endroit.