- Les nouveaux DM chiffrés de Twitter(X) (XChat) revendiquent techniquement un chiffrement end-to-end, mais de graves failles de sécurité subsistent, notamment le vol de clés privées, les attaques MITM et l’exposition des métadonnées
- Libsodium Box (chiffrement basé sur clé secrète) a été adopté, mais l’absence de forward secrecy et une protection des clés faible fondée sur un code PIN à 4 chiffres rendent l’extraction des clés privées relativement facile
- Le protocole Juicebox sert à sauvegarder/restaurer les clés, mais la sécurité réelle dépend entièrement de la confiance accordée au backend et, comme Twitter exploite lui-même tous les backends, le sharding n’a presque aucun intérêt
- Aucune procédure out-of-band n’existe pour authentifier/vérifier les clés publiques, ce qui permet à Twitter de les remplacer dans une attaque MITM (homme du milieu), tandis que les métadonnées des utilisateurs restent exposées
- Contrairement à Signal, la protection effective de la vie privée reste insuffisante à ce stade, d’où la recommandation d’utiliser Signal comme messagerie chiffrée digne de confiance
Analyse des nouveaux DM chiffrés de Twitter
Contexte et résumé
- Twitter(X) a dévoilé sa nouvelle plateforme de messagerie chiffrée XChat, présentée comme développée en Rust et reposant sur une architecture cryptographique inspirée de Bitcoin
- Mais à l’examen de l’implémentation réelle, l’architecture permet toujours à Twitter d’accéder aux clés privées, de mener des attaques MITM (homme du milieu) et de collecter les métadonnées
- Conclusion : utiliser Signal est recommandé, les DM de Twitter(X) ne sont pas sûrs en raison de limites structurelles fondamentales
Architecture de chiffrement et limites
1. Méthode de chiffrement
- Utilise
box de Libsodium (chiffrement à clé publique)
- Pas de forward secrecy : si une clé privée fuit, tous les messages précédents peuvent être déchiffrés (donc une solution plus faible que les messageries modernes comme Signal)
- L’implémentation réelle n’utilise pas Rust, mais une bibliothèque C liée via jni
2. Stockage et récupération des clés (protocole Juicebox)
- Les clés privées générées sur l’appareil sont stockées via le protocole Juicebox
- Les clés sont enregistrées après chiffrement à partir d’un PIN à 4 chiffres, et la récupération nécessite la saisie de ce PIN
- Le serveur ne connaît pas le PIN, mais comme il n’a que 4 chiffres (10 000 combinaisons), il peut être cassé rapidement par force brute en parallèle
- Même avec Argon2id et des paramètres de 16 MB de mémoire pour 32 itérations, cela ne constitue pas un obstacle majeur pour un attaquant réel (moins de 0,2 seconde même sur un ordinateur portable modeste)
3. Limites de l’architecture de distribution des clés (sharding)
- Juicebox prend en charge la répartition sur plusieurs backends (sharding), mais Twitter exploite lui-même les trois backends
- En pratique, le processus de récupération des clés dépend donc entièrement de la confiance accordée à Twitter, sans bénéficier de l’avantage de sécurité fondamental du sharding
- Il n’existe pas non plus de mécanisme de vérification matérielle, tel que HSM ou SGX, pour communiquer de manière sûre avec les backends
4. Faiblesses de l’authentification/échange des clés publiques
- La clé publique du correspondant est uniquement reçue via les serveurs de Twitter, sans moyen de vérification séparé (out-of-band)
- Twitter peut donc, quand il le souhaite, fournir une clé publique arbitraire et mener une attaque MITM (homme du milieu)
- La page d’assistance officielle reconnaît d’ailleurs cette faiblesse et se contente d’annoncer de futures améliorations, sans mesure concrète à ce jour
5. Métadonnées et autres problèmes
- Twitter peut entièrement savoir qui échange avec qui, et quand les messages sont envoyés ou reçus
- Même sans exposition directe des clés privées, les schémas de communication des utilisateurs restent visibles par l’entreprise
Conclusion et recommandations
- En raison des limites de conception des DM chiffrés, la solution reste inférieure, en matière de sécurité réelle et de vie privée, à des messageries éprouvées comme Signal
- Tant que Twitter contrôle à la fois les clés publiques, le keystore et le chemin de communication, on ne peut pas parler de véritable chiffrement end-to-end
- L’usage d’une messagerie reposant sur un protocole ouvert et transparent comme Signal est fortement recommandé
1 commentaires
Avis Hacker News
Je suis un admirateur de tout ce qu’écrit Matthew Garrett, mais je veux souligner avec insistance que Signal prend en charge la forward secrecy depuis longtemps. L’idée moderne de la messagerie sécurisée est née en grande partie avec OTR (Borisov et Goldberg), qui a été parmi les premiers à introduire les concepts de « perfect forward secrecy » et de déni plausible. Signal me semble être l’aboutissement de ces idées, ainsi que de leur mise en œuvre côté ingénierie (meilleure cryptographie, meilleur code, meilleur packaging). Ce qui est frustrant, c’est que les nouveaux messagers ne régressent pas au niveau « pré-Signal », mais au niveau de sécurité d’avant 2001, donc d’avant l’ère moderne
Il y a trois points à retenir de diverses fuites passées. (1) Le FBI a « forcé » des entreprises à installer discrètement des portes dérobées. Il a aussi été mentionné que la cour FISA pouvait infliger des amendes massives aux sociétés. (2) De très grandes entreprises ont reçu des dizaines, voire des centaines de millions pour le coût de ces portes dérobées. Et l’État a aussi exercé des pressions par divers moyens, comme des contrats publics ou des licences d’exportation. En somme, on peut y voir une politique du type « la bourse ou le fusil ». (3) Dans l’affaire Lavabit, le FBI a exigé la remise des clés tout en forçant de fait l’entreprise à mentir à ses clients. Quand on se souvient de tels précédents, on peut soupçonner que le chiffrement intégré aux grandes plateformes est souvent soit volontairement affaibli à la demande des gouvernements, soit simplement mal implémenté par négligence. Tant que le Patriot Act, le FISC, les interprétations secrètes et les pratiques associées n’auront pas disparu, et tant que les responsables ne seront pas sanctionnés, je pars du principe que le chiffrement dans un État policier a déjà été compromis par les Five Eyes
Tant que les gens installeront des applis PC via l’App Store, cette situation rétrograde risque de perdurer
S’il n’y a ni clé éphémère, ni forward secrecy, ni transcript d’interaction, je me demande bien ce qu’il y a réellement de « style bitcoin » là-dedans
Il y a bien un peu de cryptographie, mais ça ressemble surtout à une dérivation peu intéressante et presque inutile
En clair, ça n’a pas de réelle utilité pratique
Bitcoin lui-même n’est pas non plus un canal de communication sécurisé
Il y a aussi l’usage d’une dérivation de clé basée sur un PIN. Mais cela ressemble davantage à une implémentation de sauvegarde qu’à quelque chose d’essentiel à la messagerie elle-même
Mention de l’utilisation d’une fonction de hachage
Partage d’un lien vers une discussion précédente :
Le nouveau XChat « chiffré » de X n’est pas tellement plus sûr non plus
Voir le commentaire associé
Pour chiffrer, il vaudrait sans doute mieux utiliser un logiciel séparé et échanger les clés publiques en face à face
Question : je vais bientôt à Pékin et je me demande s’il est possible d’utiliser Twitter sans VPN
Je m’interroge sur l’expression « Bitcoin style encryption ». À ma connaissance, Bitcoin repose davantage sur des signatures cryptographiques que sur ce qu’on appelle habituellement du « chiffrement »
En réalité, ce terme ne veut rien dire ; c’est juste un mot marketing destiné à sonner bien auprès des gens peu familiers avec la technique
Il faut garder à l’esprit que l’auteur de cette déclaration n’est pas quelqu’un de très pointu techniquement
S’il a employé ce terme, c’est probablement parce qu’il savait qu’il susciterait des réactions. On peut y voir un choix stratégique pour attirer davantage l’attention
Partage d’un lien vers une vidéo explicative
https://www.youtube.com/watch?v=sJNK4VKeoBM
C’est juste un mot à la mode utilisé pour donner l’impression de quelque chose de cool et de « précieux »
Je me demande si le vrai XChat (le client IRC) pourrait poursuivre X-Twitter pour atteinte à la marque
http://xchat.org/
J’ai le souvenir de l’époque où, en tant qu’utilisateur IRC, on passait de XChat à HexChat. Du coup, j’ai été surpris d’apprendre que HexChat aussi avait arrêté son développement
Annonce de la fin de HexChat
C’est probablement possible, mais il faudrait que XChat démontre clairement une valeur commerciale sur chaque segment où X porterait atteinte à la marque, et que la marque soit enregistrée dans chaque juridiction concernée pour que ce soit facilement reconnu. Sinon, ce serait plus compliqué
Ce qui est amusant avec la bibliothèque utilisée par Twitter (d’après l’article source), c’est que le développeur lui-même écrit dans sa description :
« Avertissement : bibliothèque expérimentale ! Ne l’utilisez pas en production tant qu’elle n’a pas été auditée. Risques et bugs probables »
https://github.com/ionspin/kotlin-multiplatform-libsodium
Je reste admiratif de la puissance de la marque Twitter, qui conserve encore son pouvoir malgré le rebranding