Architecture technique mobile

Contenu

Cette page explique comment l'application mobile Crisis Connect établit la confiance, transmet des messages et des appels chiffrés bout à bout lorsque l'internet est disponible, continue de fonctionner via Bluetooth direct lorsque les réseaux tombent en panne, et dirige les intervenants vers des chemins sécurisés.

Code source ouvertemirhan-duman/Crisis-Connect

BLE + RFCOMM

Chemin d'incident par défaut

Wi-Fi Aware + GATT

Couches d'extension contrôlées

AES-GCM + ECDH

Profil de confiance sécurisé

Android 1.0.4 · iOS 1.1.0

Versions du magasin public

Crisis Connect est un système de communication d'urgence basé sur le mode hors ligne. Bien que l'internet soit disponible, il offre des messages chiffrés de bout en bout, ainsi que des appels vocaux et vidéo; lorsque l'infrastructure internet et cellulaire tombe en panne ou devient saturée, la même application continue de fonctionner via les radios à courte portée des téléphones voisins. L'architecture Android de base maintient le chemin d'incident sur Bluetooth local, construit la couche en ligne sur des enveloppes chiffrées de bout en bout, ajoute des couches d'extension uniquement lorsque cela est autorisé par la politique, et traite le cloud comme un plan de livraison et de confiance qui ne voit jamais de contenu non chiffré

Résumé du système

Chemin de message hors ligne: Les appareils voisins se détectent via Bluetooth, puis échangent des charges utiles sécurisées sur un transport point à point local sans compter sur l'internet

Couche en ligne: Lorsque l'internet est disponible, les messages voyagent sous forme d'enveloppes chiffrées de bout en bout, les appels entre deux personnes fonctionnent via WebRTC, et les rapports SOS atteignent les panneaux de réponse autorisés

Confiance explicite: Les contacts connus sont provisionnés hors ligne avec des QR, tandis que le mode d'urgence ne met en œuvre que les répondants vérifiés dans un chat bidirectionnel sécurisé

Modèle d'expansion contrôlé: Un réseau d'interopérateurs autorisés et une coordination publique étendue existent, mais ils sont séparés, contrôlés et intentionnellement ne sont pas considérés comme le chemin par défaut

Le cloud n'a pas accès au contenu: Les services backend gèrent l'émission de certificats, la distribution des ancres de confiance, la synchronisation des données télémétriques et la livraison des enveloppes chiffrées; à aucun moment ils ne peuvent lire du contenu chiffré de bout en bout

Mode de fonctionnement

Hypothèses, portée et limites des capacités actuelles

Crisis Connect est conçu pour être utile dans les deux situations : la messagerie et les appels chiffrés de bout en bout lorsque l'internet est disponible, ainsi que la coordination locale qui continue de fonctionner lorsque les réseaux à grande échelle tombent en panne. Le poids des décisions architecturales repose sur ce second moment : les téléphones proches fonctionnent toujours, et les opérateurs ont besoin d'une couche de coordination locale contrôlée — et non illimitée.

Hypothèse de première priorité : L'application est conçue pour les situations d'urgence où l'internet et le service cellulaire sont indisponibles ou surchargés, mais que les smartphones proches ont encore de la batterie et des radios utilisables.

Client pré-installé : La participation civile suppose qu'une version compatible de l'application est déjà installée avant la perte de connectivité, ou peut toujours être distribuée via un flux local approuvé, alors que l'installation reste possible.

Enveloppe de radio locale : La communication est basée sur la proximité. Bluetooth est le chemin par défaut, tandis que Wi-Fi Aware est réservé aux sessions de réseau d'intervenants autorisés sur les appareils compatibles.

Ensemble de capacités actuel : Les mises à jour de texte et de localisation sécurisées, la voix point à point optionnelle, le mode de sauvetage, la messagerie par réseau d'intervenants autorisés, la messagerie internet chiffrée de bout en bout, les appels vocaux et vidéo WebRTC, ainsi que la synchronisation de télémétrie Crisis Link optionnelle sont inclus dans l'ensemble actuel.

Posture de confinement des rumeurs : Les messages civils par défaut sont envoyés aux contacts connus, SOS est ouvert pour la découverte mais vérifié pour une conversation sécurisée, et la coordination publique étendue reste facultative et limitée.

Principes de conception

Local avant le cloud

Le système est conçu pour fonctionner entièrement sans connexion Internet. La couche en ligne ajoute à la voie d'urgence hors ligne plutôt que de la remplacer ; les communications d'urgence locales restent sur les chemins radio entre les appareils.

Directement Avant le Réseau

Le comportement par défaut est le Bluetooth point-à-point. Les modes à portée plus importante sont ajoutés uniquement sous le contrôle explicite du rôle, des capacités et de l'opérateur.

Durée d'exécution limitée

La conception suppose une alimentation limitée et des conditions de terrain instables, de sorte que les limites de file d'attente, les limites de tentatives, les services en premier plan et la portée vocale unique sont intentionnelles.

La confiance est explicite

Les contacts ne deviennent opérationnels qu'après un démarrage par QR plus une vérification cryptographique de l'activité, et les flux sécurisés pour les répondants nécessitent une vérification basée sur les certificats.

Pile radio principale

Découverte et contrôle BLE au-dessus du transport de paquets RFCOMM

Le chemin d'incident par défaut combine deux couches Bluetooth différentes avec des tâches : le BLE gère la découverte légère, le signalement de services et les échanges de contrôle de sauvetage, tandis que le Bluetooth Classic RFCOMM transporte le trafic de paquets point-à-point plus lourd pour le texte, la localisation, les médias et la voix optionnelle.

Couche de Découverte et de Contrôle

BLE (GAP/GATT)

Signalisation de présence, échanges de contrôle courts, annonce Rescue Mode et découverte basse consommation

Découverte et diffusion de présence basse consommation pour les appareils à proximité

Échanges d'authentification et de contrôle pour préparer des sessions sécurisées avant le transfert de données importantes

Comportement du balise SOS et signaux au niveau du service pour les flux Rescue Mode

Couche de Transport de Données

Bluetooth Classic RFCOMM/SPP

Transport fiable point à point pour le texte, la localisation, les médias et la voix optionnelle

Sessions directes à haut débit entre appareils proches une fois la découverte réussie

Transfert sécurisé de messages, d'images, de fichiers et de voix sur un protocole défini par l'application

La compatibilité peut inclure des options de socket sécurisées ou non sécurisées, de sorte que la sécurité des messages est appliquée au-dessus du socket

Portée d'opération : La plage indicative est d'environ 50 à 150 m en ligne de visée dégagée, 30 à 80 m en milieu urbain ou avec des obstacles, 10 à 30 m en intérieur et 5 à 20 m dans un environnement avec des débris. Étant donné que la portée et le comportement du socket varient selon les appareils, la confidentialité est ancrée au niveau de l'application plutôt qu'elle ne soit supposée à partir du mode RFCOMM seul.

Extensions Contrôlées

Comment le système s'étend au-delà du Bluetooth direct

Le système étend délibérément la portée dans des couches séparées. Un réseau de réponses sécurisé et une coordination publique étendue sont tous deux des fonctionnalités réelles de base, mais elles existent sous des règles de confiance, d'activation et de gouvernance différentes.

Réseau de Réponses Autorisé

La version Android comprend une extension optionnelle de chat de groupe sécurisé sur Wi-Fi Aware pour les rôles d'administrateur et d'équipe sur le terrain autorisés. Elle reste désactivée à moins que les vérifications du certificat de rôle et des capacités de la plateforme ne réussissent.

Canal GATT Public Opt-in

Un réseau GATT public peut être activé à partir des paramètres avancés pour une communication générale et des annonces à courte portée. Il est intentionnellement large et doit être considéré comme du trafic de coordination non confidentiel.

Activation explicite

Le réseau de secours nécessite un rôle local valide et du matériel pris en charge. Le réseau public reste éteint à moins que l'utilisateur n'active explicitement le mode réseau public.

Contrôles d'abus limités

Le profil de canal public déclaré fixe la hauteur maximale de saut à 4, applique une fenêtre de timestamp, un budget de flux par source, des limites de taille de message, une suppression des doublons et une file d'attente de relais limitée.

Démarrage de confiance

Établir la confiance avant ou pendant une coupure

Les contacts peuvent établir localement la confiance par QR pendant une coupure. Préparer réduit la pression sans être un prérequis du protocole. Les numéros vérifiés ajoutent l’annuaire en ligne et l’appairage local À proximité après vérification préalable.

QR sans Internet : deux téléphones proches échangent session et matériel cryptographique par QR, puis vérifient et enregistrent le contact par Bluetooth ; aucun compte, SMS, SIM ni serveur.

Contacts en ligne : les deux numéros sont vérifiés en ligne, puis l’annuaire ajoute l’utilisateur détectable sans QR.

À proximité hors ligne : après vérification préalable, l’échange local utilise en privé le numéro choisi, ne le diffuse pas et n’exige pas Internet actif.

Activation : l’identité n’est enregistrée qu’après réussite des contrôles cryptographiques et du lien local applicables.

Le QR est la voie locale universelle et reste disponible pendant une coupure. Les voies téléphoniques exigent la vérification préalable des deux personnes ; l’annuaire nécessite Internet, À proximité non.

Modèle d'identité et de confiance

Confiance QR locale, découverte téléphonique vérifiée et certificats d’intervention

Crisis Connect utilise des chemins de confiance différents pour différentes relations. Les contacts connus et les intervenants vérifiés n'utilisent pas le même modèle de démarrage, d'autorisation ou de récupération.

Chemin sécurisé pour les contacts connus

Les contacts peuvent établir la confiance par QR sans compte, vérification téléphonique ni Internet. L’annuaire en ligne exige des numéros vérifiés ; À proximité réutilise les numéros vérifiés pour un appairage Bluetooth local hors ligne.

Authentification de l'intervenant

Les interactions de secours valident les certificats de rôle ECDSA hors ligne contre une clé publique d'autorité ancrée, vérifiant la signature, l'UID du propriétaire, la portée du rôle et la fenêtre de validité avant de promouvoir en toute sécurité.

Éligibilité au réseau

Les sessions Wi-Fi Aware à mesh nécessitent à la fois un certificat de rôle valide et le support de la plateforme. Les tentatives d'association non autorisées sont rejetées avant l'activation du chat de mesh.

Cycle de vie des clés et des certificats

Les certificats de rôle ont une durée de vie courte dans la configuration de base (durée TTL actuelle : 72 heures). Les clés d'identité locales résident dans AndroidKeyStore, les autres données sensibles sont protégées dans un stockage chiffré, et l'absence ou l'expiration du profil de réponse force un rafraîchissement ou une réaffectation.

Cycle de vie des messages

De la découverte à la progression ACK

Cette section couvre le cycle de vie des chemins sécurisés de proximité (Bluetooth) ; les messages sur Internet sont couverts dans la section Couche en ligne. Sur le chemin de proximité, les données sont chiffrées sur l'appareil de l'expéditeur et déchiffrées sur l'appareil du destinataire. Si un pair est hors ligne ou temporairement hors portée, la livraison attend une liaison locale plutôt que de s'échapper vers un relais dans le cloud.

01La découverte BLE et les signaux de contrôle indiquent la disponibilité du pair et préparent la session locale.

02L'établissement du lien RFCOMM ouvre le transport à débit plus élevé utilisé pour le texte, l'emplacement, les médias et la voix optionnelle.

03L'activation des contacts connus utilise les cadres de réponse challenge-réponse `HSK_REQ` et `HSK_ACK` ; la session n'est active que lorsque la validation limitée dans le temps réussit.

04Les cadres `SEC_MSG` transportent des charges utiles chiffrées par l'expéditeur, identifiées par UUID, IV et texte chiffré ; le destinataire vérifie AEAD avant la persistance locale.

05La progression ACK avance les messages en attente à travers les états livrés et lus sans dupliquer les enregistrements persistés par UUID.

06Les transferts de voix, d'images et de fichiers passent aux familles d'enregistrements JSON typées avec des blocs, des fenêtres de nouvelles tentatives et des vérifications d'intégrité à la fin de la transmission.

07Les règles de réutilisation, de doublon et d'idempotence reposent sur l'unicité de l'UUID, les caches limités et le comportement de rejet du côté du destinataire plutôt que de supposer un lien parfait.

08Le canal GATT général est logiquement séparé de ces chemins sécurisés désignés et ne doit pas être considéré comme un transport confidentiel.

Posture du protocole: Dans la configuration Android de base, le trafic RFCOMM utilise des enregistrements UTF-8 délimités par des sauts avec à la fois des lignes de contrôle délimitées par des pipes et des familles de messages JSON typés pour les flux plus riches ou de contrôle d'appel.

Chemin de voix

Opus sur Bluetooth point à point

La voix est optionnelle et conservatrice. Elle fonctionne comme un flux en temps réel pair à pair sur le transport point à point, est chiffrée avant la transmission et doit être jugée par rapport à la batterie et à la stabilité RF.

Profil de voix

CodecOpus

Taux d'échantillonnage16 kHz

Cadre / Paquet10 ms x 5 = ~50 ms

Cibles de débit20 kbps WB / 16 kbps NB

Tampon de jitter20-50 ms (30 ms par défaut)

Objectif de tamponnage~70-100 ms

Séquence d'appel

01L'audio est capturé, encodé avec Opus, chiffré et envoyé via le lien RFCOMM actif plutôt qu'à travers un autre réseau internet.

02La portée de base suppose une seule session vocale active par lien point-à-point; plusieurs appels vocaux simultanés sur un seul appareil ne sont pas pris en compte.

03Une boucle de contrôle d'une seconde peut basculer entre les profils large et étroit, avec un délai de 6 secondes et des confirmations de configuration négociées avant que les changements de profil n'entrent en vigueur.

04Les données pilotes doivent signaler le temps de mise en place de l'appel, la perte, la distribution de la latence et l'impact sur la batterie incrémental dans des conditions scéniques nommées plutôt que seulement une continuité anecdotique.

Politique adaptative

L'implémentation passe du WB au NB lorsque les temps d'écriture augmentent, que les sous-débits réapparaissent ou que la profondeur de jitter devient instable; elle revient à passer au WB uniquement après une récupération durable. Il s'agit d'une politique de continuité limitée, et non d'une garantie QoS universelle.

Couche en ligne

Messagerie et appels chiffrés bout en bout pendant que le réseau internet est actif

Avec une connexion Internet, Crisis Connect fonctionne comme un messager que vous pouvez utiliser au quotidien : chat chiffré de bout en bout, appels vocaux et vidéo, ainsi qu'un signalement SOS qui atteint les panneaux de réponse autorisés. Cette couche ne remplace pas l'architecture hors ligne ; elle s'y ajoute selon le même principe : le contenu est chiffré sur l'appareil, et les serveurs ne gèrent que des enveloppes chiffrées ainsi que les métadonnées nécessaires à la livraison.

Messagerie chiffrée de bout en bout

Les messages, les notes vocales et les pièces jointes quittent l'appareil uniquement sous forme d'enveloppes chiffrées de bout en bout ; les serveurs ne peuvent pas les ouvrir. Lorsque les deux parties le supportent, la session fonctionne selon le protocole Signal via libsignal (Double Ratchet plus l'accord de clé PQXDH post-quantique) avec une confidentialité avant tout. Une enveloppe ECIES chiffrée authentifiée (ECDH P-256 + HKDF-SHA-256 + AES-256-GCM) couvre les anciens clients ; elle ne fournit pas de confidentialité avant tout, et une fois qu'une session Signal existe, les tentatives de dégradation vers ce format sont rejetées. La clé d'identité P-256 héritée est stockée dans AndroidKeyStore sur le matériel sur les appareils pris en charge ; la clé d'identité Signal est stockée chiffrée au repos sous une clé Keystore. Les contacts peuvent être vérifiés avec un numéro de sécurité de 60 chiffres.

Appels vocaux et vidéo WebRTC

Les appels entre deux personnes fonctionnent selon le protocole WebRTC : audio Opus, vidéo caméra jusqu'à 720p et partage d'écran. Les médias sont chiffrés avec DTLS-SRTP, et les signaux SDP et ICE ne traversent jamais le serveur en texte clair — ils voyagent à l'intérieur d'enveloppes de messages chiffrées de bout en bout. Lorsqu'une connexion directe n'est pas possible, les médias chiffrés sont acheminés via Cloudflare TURN relay ; les identifiants TURN sont générés côté serveur avec des durées courtes, et si le service est inaccessible, l'appel revient à la connectivité directe via STUN.

SOS sur Internet

Avec une connexion Internet disponible, SOS se déroule selon deux chemins séparés. Le rapport envoyé aux panneaux de réponse autorisés contient l'emplacement, la précision, le niveau de batterie et le pays, et est délibérément non chiffré afin que les panneaux puissent le lire. Les alertes SOS et les mises à jour de localisation envoyées à vos contacts d'urgence voyagent sous forme d'enveloppes chiffrées de bout en bout comme tout autre message. Sans connectivité, le rapport est mis en file d'attente et envoyé lorsque l'Internet revient ; le balise BLE SOS continue de fonctionner comme le chemin hors ligne principal dans tous les cas.

Le choix du transport est automatique : si une connexion Bluetooth avec la personne est établie, le message utilise le chemin local ; sinon, Internet est utilisé ; si ni l'un ni l'autre n'est disponible, il attend dans la file d'attente et la même conversation se poursuit. La limite honnête : le contenu reste chiffré de bout en bout, mais les métadonnées de livraison et de signalisation (identifiants de l'expéditeur et du destinataire, horodatages, adresses IP) sont traitées par les serveurs ; les copies d'enveloppes confirmées sont supprimées, et celles qui n'ont pas été livrées sont effacées après une période limitée.

Mode de sauvetage

Diffusion SOS, vérification des intervenants, promotion du chat sécurisé

Le Mode de sauvetage sépare intentionnellement la découverte de la confiance. Une victime peut être trouvée sans jumelage préalable, mais un échange de chat de sauvetage sécurisé ne commence qu'après que la vérification de l'intervenant a réussi.

01 Beacon SOS

Beacon SOS

Un signal SOS déclenché par l'utilisateur place l'appareil dans un état de détresse local et émet des publicités BLE connectables pour le service `0xCC00`.
Le contenu de la publicité reste minimal dans la base : le signal radio expose la découverte au niveau du service plutôt qu'une identité authentifiée complète.
La diffusion SOS est conçue pour améliorer la découverte des intervenants à proximité lors des opérations de balayage sectoriel lorsque les réseaux étendus sont hors service.
Le coût de confidentialité est explicite : la découverte augmente en mode SOS, il est donc important le consentement, l'état UI clair et les contrôles de débit.

02 Vérification des intervenants

Vérification des intervenants

Après la connexion, les intervenant et la victime échangent un défi d'authentification et une réponse sur `0xCC10` et `0xCC11` et dérivent une clé de session ECDH éphémère.
La preuve de rôle chiffrée arrive sur `0xCC20` et doit inclure une référence de certificat, la portée du rôle, l'heure d'émission et la date d'expiration.
Les vérifications de validation signent, confiance, liaison de transcript, expiration et autorisation de rôle avant qu'une promotion sécurisée ne soit autorisée.
Les preuves invalides, malformées ou hors de portée sont rejetées à la porte plutôt que d'être dégradées dans le chat de secours.

03 Chat de secours sécurisé

Chat de secours sécurisé

Seulement après une vérification réussie, la victime émet `OK` sur `0xCC21`, ouvrant ainsi le chemin sécurisé.
Le chat de secours bidirectionnel chiffré se poursuit ensuite sur `0xCC30` et `0xCC31` avec des mécanismes d'accusé de réception `DELIVERED` et `READ`.
Les contraintes de base actuelles comprennent une taille de paquet de preuve de rôle limitée, un découpage conscient de MTU et une enveloppe de paquet de chat sécurisé de grande mais finie.
Les clients non vérifiés n'atteignent jamais le canal d'écriture sécurisé ; la porte de promotion est une limite rigide, et non une interface utilisateur consultative.

La propriété de sécurité principale est que le mode de secours ne fait pas correspondre la découverte avec la confiance. La découverte locale est suffisamment ouverte pour trouver les victimes ; le chat de secours sécurisé ne l'est pas.

Services en arrière-plan

Temps d'exécution et portée de plateforme

Le principal temps d'exécution institutionnel validé reste l'architecture du service Android. Un client iOS distinct est disponible publiquement avec un message axé sur BLE et une logique de secours contrôlée par le répondant, mais des preuves de déploiement de niveau répondant doivent toujours être examinées par plateforme.

SVC-01

RfcommForegroundService

Maintient l'écouteur de transport classique, la signalisation d'appel et les cycles de vie de transfert de médias ou de fichiers pour les sessions locales.

SVC-02

GattSOSServerService

Héberge le transmetteur SOS du mode de secours et le point d'extrémité d'interaction sécurisé avec le répondant utilisé par les victimes dans les flux de secours BLE.

SVC-03

GattRescueClientService + MeshAwareService

Gère les sessions de secours BLE côté répondant et, lorsqu'elles sont autorisées, la découverte Wi-Fi Aware et l'authentification du réseau avec un comportement de reconnexion limité.

SVC-04

CrisisLink, Outils hors ligne et Note iOS

Le service CrisisLinkForegroundService vide la télémétrie en attente après une récupération Internet validée, le OfflineDownloadService gère les régions de carte hors ligne et le client iOS distinct reste réel mais se trouve toujours derrière ses propres portes de préparation.

Cryptographie et modèle de menace

Garanties au niveau de l'application au-dessus des conditions radio instables

Le comportement des sockets Bluetooth et les conditions RF varient selon les appareils, de sorte que les garanties de chemin sécurisé sont définies au niveau de l'application. Le profil cryptographique, les hypothèses sur les menaces et le modèle de gestion des clés font partie explicite de l'architecture.

Couche 01

Contactez le chemin sécurisé : Les contacts provisionnés par QR utilisent AES-256-GCM avec des IV de 96 bits et des balises de 128 bits ; les cadres de main d'œuvre renforcés ne transmettent plus de matériel de clé en continu.

Couche 02

Certificats des intervenants : Le mode de sauvetage valide les certificats de rôle ECDSA P-256 hors ligne contre une clé publique d'autorité ancrée avant la promotion du chat sécurisé.

Couche 03

Clés de maillage des intervenants : Le maillage Wi-Fi Aware autorisé utilise une clé de groupe partagée ; le handshake sécurisé (GATT) dérive les clés de session par peer via un ECDH P-256 éphémère plus HKDF-SHA-256 et chiffre la conversation avec AES-256-GCM avec AAD lié à l'expéditeur, au destinataire et à la conversation, et les mises à niveau vers le format hérité sont rejetées une fois qu'une session Signal existe.

Couche 04

Politique de nonce et de relecture : Des IV générés par CSPRNG, des paquets limités par clé, un redémarrage ou un redémarrage, des caches de relecture, et l'idempotence UUID sont nécessaires pour maintenir le fonctionnement sécurisé d'AES-GCM.

Couche 05

Gestion des clés : Les clés de signature d'identité de l'appareil résident dans AndroidKeyStore (`dcs_attested_signing_key`), tandis que les matériaux symétriques sensibles sont stockés dans des préférences chiffrées et la sauvegarde est désactivée.

Couche 06

Limite du canal public : Les paquets GATT publics peuvent contenir un enveloppe AES-GCM pour l'intégrité et le durcissement du format, mais le canal est toujours traité comme un trafic de coordination public non confidentiel.

Couche 07

Enveloppe de message Internet : Le chemin préféré pour les messages sur Internet est le protocole Signal via libsignal (Double Ratchet + PQXDH post-quantique) ; l'enveloppe de compatibilité utilise ECDH P-256 + HKDF-SHA-256 + AES-256-GCM avec AAD lié à l'expéditeur, au destinataire et à la conversation, et les mises à niveau vers le format hérité sont rejetées une fois qu'une session Signal existe.

Couche 08

Médias et TURN pour les appels : Les appels WebRTC utilisent des médias DTLS-SRTP chiffrés avec un signal d'appel transporté dans des enveloppes chiffrées de bout en bout ; TURN ne transmet que des paquets chiffrés, et les identifiants sont générés côté serveur avec de courtes durées de vie.

Couche 09

Modèle de menace : La conception suppose l'écoute RF passive plus l'interception active, la falsification, le brouillage, le débordement des appareils et les tentatives de perturbation du plan de contrôle dans le cloud. Sur le chemin Internet, les serveurs et l'infrastructure relais sont considérés comme non fiables pour le contenu : aucun texte ne parvient à un serveur, tandis que les métadonnées de livraison restent visibles.

Couche 010

Exclusions explicites : La compromission complète du système d'exploitation, la coercition de l'utilisateur et le brouillage RF à grande échelle restent hors champ, de sorte que les affirmations de déploiement ne doivent pas impliquer une protection là.

La défense en profondeur ici signifie le chiffrement côté expéditeur, la vérification côté destinataire, les portes de rôle explicites et la politique des métadonnées limitées. Cela n'efface pas l'impact sur la vie privée d'être détectable sur les ondes radio.

Confidentialité et Gouvernance

Métadonnées, contrôle du bruit, et propriété opérationnelle

La sécurité opérationnelle en cas de catastrophe dépend autant du flux d'informations limité que du chiffrement. Les décisions politiques, la discipline des métadonnées et le suivi des preuves font partie de l'architecture technique ici.

Hygiène de l'information

La communication civile par défaut reste dans les contacts pré-provisionnés, la découverte SOS est séparée du chat sécurisé, et le maillage public doit réserver des instructions officielles pour les formats d'annonce validés par les intervenants, et le mesh public révèle intrinsèquement les étiquettes de l'expéditeur et les métadonnées de saut.

Politique des métadonnées sur le réseau

Les émissions d'onboarding sont limitées dans le temps, la préparation régulière évite des identifiants humains lisibles, le mode SOS expose intentionnellement l'UUID du service de sauvetage, et le maillage public révèle intrinsèquement les étiquettes de l'expéditeur et les métadonnées de saut.

Rétention et Anonymisation

La persistance des messages utilise des enregistrements basés sur UUID, l'historique des événements est tronqué dans des fenêtres limitées, les clés sensibles restent dans un stockage local chiffré, et les journaux du pilote doivent pseudonymiser les identifiants d'appareil et quantifier la localisation.

Propriété du contrôle

Les autorités ont besoin de propriétaires explicites pour l'émission de certificats, le cadencement des listes noires, le renouvellement des clés, la révocation d'urgence et les artefacts de preuve utilisés dans les revues Go ou No-Go.

La posture de confiance sur Public GATT est un contrat de gouvernance plus qu'une garantie de produit fermé aujourd'hui ; les preuves de dégradation et la couverture des parseurs restent des éléments à examiner.

Plan de confiance assisté par le cloud

Hors du chemin d'urgence de proximité ; enveloppes chiffrées uniquement sur le chemin en ligne

Crisis Connect peut fonctionner entièrement hors ligne pour la communication de contact à contact de proximité. Les services cloud effectuent deux tâches : l'établissement de la confiance avec le support de télémétrie opérationnelle, et la livraison d'enveloppes chiffrées pour les messages sur Internet. À aucun moment, les serveurs ne peuvent accéder au contenu chiffré bout en bout, et le chemin d'urgence de proximité fonctionne sans le cloud.

Identité et émission

Les autorités peuvent émettre des certificats de rôle de répondant, faire tourner les clés et intégrer le flux de confiance avec l'IAM institutionnel ou un IdP hébergé sur site tel que Keycloak.

Support de vérification hors ligne

Les appareils stockent les ancres de confiance et les ensembles de politiques localement afin que la vérification des répondants puisse se poursuivre sans une connectivité cloud en direct ; les instantanés de la liste noire sont une extension de déploiement pour les fenêtres de connectivité.

Télémétrie de Crisis Link

Les répondants autorisés peuvent mettre en file d'attente et synchroniser ultérieurement des instantanés de télémétrie de sauvetage lorsque l'Internet est rétabli, mais ce canal ne transmet pas les charges utiles de chat d'urgence.

Livraison d'enveloppes chiffrées

Pour les messages sur Internet, le backend stocke uniquement des enveloppes chiffrées et des métadonnées de routage afin que les messages puissent atteindre les destinataires qui sont hors ligne ; les copies du serveur sont supprimées une fois la livraison confirmée, et les enveloppes non livrées sont effacées après un TTL limité.

Division du plan de confiance: Le contenu d'urgence de proximité reste sur BLE, RFCOMM, Wi-Fi Aware ou le canal Public GATT opt-in ;

tandis que les systèmes cloud gèrent la durée de vie des certificats, la distribution des ancres de confiance, la synchronisation de la télémétrie et la livraison d'enveloppes chiffrées pour les messages sur Internet.

Les déploiements de production doivent conserver les clés signées en dehors du code source et derrière des contrôles tels que HSM, KMS ou Secret Manager.

Porteuses de preuve et étapes d'acceptation

Ce qui doit être mesuré avant un déploiement plus large

Les affirmations architecturales ici doivent être jugées sur la base des preuves du terrain plutôt qu'uniquement sur l'intention du protocole. L'approbation pilote doit être basée sur les données de scénario, et non sur l'intention de conception.

Succès de livraison des messages: Au moins 95 % dans les scénarios intérieurs ou urbains et 85 % dans les conditions similaires à un terrain en ruine.

Latence du texte: La latence P95 bout en bout doit rester inférieure ou égale à 5 secondes sur les enveloppes prévues.

Enveloppe vocale: La latence moyenne d'une seule direction doit être inférieure ou égale à 150 ms avec une perte de paquets soutenue inférieure ou égale à 3 % pendant les appels actifs.

Impact sur l'alimentation: La découverte en mode veille et le transfert ou la déconnexion vocale doivent rester dans les limites définies par la mission ; les preuves actuelles de Pixel 7a en mode veille sont des informations complémentaires, et non un arrêt définitif.

Flux de travail du secours: Les SOS, la vérification des rôles, l'échange sécurisé de messages et l'activation autorisée du réseau doivent réussir dans 100 % des scénarios de validation.

Contrôle de l'abus sur les canaux publics: Les paquets publics malformés ou en dehors des fenêtres doivent être rejetés avant la transmission à un taux supérieur ou égal à 99 %, et les annonces des intervenants non vérifiées ne doivent jamais apparaître comme des alertes fiables.

Séquence recommandée pour le pilote

Pilote intervenant: Commencez avec une flotte d'appareils formés et validez l'émission de certificats, le mode de sauvetage, le comportement du service en arrière-plan et l'activation autorisée du réseau en fonction des rôles.

Matrice de scénarios: Effectuez des exercices en intérieur, en milieu urbain, en extérieur et dans des décombres avec des conteneurs fixes, des mesures RSSI, des notes sur le traitement du temps et des traces explicites de continuité ou de perte vocale.

Examen de gouvernance: Fixez les paramètres des canaux publics, documentez les procédures de révocation et de transfert, cartographiez les revendications vers des artefacts de preuves et envisagez uniquement ensuite un déploiement plus large et progressif.

État actuel des preuves

Le Bluetooth reste basé sur la proximité ; sa couverture est limitée par l'environnement, les obstructions, les politiques de puissance du matériel et du système d'exploitation.

Le système prend en charge la coordination sectorielle locale, mais ne garantit pas la portée à tous les victimes dans toutes les conditions de débris.

Les flux civils par défaut dépendent des liens locaux ; les modes maillés nécessitent un matériel compatible, une activation explicite et une proximité radio locale.

Le maillage GATT public est facultatif, désactivé par défaut et n'est pas recommandé comme paramètre toujours actif pour tous les profils d'utilisateurs.

Le contenu opérationnel sensible doit rester sur des chemins sécurisés ou des canaux de réponse gérés par rôle plutôt que sur des surfaces de coordination publiques.

Un relais ou un transfert non contrôlé restent hors du champ des validations.

Les preuves de déploiement institutionnel actuellement validées se concentrent sur la version Android ; iOS est disponible publiquement, mais nécessite également des preuves de préparation pour les utilisateurs.

La variation des gestionnaires de batterie des appareils, du système d'exploitation et des fabricants peut modifier considérablement le comportement ; par conséquent, les pilotes doivent mesurer les flottes plutôt que de supposer que les résultats d'un seul téléphone sont généralisables.

L’annuaire téléphonique en ligne exige Internet et des numéros préalablement vérifiés pour les deux personnes. Cela ne bloque pas le QR sans Internet ; après vérification, À proximité peut aussi appairer localement hors ligne.

Sur le chemin Internet, le contenu reste chiffré bout à bout, mais les métadonnées de livraison, de signalisation et de relais — identifiants, horodatages, adresses IP — sont traitées par des serveurs et une infrastructure TURN.

SécuritéCrisis Connect ne remplace pas les services d'urgence officiels. Lorsque tout chemin à grande échelle est disponible, les utilisateurs doivent toujours tenter le numéro d'urgence local tel que 112, 911 ou l'équivalent national.

Scénarios de déploiement

Messagerie et appels vocaux/vidéo chiffrés bout à bout avec des proches éloignés lorsque l'Internet est disponible

Communication familiale ou d’équipe avec des contacts ajoutés localement par QR avant ou pendant une coupure, ou par téléphone vérifié lorsque les conditions sont réunies

Messagerie et partage de localisation hors ligne pendant les voyages ou le travail sur le terrain sans connexion Internet

Tremblements de terre ou effondrements d'infrastructures où les victimes envoient des signaux SOS et les intervenants vérifient avant la conversation sécurisée

Victimes connectées à Internet dont les rapports SOS sont acheminés vers des panneaux de réponse autorisés

Conversation de groupe sécurisée pour les seuls intervenants sur Wi-Fi Aware sur du matériel Android pris en charge

Coordination et annonces générales à proximité grâce au maillage GATT public facultatif lorsque cela est explicitement activé

Appels vocaux via des liens Bluetooth directs lorsque l'enveloppe RF et de puissance le permettent

Téléchargement hors ligne de cartes, outils de survie ou d'utilité locaux, et flux de travail de préparation aux situations d'urgence sur les clients mobiles pris en charge

Synchronisation facultative de la télémétrie Crisis Link vers les backends institutionnels après récupération du réseau internet validée

Résultat architectural

L'architecture mobile de Crisis Connect est intentionnellement conservatrice : lorsque le réseau est actif, le contenu se déplace via des enveloppes chiffrées bout à bout et les serveurs ne y ont pas accès ; en cas de panne du réseau, Bluetooth direct est la voie par défaut pour l'incident, la confiance est établie hors ligne, les flux sécurisés des intervenants sont contrôlés par des certificats, et le cloud reste en dehors de la zone d'urgence. Le système est adapté aux pilotes institutionnels axés sur les preuves autour de la version Android, tandis qu'un déploiement plus large pour les intervenants doit attendre une validation sur le terrain selon les seuils d'acceptation déclarés.

Code source ouvert

Code source et implémentation

L'architecture Android de base et la version publique actuelle, y compris le transport Bluetooth hors ligne, la logique de promotion du Mode d'urgence, et le plan de confiance cryptographique, sont publiées ouvertement pour examen et reproductibilité.

emirhan-duman/Crisis-Connect

AGPL-3.0Tickets

Afficher le dépôt