Dans MindTheClub, le contenu des messages voyage directement entre deux appareils par un canal pair-à-pair chiffré. Aucun serveur MindTheClub, ni aucun tiers, ne stocke le contenu de vos messages.
Pour établir cette connexion directe, deux appareils doivent échanger une petite quantité d'informations de mise en place et, si l'un d'eux dort, un signal pour le réveiller. Ces deux étapes de soutien sont les seuls endroits où un serveur intervient, et nous décrivons ci-dessous précisément ce que chacun peut voir et ne pas voir.
Avant tout cela, les deux appareils doivent connaître l'identité l'un de l'autre. Nous le décrivons en premier, car chaque étape ultérieure de cette page s'appuie dessus.
Chaque étape chiffrée qui suit repose sur une hypothèse : chaque pair utilise la vraie clé publique de l'autre, pas une clé substituée par un fournisseur intermédiaire. Nous y parvenons avec un unique échange hors bande et une réponse scellée, de sorte que les deux parties sont vérifiées après un seul scan de QR ou un seul appui sur un lien d'invitation.
Votre code QR contient votre identifiant utilisateur et une empreinte de votre clé publique, un court condensé cryptographique qui l'identifie de façon unique. Votre lien d'invitation porte les deux mêmes éléments, intégrés dans le lien lui-même. Ainsi, que quelqu'un scanne votre code ou touche votre lien, son appareil reçoit la même empreinte à vérifier. Montrer le QR en face à face est le canal le plus sûr, mais dans les deux cas la garantie ci-dessous tient : le fournisseur de l'annuaire ne peut jamais substituer votre clé sans être détecté.
Quand l'autre personne scanne ou touche, son appareil récupère votre clé publique dans l'annuaire et calcule son empreinte localement. Si elle correspond à celle du QR ou du lien, la clé est acceptée ; sinon, elle est rejetée et non enregistrée. Une clé substituée produit une discordance, et l'appareil la refuse.
Son appareil vous envoie ensuite une demande de contact avec sa propre empreinte scellée à l'intérieur, chiffrée avec votre clé vérifiée. Vous seul pouvez la déchiffrer. Votre appareil effectue la même vérification en sens inverse, n'acceptant le contact que si les empreintes correspondent.
Après un scan ou un appui, les deux pairs ont vérifié indépendamment la clé l'un de l'autre, et un fournisseur détenant l'annuaire ne peut substituer aucune des deux sans casser une vérification qu'il n'a aucun pouvoir de falsifier.
MindTheClub utilise des canaux de données WebRTC pour transporter les messages. Un canal de données WebRTC est une connexion directe et chiffrée entre deux appareils. Une fois établi entre deux pairs :
Les gros fichiers sont découpés en blocs et envoyés par le même canal direct, avec une logique de reprise sur l'appareil émetteur pour garantir la livraison finale. Les blocs voyagent en pair-à-pair comme tout le reste.
Parfois, deux appareils ne peuvent pas ouvrir de chemin direct (NAT restrictifs, pare-feu d'opérateurs mobiles). Dans ce cas, WebRTC se rabat sur un relais TURN pour faire transiter le flux chiffré. MindTheClub utilise le service TURN de Cloudflare pour ce repli. Le relais transmet des paquets chiffrés ; c'est un élément standard du fonctionnement de WebRTC quand une connexion directe est impossible. Ce repli n'affecte que le chemin réseau du flux chiffré ; il ne change rien au fait que le contenu reste de bout en bout entre les deux appareils.
Avant qu'un canal WebRTC puisse s'ouvrir, les deux appareils doivent échanger des informations de « signalisation » : descriptions de connexion et adresses réseau candidates (en termes WebRTC, l'offre/réponse SDP et les candidats ICE). C'est une exigence universelle de WebRTC : toute application WebRTC, y compris les sites d'appels vidéo, le fait. Ces informations sont légères et ne servent qu'à établir la connexion ; ce n'est pas le contenu de vos messages.
La question est : qui transporte cette signalisation, et que peut-il voir ? Dans MindTheClub :
Nous avons conçu la signalisation pour que le relais en apprenne le moins possible :
Si le téléphone de Bob dort ou que l'application ne tourne pas, l'appareil d'Alice a besoin d'un moyen de le réveiller pour qu'il rejoigne la connexion. Pour cela, MindTheClub utilise Firebase Cloud Messaging (FCM), le service push de Google, car c'est le mécanisme fourni par Android pour réveiller une application de façon fiable depuis l'arrière-plan.
Le contenu de la charge de réveil est chiffré avec la clé publique du destinataire avant de quitter l'expéditeur. Point crucial : l'identité de l'expéditeur se trouve à l'intérieur de cette charge chiffrée ; elle n'est pas visible pour l'infrastructure push. C'est une conception « expéditeur scellé » : la partie qui livre le push ne peut pas voir qui l'a envoyé.
Pour livrer un push, tout système push doit savoir qui le reçoit ; c'est ainsi que fonctionne la livraison, et c'est vrai de toute messagerie basée sur le push. L'adresse du destinataire est donc nécessairement visible pour la couche push. Ce qui n'est pas visible, c'est l'identité de l'expéditeur, qui reste scellée dans la charge chiffrée.
Pour établir la connexion WebRTC, les appareils ont besoin d'identifiants de courte durée pour le service STUN/TURN (les composants qui aident deux appareils à trouver un chemin réseau l'un vers l'autre). Ces identifiants sont générés à l'aide d'une clé secrète qui doit rester hors de l'appareil.
MindTheClub récupère ces identifiants auprès d'un Cloudflare Worker qui détient le secret côté serveur. Aucun service Google n'intervient dans l'obtention des identifiants de connexion. Si cette récupération échoue, la connexion se rabat sur des serveurs STUN publics, qui aident seulement un appareil à découvrir sa propre adresse publique et n'apprennent rien sur qui il contacte.
En résumé : les pairs vérifient mutuellement leurs clés avec un scan de QR ou un lien, puis échangent de petites quantités d'informations de mise en place chiffrées via un relais sans état et un push de réveil scellé. Une fois le canal direct ouvert, le contenu des messages circule uniquement d'appareil à appareil.