Idée de protocole d'échange SMS anonyme

Bonjour tout le monde !

Il y a quelques jours, une idée m’est venue en tête pour permettre d’échanger des SMS de manière quasi-anonyme, et je serais curieux de savoir ce que vous en pensiez, ou si un projet dans ce genre a déjà été tenté. Je n’ai pas pour projet de la mettre en œuvre, mais je me demande si elle théoriquement possible. Voilà en gros ce que ça donne.

Situation de départ

Imaginons que Clem veut envoyer un message à Citron, elle écrit et envoie donc ZdS c'est la classe, tu peux pas zeste !. Maintenant, supposons que Saucisson cherche à surveiller Clem, il voit que celle-ci a envoyé à Citron le message ZdS c'est la classe, tu peux pas zeste ! le 27 mai à 15h. Il a donc à la fois le message, son expéditeur, son destinataire et le moment de son envoi.

Avec un chiffrement asymétrique

Imaginons maintenant que Clem et Citron possèdent toutes deux l’application Silence ou Signal, ou équivalent. Elles échangent leurs clés de chiffrement, puis Clem envoie le-dit message chiffré avec la clé publique de Citron. Saucisson voit alors que Clem a envoyé à Citron le message LnP4NSFHLRQRTBIPDlZUJlFZXduWSDJmTPwMqGxiCmdIEDaEsN le 27 mai à 15h. C’est beaucoup mieux pour la vie privée, mais il peut toujours voir qui est en relation avec qui, et quand.

Avec chiffrement asymétrique et centralisation

Voici donc mon idée. Imaginons qu’une tierce personne de confiance, disons Mangue, possède un serveur avec un abonnement télécom, qui peut recevoir et envoyer des SMS.

Clem et Orange utilisent une application similaire à Silence, mais avec quelques modifications. Elles vont tout d’abord envoyer leurs clés publiques respectives au serveur de Mangue, qui leur répondra en leur envoyant lui aussi sa clé publique. Dès lors, les communications entre Clem et Mangue et entre Citron et Mangue seront chiffrées.

Clem va demander au serveur de Mangue la clé publique de Citron et, à l’aide de celle-ci, va chiffrer l’empreinte de sa clé privée. Elle y indique aussi (mais en clair) qu’elle demande l’empreinte de Citron. Ce message va alors être envoyé au serveur de Mangue, qui attendra un message du même acabit de la part de Citron. Le serveur répondra alors aux demandes et enverra les empreintes (qui sont chiffrées) des correspondants à ceux qui les demandent. Chacun pourra alors déchiffrer ce message et vérifier que l’empreinte est la bonne, c’est-à-dire que Mangue a bien envoyé les clés publiques des correspondants et non la sienne (pour éviter une attaque du type "homme du milieu").

Clem va maintenant écrire un message pour Citron, qu’elle va chiffrer avec la clé publique de Citron (récupérée sur le serveur de Mangue). Le texte obtenu sera placé dans un message, mais précédé d’un autre en-tête contenant le destinataire, c’est-à-dire Citron. Ce message va alors être chiffré avec la clé publique de Mangue et va lui être envoyé. Une fois déchiffré, Mangue verra le message ci-dessus et verra que son destinataire est Citron. Il met alors ce message de côté et, une fois la minute en cours écoulée, il enverra tous les messages reçus à leurs destinataires. Les messages n’étant pas envoyés immédiatement après avoir été reçus, il devient plus complexe de "tracer" un message depuis l’entrée jusqu’à la sortie du serveur (chaque message arrive à un moment différent, mais tous repartent en même temps).

Une fois le message reçu de la part de Mangue, Citron déchiffre le message et peut alors lire ZdS c'est la classe, tu peux pas zeste !.

Si Saucisson surveille le réseau, tout ce qu’il peut voir est que Clem a envoyé un message illisible à Mangue le 27 mai à 15h00, et que Mangue a envoyé plusieurs messages illisibles à plusieurs personnes, dont Citron, à 15h01.

A priori, ce système aurait principalement quatre inconvénients / points de faiblesse :

• il faut plusieurs envois / réceptions de messages avant de pouvoir effectivement établir une communication ;
• les messages mettent plus de temps à arriver ;
• Clem et Citron doivent faire confiance à Mangue pour ne pas faire de surveillance relationnelle ;
• l’anonymat dépend principalement du nombre de personnes utilisant le serveur de Mangue : si 50 messages sont envoyés à 15h01, retracer lequel vient de qui et va à qui est bien plus complexe que si 5 seulement sont envoyés.

Voilà voilà, c’est encore assez fouillis et il y a surement quelques erreurs techniques de ma part (je suis très loin d’être un spécialiste en cryptographie). À votre avis, est-ce qu’un protocole comme celui-ci est technique envisageable, ou y-aurait-il des erreurs ou des problèmes bloquants ?

Merci pour vos idées et critiques, et bon week-end !

Non mais t’en fais pas Saucisson, on t’aime quand même !

Que faire si le serveur de Mangue tombe en rade ou est bloqué ?

Salut rezemika !

J’ai pas bien compris l’histoire de l’emprunte de la clé privée. Tu pars du principe que Clèm et Citron vont vérifié ensuite que l’emprunte correspond ?

Je trouve ça bizare car dans tous les cas, Mangue pourrait retourner l’emprunte de sa clé privée. Si elle a donné sa clé publique plutôt que celle de Citron (c’est donc un man[gue]-in-the-middle \o/), elle a plutôt intéret à donner l’emprunte de sa clé privé chiffré avec sa clé publique.

Mais sinon, oui ton système marche
Généralement on considère que Mangue est un intermédiaire de confiance et qu’il est au moins aussi sûr que les correspondants. À quelques détails près (la latence ajoutée pour anonymiser qui je pense n’est pas idéal), c’est un cryptosystème classique de clé asymétrique avec intermédiaire de confiance. Il y a d’autres problèmes comme au niveau de la disponibilité, le coût de service de Mangue (comme le signale qwerty).

Il faudrait également vérifié que Citron aie bien reçu le message !

Mais sinon, il y a aussi des avantages. Ici, on a la non-répudiation ! C’est à dire que de base en s’échangeant des messages, Citron peut dire à un moment, je lui ai posé cette question et Clèm à répondu ça ! Sauf que Clèm avait répondu ça pour une autre question. Avec ce système, on est assuré que ça n’arrivera pas. En mettant en place la vérification que Citron aie bien reçu le message on a même la non-répudiation de la destination.

Il y a tout pleins d’exemple de ce type dans le livre Applied Cryptography, pour moi c’est une référence.

Merci pour vos retours !

On l’aime bien, mais il a quand même enchainé Clem dans le chapitre 7. ;-(

En effet, c’est une nouvelle faille à rajouter. Je ne sais pas s’il y a un moyen de la contourner…

J’ai pas bien compris l’histoire de l’emprunte de la clé privée. Tu pars du principe que Clèm et Citron vont vérifié ensuite que l’emprunte correspond ?

Je trouve ça bizare car dans tous les cas, Mangue pourrait retourner l’emprunte de sa clé privée. Si elle a donné sa clé publique plutôt que celle de Citron (c’est donc un man[gue]-in-the-middle \o/), elle a plutôt intéret à donner l’emprunte de sa clé privé chiffré avec sa clé publique.

Ah en effet, bien vu. Du coup, il faudrait soit une confiance totale envers le tiers, soit une confirmation IRL de l’emprunte. :/

Merci pour le lien, je vais voir ça !

Edit : Par contre, je n’ai que de toutes petites bases en langage C, j’imagine que ce livre demande des connaissances solides sur le sujet ?

Absolument pas, les codes C sont en Annexes, je les ai jamais regardé x)

Ah d’accord, je vais tenter ma chance du coup.

Il me semble qu’il faut toujours une vérification irl. Le seul moyen qu’on a trouvé pour l’éviter, c’est le web of trust (si je ne me trompe pas, avec les serveurs de clefs), qui implique de déjà vérifier quelques clefs irl puis de les signer avant de leur faire confiance.

Plus ou moins

Si on ne lui fait pas confiance de toute façon, ça marche pas. Mais on peut toujours ne pas trop lui faire confiance en utilisant le principe du protocole à cliquet. C’est que théorique car dans le cas réelle on fait juste confiance à Mangue.

Dans l’idée, Clem envoie la première partie d’un message + le hash de l’ensemble du message (chiffré avec la sois-disans clé de Citron). Citron signal qu’il a bien reçu le message (soit disant clé de Clem). Clem envoye alors la deuxième partie du message (…).

Dans l’idée Mangue ne peut pas falcifié une moitié de message sans connaitre le contenu. Son mangue-in-the-middle est détectée.

Il y a toujours le risque que Mangue soit une attaquante très active (Malorie) et que non pas en écoute passive mais en modification active, les messages qu’elle envoie à Clem et à Citron n’ont rien à voir l’un envers l’autre. S’ils n’ont effectivement aucune communication l’un envers l’autre alors là, il est impossible (à ma connaissance) de détecter le mangue-in-the-middle.

Une sorte de réseau TOR pour SMS en résumé ?

Pas tout à fait, puisque les SMS ne passeraient que par un seul serveur, il n’y aurait pas de "routage en oignon" et il n’y aurait pas les avantages de la décentralisation.