TextSecure va gérer le chiffrement des SMS dans CyanogenMod

Rep à ça, Google

Le 11 décembre 2013 à 08h48

3 min

Société numérique

Société

La sécurité est au centre des préoccupations de tout le monde, alors que le scandale Prism continue de se dévoiler un peu plus chaque jour et que le fameux article 13 de la Loi de Programmation Militaire vient d'être adopté par le sénat. CyanogenMod ne fait pas exception et indique qu'il intègrera nativement un outil de chiffrement des SMS : TextSecure.

Si le chiffrement de tous types de communications n'a rien de nouveau, l'éclatement du scandale Prism a donné naissance à une curiosité plus grande de la part d'un public plus large que ceux qui sont taxés d'être les paranos de service. Et avec l'émergence d'une demande plus importante sur ces problématiques, on voit de nombreux acteurs du numérique chercher à proposer une solution.

Le chiffrement des échanges est à la mode : CyanogenMod veut le généraliser

Du côté de Cyanogenmod, qui publie des ROM alternatives pour des centaines d'appareils sous Android, cela passera par l'intégration de TextSecure comme outil de chiffrement des SMS. Celle-ci n'a rien de nouveau, mais a l'avantage d'être open source puisque son code est diffusé sur GitHub par WhisperSystems, qui édite aussi Red Phone (un outil de VoIP chiffré).

Son implémentation a CyanogenMod a demandé un travail spécifique, chapeauté par Moxie Marlinspike qui est justement Lead Engineer pour la société qui a déjà tenu plusieurs conférences lors de la DEFCON, comme ce fût le cas en 2011 autour du sujet « SSL et le future de l'authenticité » (entre autres) :

TextSecure utilisé comme protocole, pas comme application

Quoi qu'il en soit, l'intégration de TextSecure est plus profonde que l'on ne pourrait le penser et l'outil pourra au final s'interfacer avec n'importe quelle autre application de gestion des SMS. Si vous envoyez un message à un autre utilisateur de CyanogenMod ou TextSecure, le chiffrement sera automatique. Sinon, il sera envoyé en clair. Pour l'utilisateur tout sera transparent. Des indicateurs vont néanmoins être rajoutés à terme afin d'indiquer si le chiffrement sera activé ou non en fonction du destinataire.

Pour le moment, cette intégration prend place dans la version Nightly de CM 10.2 afin de vérifier que tout se passe bien, et que la charge des serveurs de n'est pas trop forte. Si tout se passe comme prévu, cela sera étendu à CM 11. Les adeptes du chiffrement et de l'open source pourront bien entendu retrouver le code de Whisper Push et TextSecure server qui ont servi de base au projet.

Pour rappel, un client iOS est actuellement en cours de finition et devrait arriver d'ici quelques semaines ainsi qu'une extension dédiée aux navigateurs. L'équipe souhaite ainsi propose au final une plateforme complète de communication multiplateforme, un peu comme le fait CryptoCat de son côté en misant plutôt sur la messagerie instantanée. L'intégration à Cyanogen devrait lui permettre de se placer sous le feu des projecteurs et de gagner une large base d'utilisateur, un point important alors que les initiatives se multiplient, et qui prendra tout son sens au moment où les utilisateurs devront choisir quelle solution utiliser au quotidien.

Commentaires (57)

Minikea

Le 11/12/2013 à 08h54

j’ai pas été voir la techno, mais concrètement, comment fait un protocole pour savoir à priori si le destinataire possède aussi le logiciel pour déchiffrer les messages?

knos

Le 11/12/2013 à 08h58

geekounet85 a écrit :

j’ai pas été voir la techno, mais concrètement, comment fait un protocole pour savoir à priori si le destinataire possède aussi le logiciel pour déchiffrer les messages?

Surement avec une liste des téléphones qui on l’application. Si ton num est dans la liste ça crypte sinon non.

Strimy

Le 11/12/2013 à 10h21

NarOneR a écrit :

Je comprend pas pourquoi ils ont besoin d’un serveur.

Si les choses sont bien faites chacun génère une clé et chiffre/déchiffre localement.

Le chiffrement et déchiffrement sont bien fait localement.

Le problème se pose pour l’échange des clés qui ne peut pas être fait en direct. Et vu qu’ils changent de clés à chaque messages, il faudrait qu’aussi bien l’émetteur et le récepteur soit actif pour pouvoir s’échanger des messages.

Le serveur sert donc de cache de clés publiques pré-générées pour éviter l’attente.

NarOneR

Le 11/12/2013 à 10h34

Strimy a écrit :

Le chiffrement et déchiffrement sont bien fait localement.

Le problème se pose pour l’échange des clés qui ne peut pas être fait en direct. Et vu qu’ils changent de clés à chaque messages, il faudrait qu’aussi bien l’émetteur et le récepteur soit actif pour pouvoir s’échanger des messages.

Le serveur sert donc de cache de clés publiques pré-générées pour éviter l’attente.

Du coup il fait être obligatoirement connecter au web non ?

Strimy

Le 11/12/2013 à 10h40

NarOneR a écrit :

Du coup il fait être obligatoirement connecter au web non ?

Je pense que oui… A moins que l’émetteur puisse récupérer le pool de clés du destinataire et travailler en local tant qu’il en a sa disposition (ce qui me parait pas évident si la clé est à utilisation unique et accessible par plusieurs utilisateurs).

CryoGen

Le 11/12/2013 à 10h44

NarOneR a écrit :

Du coup il fait être obligatoirement connecter au web non ?

Strimy a écrit :

Je pense que oui… A moins que l’émetteur puisse récupérer le pool de clés du destinataire et travailler en local tant qu’il en a sa disposition (ce qui me parait pas évident si la clé est à utilisation unique et accessible par plusieurs utilisateurs).

D’après ce que j’ai compris il faut être connecté oui. Si tu ne l’es pas (portable éteint, pas de réception, etc.) le serveur attend ton retour pour te l’envoyer en push. Mais le serveur en lui même ne saurai décoder le message.

flagos_

Le 11/12/2013 à 10h48

NarOneR a écrit :

Du coup il fait être obligatoirement connecter au web non ?

Après on peut espérer un cache sur les échanges de cles. Si tu as deja échangé tes clés avec ton destinataire, a priori pas besoin de les repasser et donc on peut se passer de connection au web.

Carisious

Le 11/12/2013 à 10h48

J’ai pas regardé le cas précis de Cyanogen, mais je vois pas pourquoi ils n’utiliseraient pas un truc de type OTR (disponible depuis déjà pas mal de temps par exemple dans Pidgin et Jitsi):

Wikipedia https://otr.cypherpunks.ca

NarOneR

Le 11/12/2013 à 10h50

flagos_ a écrit :

Après on peut espérer un cache sur les échanges de cles. Si tu as deja échangé tes clés avec ton destinataire, a priori pas besoin de les repasser et donc on peut se passer de connection au web.

Hum je e sais pas à qu’elle rythme les clés sont renouveler mais faire du catching sur des clés ça doit être limitée.

Strimy

Le 11/12/2013 à 10h56

Carisious a écrit :

J’ai pas regardé le cas précis de Cyanogen, mais je vois pas pourquoi ils n’utiliseraient pas un truc de type OTR (disponible depuis déjà pas mal de temps par exemple dans Pidgin et Jitsi):

Wikipedia https://otr.cypherpunks.ca

“OTR was designed for synchronous transports. It works well for desktop IM clients, but is not well tailored for the mobile environment, where a number of factors such as the OS process model, battery constraints, and network conditions have conspired to make mobile messaging systems asynchronous.”

Urgente-Fraxinelle-unitaire

Le 11/12/2013 à 11h59

Presteus a écrit :

Et toi, plutôt que d’attaquer gratuitement les interlocuteurs, cela te semblerait digne de partager tes connaissances ? " />

Quelles connaissances ?

DorianM

Le 11/12/2013 à 12h42

frikakwa a écrit :

Ah ben oui c’est exactement comme iMessage: il suffit d’avoir iMessage INstallé sur son iPhone, son Android phone ou son Win Phone et c’est exactement pareil! " />

Je parle bien entendu du principe… le fait que iMessage soit uniquement dispo sur iOS (et OS X) n’empêche pas qu’il utilise ce mode de fonctionnement depuis des années.

Minikea

Le 11/12/2013 à 12h50

DorianMonnier a écrit :

Je parle bien entendu du principe… le fait que iMessage soit uniquement dispo sur iOS (et OS X) n’empêche pas qu’il utilise ce mode de fonctionnement depuis des années.

heureusement que c’est open-source et qu’on a pu le forker et faire une version pour Android! " />

ou pas?

sous-entendu : c’est quand même plus simple de réutiliser un “principe” quand on a les sources plutôt que de devoir ré-inventer la roue.

frikakwa

Le 11/12/2013 à 13h32

geekounet85 a écrit :

heureusement que c’est open-source et qu’on a pu le forker et faire une version pour Android! " />

ou pas?

sous-entendu : c’est quand même plus simple de réutiliser un “principe” quand on a les sources plutôt que de devoir ré-inventer la roue.

Je pensais avoir été clair assez… apparemment j’ai été trop “subtil”! " />

Carisious

Le 11/12/2013 à 13h33

Strimy a écrit :

“OTR was designed for synchronous transports. It works well for desktop IM clients, but is not well tailored for the mobile environment, where a number of factors such as the OS process model, battery constraints, and network conditions have conspired to make mobile messaging systems asynchronous.”

Je ne sais pas quand ce petit paragraphe a été rédigé, mais dans le monde moderne on s’oriente quand même vers de plus en plus de forfaits avec data, et des terminaux y étant +/- toujours connectés. BlackBerry Messenger fonctionne sur ce principe, et ça ne semble pas avoir été un gros obstacle pour eux. Même si à titre personnel je suis le premier à n’activer la data que quand j’en ai besoin, je crois pas que ce soit le cas de la majorité des gens.

Sinon pour m’être amusé à observer ce que donne un échange OTR vu de Facebook (ça peut être utilisé pour le chat Facebook, et ensuite ça laisse traîner l’intégralité de l’échange dans la messagerie), c’est vraiment pas gourmand en traffic, il n’est pas nécessaire d’avoir un échange véritablement en temps réel, et des pauses mêmes longues dans la discussion une fois l’échange de clés réalisée ne sont pas un problème non plus. En gros, je pense que ça pourrait même passer, après quelques petits bricolages, par SMS classique si les développeurs s’en donnaient la peine. (évidemment il faudrait un système de type liste blanche pour que l’utilisateur ne réponde pas systématiquement à toute initialisation de chat OTR)

zeguigui

Le 11/12/2013 à 13h33

ça protège le contenu du message, OK, mais les métadonnées… bof. Le point intéressant c’est surtout que c’est une couche bas niveau pour l’utilisateur et donc ça ajoute le cryptage dès que possible et ça c’est bien !

L4igleNo1r

Le 11/12/2013 à 13h44

C’est bien comme initiative mais en même temps, vue le nombre d’application qui demande l’accès au SMS dans les permissions alors qu’elles en ont absolument pas besoin, il y a peut de chance que utilisateur normale garde ses sms secret.

Strimy

Le 11/12/2013 à 13h53

Carisious a écrit :

Je ne sais pas quand ce petit paragraphe a été rédigé, mais dans le monde moderne on s’oriente quand même vers de plus en plus de forfaits avec data, et des terminaux y étant +/- toujours connectés. BlackBerry Messenger fonctionne sur ce principe, et ça ne semble pas avoir été un gros obstacle pour eux. Même si à titre personnel je suis le premier à n’activer la data que quand j’en ai besoin, je crois pas que ce soit le cas de la majorité des gens.

Sinon pour m’être amusé à observer ce que donne un échange OTR vu de Facebook (ça peut être utilisé pour le chat Facebook, et ensuite ça laisse traîner l’intégralité de l’échange dans la messagerie), c’est vraiment pas gourmand en traffic, il n’est pas nécessaire d’avoir un échange véritablement en temps réel, et des pauses mêmes longues dans la discussion une fois l’échange de clés réalisée ne sont pas un problème non plus. En gros, je pense que ça pourrait même passer, après quelques petits bricolages, par SMS classique si les développeurs s’en donnaient la peine. (évidemment il faudrait un système de type liste blanche pour que l’utilisateur ne réponde pas systématiquement à toute initialisation de chat OTR)

Pour pouvoir envoyer un message à quelqu’un en OTR, il faut que l’autre en fasse soit aussi connecté pour effectuer l’échange de clés immédiatement. Ce n’est pas possible sur un mobile où les applications ne peuvent pas écouter le réseau en permanence. Seul un système de push peut notifier le téléphone tout en restant relativement limité.

Blackberry fonctionne par des serveurs, comme le fait TextSecure au final, et encore, on peut supposer que dans le cas de Blackberry, la transmission n’est sécurisée qu’entre le téléphone et les serveurs, et non entre les deux téléphones.

Carisious

Le 11/12/2013 à 14h51

Strimy a écrit :

Pour pouvoir envoyer un message à quelqu’un en OTR, il faut que l’autre en fasse soit aussi connecté pour effectuer l’échange de clés immédiatement. Ce n’est pas possible sur un mobile où les applications ne peuvent pas écouter le réseau en permanence. Seul un système de push peut notifier le téléphone tout en restant relativement limité.

Les SMS sont réceptionnés +/- en temps réel donc pourraient être utilisés pour ça.

Je ne vois vraiment pas en quoi l’échange de clés doit absolument être instantanné à partir du moment où l’on accepte soit d’attendre qu’il soit réalisé pour transmettre le message soit d’envoyer les premiers messages (avant échange) non chiffrés. On peut par ailleurs imaginer un système qui ne renégocierait les clés par exemple qu’une fois par jour, afin de ne pas entraîner des échanges de clés intempestifs peu utiles.

Strimy a écrit :

Blackberry fonctionne par des serveurs, comme le fait TextSecure au final, et encore, on peut supposer que dans le cas de Blackberry, la transmission n’est sécurisée qu’entre le téléphone et les serveurs, et non entre les deux téléphones.

La seule raison pour laquelle je citais BBM est pour souligner que leur système fonctionne sur la data sans que cela soit rédibitoire pour leurs utilisateurs. Après oui, il s’agit d’un système très centralisé il me semble.

lincruste_2_la vengeance

Le 11/12/2013 à 15h51

geekounet85 a écrit :

j’ai pas été voir la techno, mais concrètement, comment fait un protocole pour savoir à priori si le destinataire possède aussi le logiciel pour déchiffrer les messages?

Aucune idée non plus, mais quand tu flashes ton téléphone et que tu réinstalles l’application t’as pas intérêt à oublier de refaire un échange des clés sinon tu vas envoyer de la merde à tes destinataires. Pareil si le destinataire en question désinstalle l’application de son côté.

ggllk

Le 12/12/2013 à 08h32

Il y a pas mal d’applications similaires qui présentent l’avantage d’etre deja multi-plateformes, par exemple: myEnigma. Qui fait SMS, chats et transfert de fichiers.

16ar

Le 12/12/2013 à 16h47

Bon pour répondre à toutes les questions en cours avec plein d’affirmations sans connaissances. Pour la partie TextSecure seule :

* le client fonctionne en SMS, la partie avec push data n’est pas encore disponible, mais devrait bientôt arriver.

* Les clés de chiffrement des messages sont sur le téléphone, et chacun peut vérifier le fingerprint de sa session avec son interlocuteur.

* Actuellement, le système fonctionne avec des demandes de création de session à la sauce Diffie-Helmann, si la personne en face n’a pas de TextSecure, elle recevra un SMS illisible (plein de caractère ascii illisibles)

* Le système fonctionne plutôt très bien, je l’utilise avec toute ma famille. J’ai initialisé les sessions avec tout le monde et vérifié le fingerprint. Depuis, tout a été chiffré sans soucis.

* OTR ne peut pas s’adapter car le téléphone est principalement asynchrone, d’où le blog post :https://whispersystems.org/blog/advanced-ratcheting/ qui propose une alternative plus viable que l’idée de la DarkMail alliance qui ne peut pas vraiment fonctionner sur mobile sans bouffer toute la batterie.

pour TextSecure sur Cyanogenmod, de ce que j’en comprend, c’est principalement placer tout le fonctionnement bas niveau de TextSecure au niveau de la couche de reception/envoi de SMS. C’est à dire que même l’application wallpaper voleuse de SMS passera par cette couche.

Sur l’application TextSecure, par contre, la base de données des SMS est chiffrée par un mot de passe (possible de mettre en cache, pas besoin de dévérouiller à chaque sortie de veille du téléphone). Du coup, une application voleuse de sms ne pourra vraiment pas voler les SMS car ils ne sont plus là où ils sont censés être.

Tous ceux qui critiquent sans comprendre feraient bien de lire les blogpost sur le site de l’éditeur, l’auteur répond à toutes les questions en général et vous apprendrez pleins de choses.

Cet auteur est un bon ennemi de la NSA et autre, ils se fait emmer à chaque fois qu’il prend l’avion quelque part. C’est un white hat connu pour avoir trouvé des failles dans beaucoup de protocoles (notamment le protocole de “protection” wifi d’entreprise ms-chap, du crack de ssl, etc). Ça ne garantit pas qu’il ne soit pas passé à l’ennemi, mais en attendant ses sources sont là et on peut vérifier par nous-même.

Et pour ceux qui disent que iMessage c’est pareil, d’une, on n’a pas les sources, de 2, je suis intimement persuadé que le chiffrement de iMessage n’est que entre l’iPhone et le serveur apple, mais que le contenu n’est pas chiffré de point à point comme le sont TextSecure, OTR (cryptocat, jitsi, gajim, …), PGP ou S/MIME.

Minikea

Le 13/12/2013 à 08h38

16ar a écrit :

…

du coup, on peut quand même dialoguer avec une personne sans TextSecure depuis un téléphone avec la dernière Cyanogen, mais la personne en face recevra un SMS en plus illisible, c’est ça?

Donc ma réflexion sur les SMS illimités était pas si bête que ça!

16ar

Le 13/12/2013 à 14h05

doublon

16ar

Le 13/12/2013 à 14h09

geekounet85 a écrit :

du coup, on peut quand même dialoguer avec une personne sans TextSecure depuis un téléphone avec la dernière Cyanogen, mais la personne en face recevra un SMS en plus illisible, c’est ça?

Donc ma réflexion sur les SMS illimités était pas si bête que ça!

geekounet85 a écrit :

du coup, on peut quand même dialoguer avec une personne sans TextSecure depuis un téléphone avec la dernière Cyanogen, mais la personne en face recevra un SMS en plus illisible, c’est ça?

Donc ma réflexion sur les SMS illimités était pas si bête que ça!

Non, par défaut, je pense que le sms sera non-chiffré, sauf si il arrive a déterminer par les serveurs de cyanogenmod que l’utilisateur en face à textsecure et/ou cyanogenmod.

Il y a toute une discussion à ce sujet sur le blogpost de whispersys à propos de l’entropie des hash de numéro de téléphone dans les serveurs cyanogenmod/textsecure. Ils ont fait ce qui était techniquement le mieux possible pour conserver l’anonymat des données, mais ce n’est pas parfait. (si ça l’était, ni madame michu, ni même l’informaticien moyen pourrait utiliser TextSecure, la gestion de clé de chiffrement et d’identité étant bien trop complexe pour la personne lambda). Évidemment, l’équipe TextSecure est ouverte à toutes idées pour améliorer le système possible, sachant que pour le moment, beaucoup de réflexion a déjà été fait à ce sujet, mais il pourrait y avoir des axes d’améliorations non explorés.

Concernant les sms illimité, en effet, le surcoût de chiffrement fait passer un SMS de 160 caractère à 60 pour le premier, et 114 pour les suivants. Mais je pense qu’il est plus simple et moins cher d’avoir un forfait sms illimité que data plus conséquent, en tout cas dans beaucoup de pays j’imagine.

Urgente-Fraxinelle-unitaire

Le 11/12/2013 à 09h34

geekounet85 a écrit :

donc c’est centralisé et c’est sans doute le serveur (localisé pourquoi pas aux US, pour faciliter les choses) qui gère les paires de clefs, j’imagine. quelle solution sécurisante, en effet!

Faudrait peut-être se renseigner avant de raconter n’importe quoi.

DorianM

Le 11/12/2013 à 09h39

Le mode opératoire est en fait exactement le même que iMessage sur iOS depuis depuis des années non ?

Deux utilisateurs d’iMessage communiquent avec iMessage (et c’est chiffré), si l’un des deux ne l’ulitise pas, c’est du SMS. Pas franchement révolutionnaire quoi…

CryoGen

Le 11/12/2013 à 09h42

DE l’info (en english) ici : Blog Whispersystems: Asynchronous Security

Le serveur génère des clés mais seul les destinataires ont tous les éléments pour chiffrer/déchiffrer les messages.

Minikea

Le 11/12/2013 à 09h48

CryoGen a écrit :

DE l’info (en english) ici : Blog Whispersystems: Asynchronous Security

Le serveur génère des clés mais seul les destinataires ont tous les éléments pour chiffrer/déchiffrer les messages.

une autre source d’infos:https://whispersystems.org/blog/cyanogen-integration/

mistigrite a écrit :

Faudrait peut-être se renseigner avant de raconter n’importe quoi.

je fais avec ce que je trouve, et l’article ne donne pas toutes les infos… et pour moi, GitHub est loin d’être une source claire, même si c’est la plus fiable.

trash54

Le 11/12/2013 à 09h57

Ingénieur informaticien a écrit :

Oui ça serait bien d’avoir des infos sur le fonctionnement exact.

Comment ce système gère le problème du “man in the middle” au juste ?

Est-ce juste du pur marketing ou quoi ?

vague PRISM Art13 … avec truc genre “avec CM vos SMS sont secur”

car sinon intérêt pour le quidam du coin euh …. zéro à part faire le quiquiestlemieuxsecur

frikakwa

Le 11/12/2013 à 09h59

DorianMonnier a écrit :

Le mode opératoire est en fait exactement le même que iMessage sur iOS depuis depuis des années non ?

Deux utilisateurs d’iMessage communiquent avec iMessage (et c’est chiffré), si l’un des deux ne l’ulitise pas, c’est du SMS. Pas franchement révolutionnaire quoi…

Ah ben oui c’est exactement comme iMessage: il suffit d’avoir iMessage INstallé sur son iPhone, son Android phone ou son Win Phone et c’est exactement pareil! " />

Minikea

Le 11/12/2013 à 10h00

autre chose : les commentaires du blog de CM indiquent que la clé est générée localement, ce qui est apparemment partiellement vrai puisque le serveur génère une pré-clé.

si le serveur possède une partie de la solution pour déchiffrer le message, ce sera forcément un maillon attaquable facilement par la NSA, surtout si ce serveur est aux USA.

Autre question : peut-on faire son propre serveur et l’utiliser facilement sans avoir à refaire un APK spécifique?

Minikea

Le 11/12/2013 à 10h02

trash54 a écrit :

vague PRISM Art13 … avec truc genre “avec CM vos SMS sont secur”

car sinon intérêt pour le quidam du coin euh …. zéro à part faire le quiquiestlemieuxsecur

PRISM sans doute, Art13 je pense que CM s’en tamponne l’oreille avec une babouche des débats parlementaires français…

CryoGen

Le 11/12/2013 à 10h07

geekounet85 a écrit :

autre chose : les commentaires du blog de CM indiquent que la clé est générée localement, ce qui est apparemment partiellement vrai puisque le serveur génère une pré-clé.

si le serveur possède une partie de la solution pour déchiffrer le message, ce sera forcément un maillon attaquable facilement par la NSA, surtout si ce serveur est aux USA.

Autre question : peut-on faire son propre serveur et l’utiliser facilement sans avoir à refaire un APK spécifique?

Je ne suis pas sur que la prekey représente une faille. A priori les clés changent à chaque message par la suite (clé éphémère)

Minikea

Le 11/12/2013 à 10h09

CryoGen a écrit :

Je ne suis pas sur que la prekey représente une faille. A priori les clés changent à chaque message par la suite (clé éphémère)

OK, " />

du coup, il faut un forfait avec SMS illimités car je suppose que les échanges transparents se font via des sms non visibles, non?

enfin, je râle mais ça reste une très bonne initiative! " />

et l’image est juste énorme! " />

Urgente-Fraxinelle-unitaire

Le 11/12/2013 à 10h11

geekounet85 a écrit :

je fais avec ce que je trouve, et l’article ne donne pas toutes les infos… et pour moi, GitHub est loin d’être une source claire, même si c’est la plus fiable.

Justement, si t’as pas d’info, pourquoi tu affirmes des trucs dont tu ne sais même pas s’ils sont vrais ?

Strimy

Le 11/12/2013 à 10h12

geekounet85 a écrit :

autre chose : les commentaires du blog de CM indiquent que la clé est générée localement, ce qui est apparemment partiellement vrai puisque le serveur génère une pré-clé.

si le serveur possède une partie de la solution pour déchiffrer le message, ce sera forcément un maillon attaquable facilement par la NSA, surtout si ce serveur est aux USA.

Autre question : peut-on faire son propre serveur et l’utiliser facilement sans avoir à refaire un APK spécifique?

Pour le premier point, je ne pense pas que ca change quoi que ce soit. Les données stockées sur le serveur correspondent à un ensemble de données publiques générées par les clients (et non le serveur) pour avoir un pool de clés pré-établies pour le DH.

Ca permet à un émetteur d’obtenir une de ces clés pour calculer le “shared secret” nécessaire, alors que le receveur n’est pas disponible au moment même.

NarOneR

Le 11/12/2013 à 10h15

Je comprend pas pourquoi ils ont besoin d’un serveur.

Si les choses sont bien faites chacun génère une clé et chiffre/déchiffre localement.

Presteus

Le 11/12/2013 à 10h16

mistigrite a écrit :

Justement, si t’as pas d’info, pourquoi tu affirmes des trucs dont tu ne sais même pas s’ils sont vrais ?

Et toi, plutôt que d’attaquer gratuitement les interlocuteurs, cela te semblerait digne de partager tes connaissances ? " />

PCINpact a écrit :

Si tu ne sais pas : demande. Si tu sais : partage !

trash54

Le 11/12/2013 à 10h20

geekounet85 a écrit :

PRISM sans doute, Art13 je pense que CM s’en tamponne l’oreille avec une babouche des débats parlementaires français…

oui CM doit même pas savoir mais si ils veulent placer leur truc en France hop une petite recherche et hop info sur CM sur Art13" />

CryoGen

Le 11/12/2013 à 10h21

geekounet85 a écrit :

OK, " />

du coup, il faut un forfait avec SMS illimités car je suppose que les échanges transparents se font via des sms non visibles, non?

enfin, je râle mais ça reste une très bonne initiative! " />

et l’image est juste énorme! " />

Les échanges sécurisés se font en data (push), pas en sms.

yverry Abonné

Le 11/12/2013 à 08h59

Comme les autres …. il envoi une séquence text et si le destinataire la comprend fais une réponse adéquat

Strimy

Le 11/12/2013 à 09h04

Quelqu’un sait comment le chiffrement est effectué ? Symétrique ou asymétrique ? Quelle méthode est utilisé pour l’échange des clés ? (J’ai l’impression que c’est du DH pour l’échange, puis AES pour la communication)

J’ai développé une application très similaire sur Windows Phone, mais toujours en recherche d’idées pour améliorer l’utilisabilité (surtout avec les limitations de WP).

knos

Le 11/12/2013 à 09h04

venery a écrit :

Comme les autres …. il envoi une séquence text et si le destinataire la comprend fais une réponse adéquat

Mais comment ca sais si le destinataire ne la comprend pas? Ca oblige une réponse de l’autre téléphone? Qui paye la réponse?

Minikea

Le 11/12/2013 à 09h06

donc c’est centralisé et c’est sans doute le serveur (localisé pourquoi pas aux US, pour faciliter les choses) qui gère les paires de clefs, j’imagine. quelle solution sécurisante, en effet!

Strimy

Le 11/12/2013 à 09h07

geekounet85 a écrit :

donc c’est centralisé et c’est sans doute le serveur (localisé pourquoi pas aux US, pour faciliter les choses) qui gère les paires de clefs, j’imagine. quelle solution sécurisante, en effet!

De ce que je comprend dans le code, il y a un échange de clé qui est effectué par sms classique. Pas de lien avec un serveur.

iosys Abonné

Le 11/12/2013 à 09h08

“La sécurité est au centre des préoccupations de tout le monde”

Je cite JDG ; “l’OS de Google a atteint 81,9 % de parts de marché à travers le monde ce dernier semestre.”

J’ai ri.

Commencez par choisir des marques qui résistent le plus à la publicité, et vous aurez déjà fait un grand pas.

De plus, je pense que, vu l’utilisation du numérique et du social (les SMS en faisant partie) par plus de la moitié des utilisateurs, la sécurité est leur dernière préoccupation.

Comme dit une auteure ès lettres célèbre : “Moi, j’infiltrais ton phone-tel’ quatre ans en arrière”

Donc crypté sur le chemin ou pas, la faille, c’est encore et TOUJOURS l’ICC. D’ailleurs, quand on voit que les gens confient leur téléphone à n’importe quelle boutique de réparation sans se poser aucune questions….

Non, la sécurité n’a plus vraiment de sens au 21e siècle.

CryoGen

Le 11/12/2013 à 09h08

geekounet85 a écrit :

j’ai pas été voir la techno, mais concrètement, comment fait un protocole pour savoir à priori si le destinataire possède aussi le logiciel pour déchiffrer les messages?

Il faut s’inscrire en tant qu’utilisateur. Si t’on numéro est reconnu comme utilisateur, le message est envoyé via les serveurs Cyanogen/textsecure et non par sms.

Ingénieur informaticien

Le 11/12/2013 à 09h14

Oui ça serait bien d’avoir des infos sur le fonctionnement exact.

Comment ce système gère le problème du “man in the middle” au juste ?

Est-ce juste du pur marketing ou quoi ?

Minikea

Le 11/12/2013 à 09h14

CryoGen a écrit :

Il faut s’inscrire en tant qu’utilisateur. Si t’on numéro est reconnu comme utilisateur, le message est envoyé via les serveurs Cyanogen/textsecure et non par sms.

et donc le serveur “peut” être en possession des moyens de déchiffrer le message? pas NSA-proof, donc…

alors, oui, je suis d’accord, au niveau facilité de mise en place et d’utilisation, on peut pas mieux faire. par contre ça bouffe sérieusement sur la sécurité.

Origami

Le 11/12/2013 à 09h16

iosys a écrit :

“

Commencez par choisir des marques qui résistent le plus à la publicité, et vous aurez déjà fait un grand pas.

Ouais c’est clair, je vais quitter l’os de Google pour celui d’Apple ah non…celui de Microsoft…" />

Cette prise de conscience sur la sécurité des données ne peut-être que bénéfique, même si pour le moment elle reste cantonnée à une infime partie de la population.

Reste à savoir si cette techno est totalement décentralisée ou fait intervenir un quelconque tiers.

Strimy

Le 11/12/2013 à 09h16

Ingénieur informaticien a écrit :

Oui ça serait bien d’avoir des infos sur le fonctionnement exact.

Comment ce système gère le problème du “man in the middle” au juste ?

Est-ce juste du pur marketing ou quoi ?

D’après ce que j’ai compris du code j’ai pas regardé en détail, et je n’ai jamais utilisé l’appli), il y a en premier lieu un échange de clé effectué par du ECDH qui permet de partager une valeur secrète entre les deux parties.

A partir de cette valeur, une clé AES est générée pour sécuriser l’échange des communications.

fwak

Le 11/12/2013 à 09h23

Origami a écrit :

Ouais c’est clair, je vais quitter l’os de Google pour celui d’Apple ah non…celui de Microsoft…" />

Cette prise de conscience sur la sécurité des données l’ultra-dépendance aux TI ne peut-être que bénéfique, même si pour le moment elle reste cantonnée à une infime partie de la population.

Reste à savoir si cette techno est totalement décentralisée ou fait intervenir un quelconque tiers.

Le problème est avant toute autre chose là.

TheJester Abonné

Le 11/12/2013 à 09h26

À tout ceux qui demandent des infos, tout est dispo sur GitHub ou le blog de CyanogenMod ! -_-

@David, je tourne sur les nightly de CM11 et le confirme que TextSecure est déjà dispo.

CryoGen

Le 11/12/2013 à 09h27

geekounet85 a écrit :

et donc le serveur “peut” être en possession des moyens de déchiffrer le message? pas NSA-proof, donc…

alors, oui, je suis d’accord, au niveau facilité de mise en place et d’utilisation, on peut pas mieux faire. par contre ça bouffe sérieusement sur la sécurité.

Non, apparemment il y a aussi un échange de clés “inconnues” du serveur. Il ne servirait que de relais.

Enfin faudrait que je m’y intéresse d’avantage pour être sûr de ce que je raconte " />

Ingénieur informaticien

Le 11/12/2013 à 09h28

Strimy a écrit :

D’après ce que j’ai compris

Merci.

Minikea

Le 11/12/2013 à 09h32

TheJester a écrit :

À tout ceux qui demandent des infos, tout est dispo sur GitHub ou le blog de CyanogenMod ! -_-

@David, je tourne sur les nightly de CM11 et le confirme que TextSecure est déjà dispo.

je suis allé voir sur GitHub, mais même en ayant fait un peu de progra, je pige pas grand chose à ce projet, mais il y a quelques trucs qui me font aller dans le sens

de CryoGen et Strimy, à savoir un échange de clés entre les deux parties.

GitHub a écrit :

Your TextSecure verification code: