Les deux serveurs XMPP (celui d'Alice et celui de Bob) savent qu'elles adresses XMPP parlent avec qui. Ça, c'est certain.
Cependant, les adresses XMPP dans Silence ne sont pas conçues pour être utilisées dans un autre contexte que dans Silence. Les adresses utilisées sont des UUID : pas de nom.prenom@, pas de 0612345678@. Utiliser un UUID (en fait, utiliser n'importe quoi de généré aléatoirement) permet d'éviter les risques de collision. En effet, si j'utilise la même adresse XMPP dans Silence qu'ailleurs, les risques de collisions sont grands et les attaques rendues moins difficiles.
En outre, aucune info de contacts n'est envoyée via XMPP : la découverte des utilisateurs utilisant Silence se base sur le carnet d'adresses local du téléphone et l'échange de l'adresse XMPP au moment de l'initialisation des sessions chiffrées.
Pour les MMS, c'est également possible en théorie dans Silence. Je suis néanmoins confronté à un problème technique. Historiquement, un message multimédia était échangé en initialisant une connexion directement de l'expéditeur vers le destinataire. Ensuite, le développeur de Conversations a travaillé sur un mécanisme similaire aux MMS, c'est-à-dire l'envoi du fichier multimédia sur un serveur distant, qui sera ensuite récupéré par le destinataire avec les jetons d'authentification transmis par l'expéditeur. Le gros avantage est que cela ne nécessite pas que les deux contacts soient connectés au moment de l'envoi du fichier. Ça, c'est la XEP-0363: HTTP File Upload. Prosody supporte cette XEP (je n'ai pas regardé les autres serveurs). Le problème, c'est que Smack, la bibliothèque utilisée dans Silence pour XMPP, ne supporte pas cette extension.
Pour ce qui est du support multi-appareils, il y a un blocage lié au fait que le numéro de téléphone reste le moyen d'identifier un contact et que l'envoi de SMS ne se fait que vers un seul appareil (Silence reste une application de SMS). C'est mille fois plus facile de ne transmettre qu'un numéro de téléphone plutôt qu'une adresse XMPP (qui plus est, générée aléatoirement). J'avais il y a quelques temps commencé à travailler sur une API REST pour gérer à distance les SMS/MMS du téléphone : un client quelconque peut ensuite se connecter au téléphone pour gérer les SMS/MMS à distance. Je n'ai jamais terminé cette fonctionnalité, et comme ce n'est pas une fonctionnalité si demandée que ça, je me suis concentré sur d'autres choses. L'idée de Silence est vraiment d'être un moyen de communication d'un téléphone vers un autre téléphone. Certes, c'est plus simple d'écrire un long SMS depuis son ordinateur, d'où l'idée de l'API REST.
L'intérêt des messages XMPP dans Silence est de proposer une solution de communication chiffrée sans laisser trop de traces en terme de méta-données. Silence est conçu pour remplacer l'application de SMS du téléphone : c'est pour cela que les SMS chiffrés ne seront jamais supprimés. Sauf qu'en proposant les messages XMPP en plus des SMS, cela permet aux utilisateurs d'avoir une interface unique pour communiquer de manière sécurisée. C'est beaucoup plus facile que d'avoir deux applications : il n'y a pas deux applications à paramétrer, pas besoin de s'occuper de l'adresse XMPP de son correspondant, etc. Dans Silence, lorsque 2 contacts s'échangent leurs clés publiques, les adresses XMPP sont également partagées et la bascule sur des messages XMPP se fera automatiquement lorsqu'il y aura un accès Internet. Et lorsqu'il n'y a pas d'accès Internet pour l'une des deux parties, Silence continuera d'utiliser les SMS (sauf demande explicite de l'utilisateur).
Il ne s'agit pas d'OMEMO, lequel repose sur PEP. L'implémentation dans Silence est vraiment très légère : le contenu chiffré est envoyé via XMPP au lieu d'être envoyé via SMS. Il n'y a pas non plus de reconnaissance via XMPP des contacts qui utilisent Silence : pour l'instant, la communication chiffrée via XMPP repose sur l'établissement préalable d'une session chiffrée via SMS (l'adresse XMPP est échangée au moment de l'échange des clés publiques).
À terme, l'idée est de pouvoir établir une session chiffrée via XMPP et de s'envoyer son numéro de téléphone en même temps que les clés. Mais ça, je m'en occuperai après. Le gros avantage est que cela permettra de développer un client iOS de Silence (sans chiffrement des SMS, certes), chose impossible avec uniquement du chiffrement de SMS puisqu'iOS interdit à une application tierce de gérer les SMS du téléphone.
À la demande du développeur principal de TextSecure, SecuredText a été renommé en SMSSecure (si les modérateurs pouvaient mettre à jour la dépêche, ça serait gentil).
Il est assez surprenant de voir mis en avant cet arrêt alors qu'un autre, bien plus important, est passé sous silence. La Première chambre civile rendait le 5 février un arrêt qui concerne la suite de l'affaire Pétrus c/ Lenovo, que l'AFUL suivait attentivement. Pourtant, dans cet arrêt, les juges disent clairement deux choses :
- on ne peut dire qu'un ordinateur est inexploitable sans ses logiciels (bon point pour la suite)
- mais le fait d'acheter un ordinateur avec des logiciels pré-installés est assimilable à une acceptation de la vente liée
C'est sur ce dernier point que l'AFUL a perdu. Certes, cette décision est très contestable : les juges disent en filigrane qu'il faut que le consommateur n'achète pas son ordinateur et assigne le constructeur pour pratique commerciale déloyale ; à partir du moment où il y a achat, le consommateur, pour le droit, accepte la vente des autres logiciels. Cela est contre-productif, nous sommes d'accord.
L'arrêt du 24 janvier dernier tant mis en avant par l'AFUL est clairement inintéressant. Il se borne à sanctionner une erreur de droit sur l'appréciation d'une directive européenne. Il ne sanctionne absolument pas la vente liée. On remarquera que, contrairement à celui du 5 février, l'arrêt du 24 janvier n'est pas publié au Bulletin de la Cour de cassation, ce qui signifie qu'il ne s'agit que d'un arrêt d'espèce dont les juges n'entendent pas lui donner de portée juridique.
Il est fort à parier que l'affaire Guerby c/ Darty va donner lieu à la même solution que l'arrêt du 5 février. Dans l'affaire Pétrus c/ Lénovo, en 2010, la Cour de cassation sanctionnait une erreur de droit par les juges du fond, mais pas la vente liée, et elle est ensuite venue mettre un coup de grâce aux pourfendeurs de la vente liée dans le domaine de l'informatique grand public. Dans l'affaire Guerby c/ Darty, suite à la cassation du 24 janvier, les juges du fond vont probablement suivre l'avis de la Cour de cassation ; s'il y a pourvoi, la solution sera à mon avis la même dans l'affaire Pétrus c/ Lénovo parce que M. Guerby a acheté son ordinateur en sachant qu'il y avait des logiciels pré-installés. Le seul espoir permis est que dans le cas de M. Guerby, ce dernier a prévenu qu'il ne voulait pas de ces logiciels : c'est une différence avec le cas Pétrus qui peut éventuellement changer les choses, mais j'en doute tout de même très fortement.
[^] # Re: iOS
Posté par BastienLQ . En réponse à la dépêche Silence : XMPP, chiffrement et méta‐données. Évalué à 3.
iOS n'autorise pas une application tierce à gérer les SMS/MMS. Porter Silence actuellement est donc impossible. En revanche, avec XMPP, il sera possible à terme de porter une version sans le chiffrement des SMS sur iOS : https://linuxfr.org/news/silence-xmpp-chiffrement-et-meta-donnees#comment-1685277
[^] # Re: My 2 cents
Posté par BastienLQ . En réponse à la dépêche Silence : XMPP, chiffrement et méta‐données. Évalué à 2.
Les deux serveurs XMPP (celui d'Alice et celui de Bob) savent qu'elles adresses XMPP parlent avec qui. Ça, c'est certain.
Cependant, les adresses XMPP dans Silence ne sont pas conçues pour être utilisées dans un autre contexte que dans Silence. Les adresses utilisées sont des UUID : pas de nom.prenom@, pas de 0612345678@. Utiliser un UUID (en fait, utiliser n'importe quoi de généré aléatoirement) permet d'éviter les risques de collision. En effet, si j'utilise la même adresse XMPP dans Silence qu'ailleurs, les risques de collisions sont grands et les attaques rendues moins difficiles.
En outre, aucune info de contacts n'est envoyée via XMPP : la découverte des utilisateurs utilisant Silence se base sur le carnet d'adresses local du téléphone et l'échange de l'adresse XMPP au moment de l'initialisation des sessions chiffrées.
Pour les MMS, c'est également possible en théorie dans Silence. Je suis néanmoins confronté à un problème technique. Historiquement, un message multimédia était échangé en initialisant une connexion directement de l'expéditeur vers le destinataire. Ensuite, le développeur de Conversations a travaillé sur un mécanisme similaire aux MMS, c'est-à-dire l'envoi du fichier multimédia sur un serveur distant, qui sera ensuite récupéré par le destinataire avec les jetons d'authentification transmis par l'expéditeur. Le gros avantage est que cela ne nécessite pas que les deux contacts soient connectés au moment de l'envoi du fichier. Ça, c'est la XEP-0363: HTTP File Upload. Prosody supporte cette XEP (je n'ai pas regardé les autres serveurs). Le problème, c'est que Smack, la bibliothèque utilisée dans Silence pour XMPP, ne supporte pas cette extension.
Pour ce qui est du support multi-appareils, il y a un blocage lié au fait que le numéro de téléphone reste le moyen d'identifier un contact et que l'envoi de SMS ne se fait que vers un seul appareil (Silence reste une application de SMS). C'est mille fois plus facile de ne transmettre qu'un numéro de téléphone plutôt qu'une adresse XMPP (qui plus est, générée aléatoirement). J'avais il y a quelques temps commencé à travailler sur une API REST pour gérer à distance les SMS/MMS du téléphone : un client quelconque peut ensuite se connecter au téléphone pour gérer les SMS/MMS à distance. Je n'ai jamais terminé cette fonctionnalité, et comme ce n'est pas une fonctionnalité si demandée que ça, je me suis concentré sur d'autres choses. L'idée de Silence est vraiment d'être un moyen de communication d'un téléphone vers un autre téléphone. Certes, c'est plus simple d'écrire un long SMS depuis son ordinateur, d'où l'idée de l'API REST.
[^] # Re: cli
Posté par BastienLQ . En réponse à la dépêche Silence : XMPP, chiffrement et méta‐données. Évalué à 6.
L'intérêt des messages XMPP dans Silence est de proposer une solution de communication chiffrée sans laisser trop de traces en terme de méta-données. Silence est conçu pour remplacer l'application de SMS du téléphone : c'est pour cela que les SMS chiffrés ne seront jamais supprimés. Sauf qu'en proposant les messages XMPP en plus des SMS, cela permet aux utilisateurs d'avoir une interface unique pour communiquer de manière sécurisée. C'est beaucoup plus facile que d'avoir deux applications : il n'y a pas deux applications à paramétrer, pas besoin de s'occuper de l'adresse XMPP de son correspondant, etc. Dans Silence, lorsque 2 contacts s'échangent leurs clés publiques, les adresses XMPP sont également partagées et la bascule sur des messages XMPP se fera automatiquement lorsqu'il y aura un accès Internet. Et lorsqu'il n'y a pas d'accès Internet pour l'une des deux parties, Silence continuera d'utiliser les SMS (sauf demande explicite de l'utilisateur).
[^] # Re: Fédération ?
Posté par BastienLQ . En réponse à la dépêche Silence : XMPP, chiffrement et méta‐données. Évalué à 4.
Il ne s'agit pas d'OMEMO, lequel repose sur PEP. L'implémentation dans Silence est vraiment très légère : le contenu chiffré est envoyé via XMPP au lieu d'être envoyé via SMS. Il n'y a pas non plus de reconnaissance via XMPP des contacts qui utilisent Silence : pour l'instant, la communication chiffrée via XMPP repose sur l'établissement préalable d'une session chiffrée via SMS (l'adresse XMPP est échangée au moment de l'échange des clés publiques).
À terme, l'idée est de pouvoir établir une session chiffrée via XMPP et de s'envoyer son numéro de téléphone en même temps que les clés. Mais ça, je m'en occuperai après. Le gros avantage est que cela permettra de développer un client iOS de Silence (sans chiffrement des SMS, certes), chose impossible avec uniquement du chiffrement de SMS puisqu'iOS interdit à une application tierce de gérer les SMS du téléphone.
[^] # Re: Changement de nom
Posté par BastienLQ . En réponse à la dépêche SMSSecure : les SMS et MMS chiffrés sur Android, ce n'est pas fini !. Évalué à -1. Dernière modification le 22 mars 2015 à 23:43.
(à supprimer)
# Changement de nom
Posté par BastienLQ . En réponse à la dépêche SMSSecure : les SMS et MMS chiffrés sur Android, ce n'est pas fini !. Évalué à 6.
À la demande du développeur principal de TextSecure, SecuredText a été renommé en SMSSecure (si les modérateurs pouvaient mettre à jour la dépêche, ça serait gentil).
# Malheureusement, l'AFUL n'a pas gagné
Posté par BastienLQ . En réponse à la dépêche Beaucoup d'actu chez Racketiciels. Évalué à 6.
Il est assez surprenant de voir mis en avant cet arrêt alors qu'un autre, bien plus important, est passé sous silence. La Première chambre civile rendait le 5 février un arrêt qui concerne la suite de l'affaire Pétrus c/ Lenovo, que l'AFUL suivait attentivement. Pourtant, dans cet arrêt, les juges disent clairement deux choses :
- on ne peut dire qu'un ordinateur est inexploitable sans ses logiciels (bon point pour la suite)
- mais le fait d'acheter un ordinateur avec des logiciels pré-installés est assimilable à une acceptation de la vente liée
C'est sur ce dernier point que l'AFUL a perdu. Certes, cette décision est très contestable : les juges disent en filigrane qu'il faut que le consommateur n'achète pas son ordinateur et assigne le constructeur pour pratique commerciale déloyale ; à partir du moment où il y a achat, le consommateur, pour le droit, accepte la vente des autres logiciels. Cela est contre-productif, nous sommes d'accord.
L'arrêt du 24 janvier dernier tant mis en avant par l'AFUL est clairement inintéressant. Il se borne à sanctionner une erreur de droit sur l'appréciation d'une directive européenne. Il ne sanctionne absolument pas la vente liée. On remarquera que, contrairement à celui du 5 février, l'arrêt du 24 janvier n'est pas publié au Bulletin de la Cour de cassation, ce qui signifie qu'il ne s'agit que d'un arrêt d'espèce dont les juges n'entendent pas lui donner de portée juridique.
Il est fort à parier que l'affaire Guerby c/ Darty va donner lieu à la même solution que l'arrêt du 5 février. Dans l'affaire Pétrus c/ Lénovo, en 2010, la Cour de cassation sanctionnait une erreur de droit par les juges du fond, mais pas la vente liée, et elle est ensuite venue mettre un coup de grâce aux pourfendeurs de la vente liée dans le domaine de l'informatique grand public. Dans l'affaire Guerby c/ Darty, suite à la cassation du 24 janvier, les juges du fond vont probablement suivre l'avis de la Cour de cassation ; s'il y a pourvoi, la solution sera à mon avis la même dans l'affaire Pétrus c/ Lénovo parce que M. Guerby a acheté son ordinateur en sachant qu'il y avait des logiciels pré-installés. Le seul espoir permis est que dans le cas de M. Guerby, ce dernier a prévenu qu'il ne voulait pas de ces logiciels : c'est une différence avec le cas Pétrus qui peut éventuellement changer les choses, mais j'en doute tout de même très fortement.
L'arrêt Civ. 1ère 5 février 2014 : http://www.courdecassation.fr/jurisprudence_2/premiere_chambre_civile_568/117_5_28418.html