Une des questions cruciales à se poser sur une messagerie « sécurisée » est comment sont gérées les méta-données?
Par exemple, il est intéressant pour la NSA et autres états qui surveillent en masse de savoir qui parle à qui et à quelle fréquence. Ça permet aisément de construire des réseau de relations à faible coût.
Regardons maintenant un petit peu comment fonctionnent Textsecure et Telegram .
Pour mettre en relation les utilisateurs, ceux-ci se basent sur le numéro de téléphone.
Chaque utilisateur est identifié par son numéro de téléphone, vérifié par l’envoi d’un SMS sur le terminal lorsque l’on crée son compte de messagerie.Ensuite, lorsque l’on envoie un message à un contact, ça se passe grosso modo comme ça :
on envoie le numéro de téléphone de son correspondant.
le serveur cherche dans sa base d’utilisateurs connectés si il trouve le numéro de téléphone.
le message est transmis au terminal de notre correspondant par la connexion permanente (PUSH) établie entre le terminal de notre correspondant et le serveur.
On comprend bien que déjà la personne qui gère le serveur sait qui parle à qui et à quelle fréquence.
Ensuite, on peut avoir quelques fioritures encore plus pourries :
Par exemple, comment savoir avec quels contacts je peux utiliser mon « application de communication sécurisée » ? En demandant au serveur, pour chacun des numéros de mon carnet de contact, s’il correspond à utilisateur enregistré. Bingo, vous venez d’envoyer la totalité des numéros de votre carnet de contact.
Ce qui est encore plus rigolo, c’est que même si vous ne l’avez pas fait mais que vos contacts ont envoyé leur carnet de contacts, par recoupement, le serveur peut reconstruire le votre. La preuve flagrante, c’est quand vous créez un compte avec un carnet d’adresse vide, mais qu’automatiquement, le serveur trouve vos amis (Ex: facebook, linkedin, etc…)
Pour moi, le design de base de ces applications rendent impossible la protection des métadonnées des échanges sauf si l’on a confiance dans le serveur. Croyez-vous encore au « Don’t be evil »?
Une solution serait :
Utiliser un identifiant ne permettant pas de remonter facilement à l’identité réelle de l’utilisateur (ex : un numéro aléatoire)
Ne pas laisser le serveur connaître qui envoie le message (ex: le message ne contient que l’identifiant du destinataire en clair, le message envoyé par l’utilisateur émetteur passe par plusieurs relais avant d’arriver au serveur. On peut ainsi dire que le message est envoyé de manière anonyme. L »identité de l’émetteur est à l’intérieur du message chiffré que seul le destinataire peut déchiffrer)
# Ton fournisseur d'accès téléphonique
Posté par Le Gab . Évalué à 2.
À partir de là, c'est déjà foutu. :)
Sinon, Tox décrit un peu ce que tu veux faire, le client linux de base "Venom" n'offre que le texte pour l'instant mais ça marche, il manque cela dit une intégration avec le bureau.
[^] # Re: Ton fournisseur d'accès téléphonique
Posté par tuxicoman (site web personnel) . Évalué à 1.
Si ma connexion est chiffrée jusqu'au prochain relai est chiffrée, et que les autres relais font de même, il fait quoi mon fournisseur de réseau? Du timing attack? Tu peux développer?
# D'autres voies
Posté par rakoo (site web personnel) . Évalué à 2.
Merci pour ce rappel sur la nécessité de bien comprendre ce que veut dire un projet lorsqu'il se dit "NSA-proof".
Il y a d'autres voies pour une application seule (ie sans passer par Tor) de cacher un peu les participants à une conversation:
Plutôt que de cacher l'émetteur, cacher le destinataire, comme twister le fait. Les destinataires potentiels doivent alors essayer de déchiffrer tous les messages en espérant qu'il y en ait un pour eux.
L'étape d'après: masquer expéditeur et destinataire. Tous les participants du réseau doivent alors essayer de déchiffrer tous les messages pour voir s'il n'y en a pas un pour eux. Ça peut sembler lourd, mais il y a au moins un projet qui tente l'expérience pour voir ce que ça donne: bitmessage.
[^] # Re: D'autres voies
Posté par tuxicoman (site web personnel) . Évalué à 3.
J'ai essayé BitMessage. Le problème de ce concept, c'est qu'il n'est pas applicable aujourd'hui aux smartphones.
Il faut un puissance de gueux pour décoder le stream de nouveaux messages si on a laché le fil quelques jours. L'autonomie du smartphone est morte.
De plus, pour les interactions en presque temps réel (chat par exemple), c'est impossible.
[^] # Re: D'autres voies
Posté par Renault (site web personnel) . Évalué à 9.
Le spam va tuer ce concept en noyant le flot d'informations utiles.
# ou pas
Posté par Firwen (site web personnel) . Évalué à 1. Dernière modification le 16 mars 2014 à 12:42.
Tu as pas du beaucoup te renseigner pour sortir ça.
Dans le cas de Text Secure, tu n'envoies à aucun moment ton carnet d'adresse au serveur.
Ce que tu envoie au serveur c'est un hash de ton numéro associée à ta clé publique : pair< hash(numéro de tel ), Kpub>.
Lorsque tu dois trouver si un utilisateur X utilise TextSecure, l'application fait simplement un lookup(Hash(num)) -> PubKey
il est également possible d'héberger son propre serveur, pour les cas de paranoia extrème.
[^] # Re: ou pas
Posté par rakoo (site web personnel) . Évalué à 2.
Mouais.
Un rapide parcours de la page Wikipédia me fait dire que même avec les indicatifs nationaux, un numéro de téléphone a 15 caractères maximum, dans un alphabet de 10 caractères: ça fait 1015 combinaisons grand max.
Cette autre page me dit qu'avec un montage de GPU standards, je peux espérer calculer 1 Milliard de ces combinaisons par secondes
Du coup pour avoir la liste de tous les hashs de tous les numéros de téléphones, ça me prendrait 106 secondes, soit un peu moins de 300 heures. Et ça c'est en étant large sur les chiffres.
Note: Textsecure semble utiliser sha-256, et j'ai pas inclus les ASIC parce que je sais pas exactement pour quoi ils sont taillés, mais s'ils font du sha-256 eux aussi…
Note2: même l'auteur sait que c'est pas viable sur le long terme.
[^] # Re: ou pas
Posté par tuxicoman (site web personnel) . Évalué à 1.
oui, ça a été rapporté à moxie des le début avant même qu'il publie la version finale. mais bon c'est sorti quand même et étiqueté "secure" :D
même sans ça, le serveur a quand même les couples (hash émetteur, hash destinataire) de chaque message.
sachant que les numéros de tel peuvent etre associés facilement au hash lors de l'inscription du numero de tel au service…
[^] # Re: ou pas
Posté par Firwen (site web personnel) . Évalué à 2. Dernière modification le 16 mars 2014 à 18:49.
Oui c'est sécure, TextSecure n'a jamais vendu une quelconque confidentialité des méta-données.
Les données, elles, sont chiffrés proprement et hors du champs de vue du serveur et du medium de transport. Ce qui est déja nettement mieux que la plupart des solutions actuelles.
Non ce n'est pas la solution ultime et moxie le dit lui même, l'entropie des numéros de téléphone est beaucoup trop faible et ça les rend vulnérable aux attaques par dictionnaire.
Mais il y a déja une grosse différence entre stocker un hash… et stocker le carnet d’adresse complet en clair comme LINE, facebook messenger ou whatsaps qui va se retrouver copier/coller sur pastebin au premier DB leak venu.
Dans le cas du layer SMS, les messages ne passent pas par le serveur qui ne connait que les lookup que tu effectues ( un seulm et unique par session en théorie )
Pour revenir au sujet initial :
C'est pas aussi simple malheureusement.
Dans ton cas 1, l'utilisation d'un numéro aléatoire sans aucune preuve d'identité implique de te rendre vulnérable au Spam, car le premier bot venu pourra générer un numéro aléatoire. La seul alternative à ma connaissance à ça est un système de proof of work à la Bitcoin, ce qui est énergivore donc incompatible avec une utilisation mobile….Un comble pour une app de messagerie.
Dans ton cas 2, ton serveur connaîtra au minimum l'identité réseau de l'acteur ( l'addresse IP ) à moins que tu utilises un système de routage en onion à la Tor, ce qui encore… est incompatible avec le mobile.
Et tu te rends également vulnérable au DDOS car n'importe quel botnet peut allègrement spammer ton serveur et le réseau entier de manière anonyme : ses messages ne sont pas identifiés, ils n'ont pas d'expéditeur, personne ne peut le filtrer.
TextSecure est bon pour la confidentialité des données, moins bon pour la confidentialité des meta-données. Je trouve un poil rabat-joie de le dénigrer sans rappeler que Skype, facebook Messenger, whatsapp, Viber, Line and co sont :
1- propriétaires
2- disposent d'une copie en clair serveur side de tous vos messages…. ou des clés pour les décrypter.
Et que comparé à ça, TextSecure c'est déja une franche évolution et sincèrement, merci à Moxie pour son boulot.
[^] # Re: ou pas
Posté par tuxicoman (site web personnel) . Évalué à 3.
Comme dit plus haut, le hash du tel, même salé, c'est faible pour masquer l'identité des communiquants. Mais chacun sa notion de "secure".
Pour revenir au sujet. Je suis d'accord avec toi, le spam est le problème de ma solution.
Pour contrecarrer cela, je pensais :
1. Donner un token aux contacts dont j'accepte les messages. Ce token, envoyé avec les messages à ma destination permettrait au messages d'etre traités prioritairement par rapport aux autres messages reçus.
Les messages d'inconnus (sans token) doivent avoir une preuve de travail, ce qui limite un peu le spam.
2. Recevoir les messages par l'intermédiaire d'un serveur (comme un serveur de mail). Ce serveur pourrait filtrer les messages avec ou sans token pour transmettre en priorité à mon smartphones ceux qui ont un token.
3. Ensuite, pour les nouveaux contacts, il pourrait y avoir un autre token à envoyer par l’expéditeur qui dépende de sa clé privée et de ma clé publique de telle sorte que le serveur pourrait détecter les demandes de messages répétées d'un même expéditeur sans pour autant savoir quel est l’expéditeur ni le contenu du message.
La connexion serveur(de reception) -> destinataire est directe.
La connexion expediteur -> serveur(de reception) est indirecte Tor ou autre juste pour masquer son IP.
Sinon, je suis bien d'accord que Skype, facebook Messenger, whatsapp, Viber, Line, Hangout, and co sont des services où le client se fait plumer de haut en bas ses données persos. Mais je pensais que le sujet était déja arrivé plus haut donc, voila.
J'ai aussi un problème avec le design d'OTR. Si l'une des parties a perdu son token (ex: reboot du device, changement de logiciel client) et que l'autre continue de lui envoyer un message en pensant la conversation toujours en cours, le message sera illisible en face. Donc, OTR me semble vraiment limité à des clients qui peuvent converser en temps réel en continu, ce qui est un peu problématique pour une utilisation asynchrone type "envoyer un message securisé à un correspondant hors ligne"
[^] # Re: ou pas
Posté par Firwen (site web personnel) . Évalué à 1.
Désolé pour mon ton un poil aggressif, tu as parfaitement raison sur la partie technique.
Ton article était un peu dénigrant à mon gout sur des solutions qui partent de base qu'une bonne intention : Améliorer la vie privée des communications de manière Libre et ouverte même si ce n'est pas fait de manière parfaite.
Ton modèle est un Web of Trust avec une preuve de travail pour l'entrée initiale.
Le gros du problème se situe au niveau de l'entrée initiale. Il est trés difficile d'équilibrer un système de preuve de travail comme le fait Bitcoin. Quelqu'un disposant d'hardware spécifique ou de CG pourra sans peine Spammer un réseau car disposant d'une puissance de calcul des millions de fois supérieurs à celui d'un pauvre telephone portable.
Mais l'idée est innovante oui :)
Si tu autorise le serveur à lire/comprendre ce "token", tu ré-introduis le problème de traçabilité associé aux méta-données. Tu pourras toujours construire un graphe de contacts et de relations associés à ce dit "token".
Le système de priorité est aussi un problème pour le serveur :
Que faire des messages "low priorité" ? les stocker ? si c'est du spam, ça peut aisément prendre une place importante.
Donc tu veux une signature qui n'est pas une signature ? ça me semble un peu flou ça :)
Je prendrais plutôt le problème sous une autre approche :
Privilégier les connexion P2P autant que possible au lieu de passer par un serveur tiers, spécialement dans le cas d'une messagerie synchrone.
Autoriser un système de federation de serveurs non hiérarchique comme pour SMTP, XMPP ou SMS/MMS pour favoriser une administration distribuée des serveurs.
[^] # Re: ou pas
Posté par tuxicoman (site web personnel) . Évalué à 2.
Le P2P ca marche pas avec le réseau 3G qu'on nous propose sans IP publique pour chaque appareil. Il faut au moins un serveur de relai.
[^] # Re: ou pas
Posté par barmic . Évalué à 1.
Ouai parler comme ça c'est au minimum une volonté piéger les utilisateurs.
Les méta-données c'est des données, jouer sur les mots ça ne sert à rien. D'autant qu'on sait tous que les méta-données sont souvent presque aussi importante et aident vachement lors de la cryptanalyse donc au mieux plus tu laisse de méta-données plus tu affaiblie ton chiffrement (la connaissance de l'entrée et de la sortie (la fréquence de leur communication, leur localisation nationale etc permettent par exemple d'émettre des hypothèses au sujet du format de leur numéro).
C'est quoi la grosse différence si tu peux passer de l'un à l'autre en moins d'une semaine ? Le fait que d'autre font pire ne fait pas de cette solution une solution sécurisée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ou pas
Posté par Firwen (site web personnel) . Évalué à 1.
Si je te suis: Utiliser HTTPS ça sert à rien parce qu'en analysant le réseau, même avec TLS je vois que tu te connectes à ta banque ?
Les méta-données sont trés utiles pour connaitre les acteurs et leurs habitudes, mais elles ne suffisent pas à faire tomber un cryptage correcte ( AES, TwoFish, …) par cryptanalyse sur les données elle même, et fort heureusement j 'ai envie de dire
Non ce n'est pas jouer avec les mots, et oui c'est sécurisé car le contenu des conversations est sécurisé de manière correcte au lieu de se promener en clair sur le réseau SMS.
Et OUI, ça, c'est déja une belle evolution.
Le fait que tu peux passer de l'un à l'autre n’empêchera pas de voir ta liste de contactes sur pastebin.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.