L'équipe derrière Bleep, l'outil de messagerie instantanée sécurisée de BitTorrent, continue de faire évoluer son bébé. Elle vient ainsi d'annoncer la mise en place d'un système d'échange de messages hors-ligne asynchrone. Un élément plus complexe qu'il n'y paraît.
Dans un billet, l'équipe de développement de Bleep revient sur sa dernière fonctionnalité en date, désormais accessible à tous : l'échange de messages asynchrone hors-ligne. Pour faire simple, cela vous permet d'envoyer un message à un tiers qui n'est pas connecté, ce qui était déjà possible depuis le mois dernier. Mais pour le lire, la personne concernée n'aura pas besoin que vous soyez vous-même en ligne. D'où la notion d'asynchrone.
La conversation hors-ligne améliorée dans un outil qui mise sur la sécurité
Ce point peut apparaître comme un détail, mais il cache plus que cela. En effet, pour qu'un tel échange soit possible, il faut que le message existe sur le réseau même lorsque ni l'expéditeur, ni le destinataire ne sont connectés. Cela ouvre ainsi la voie à la récupération par une personne mal intentionnée qui arriverait à s'en emparer d'une manière ou d'une autre.
L'équipe indique avoir utilisée la DHT (Table de hachage distribuée) pour arriver à ses fins, l'un des éléments utilisés dans le protocole BitTorrent. Il s'agit en effet d'un système décentralisé et distribué qui permet de stocker et de retrouver facilement une donnée au sein d'une table associant une clef à une valeur. Mais le détail précis de son utilisation dans le cadre de cette fonctionnalité de Bleep n'est malheureusement pas communiqué.
C'est d'ailleurs là que s'exprime le mieux toute la problématique autour des outils annoncés comme sécurisés, mis en ligne par BitTorrent : leurs sources n'étant pas publiées, il faut donc se reposer sur la bonne volonté et les annonces de ses développeurs pour en savoir plus, sans avoir la possibilité de décortiquer ou d'auditer le fonctionnement de l'ensemble. Des phases pourtant vitales pour ce qui est d'assurer la confiance dans des applications de ce genre, ce qui est la base même de leur intérêt.
La confidentialité persistante arrive, mais quid de la confiance ?
Dans le même temps, on apprend que si les messages sont chiffrés de bout en bout pour le moment, une prochaine mouture apportera le support de la confidentialité persistante (Forward Secrecy). Ici, le but est de rendre chaque chiffrement unique à une conversation, afin de ne pas permettre de la déchiffrer a posteriori, même si l'on arrive à récupérer la clef privée de l'un des utilisateurs. Cela passe par la mise en place d'une paire de clefs propre à chaque échange et impossible à retrouver à partir des clefs privées (ratcheting), qui ne sera utilisée que de manière temporaire, avant d'être supprimée.
Avec le chiffrement des conversations, le système de connexion qui ne nécessite pas d'autorité centrale et l'obfuscation des métadonnées, cela fera sans doute de Bleep un outil plutôt complet. Mais il faudra sans doute plus que cela pour qu'il devienne un outil auquel on puisse se fier au-delà de quelques échanges entre amis un peu paranos.
Commentaires (12)
#1
#2
Quoi qu’il arrive il est compliqué de faire confiance à un éditeur, même si celui publie les sources.
Car, clairement, qui vérifie vraiment? Et même vérifiées, il faut faire confiance en la compétence et l’intégrité de ce celui qui s’en est chargé.
Et a qui peut-on réellement faire confiance aujourd’hui ? Certainement plus aux américains ou à nos gouvernements. Il reste qui ? La justice ? Des organismes internationaux ? Ses amis ? Soit-même (donc se former longuement et correctement à chaque langages/méthodes/etc <– impossible…).
Pour le moment, la seule solution que je vois, c’est : faire confiance à la tête de l’éditeur (sa réputation), et espérer une dénonciation journalistique en cas de travers.
Bancale n’est-ce pas ?
Qui aurait une meilleure solution ?
#3
En général, c’est audité par des tiers, dont le seul intérêt est de préserver leur propre réputation.
Rajoute une grosse prime pour celui qui trouve une faille et ça donne une fiabilité du système relativement sérieuse.
#4
#5
Si tu es vraiment parano il faut recompiler le logiciel à partir des sources. C’est ce que fond les distributions Linux.
Malheureusement Bleep n’est pas libre et on a pas accès aux sources.
#6
Utiliser les DHT comme “dead letter box”, c’est pas vraiment nouveau. On pouvait déjà faire cela avec Kademlia.
#7
comme le disent certains, il suffit de faire auditer le code source,
comme c’est le cas pour Truecrypt (version 7.1a)
#8
Oui, j’ai oublié de mentionner les audits, c’est vrai, bien vu. Mais ça ne fait que déplacer le problème sur la confiance que l’on accorde aux auditeurs en fait. C’est mieux que rien dirons-nous ?
#9
ha bah là…. c’est sûr que si on fait même plus confiance à un audit de code autant oublier toutes questions de sécurité etc.
mais c’est sûr qu’il ne faut pas faire confiance à n’importe qui. d’où la réputation.
#10
Eheh oui. En tout cas, sans vouloir troller, c’est pas avec la CNIL qui laisse faire le BigData mais qui fait chier sur des stupidités, qu’on risque d’avoir confiance dans les autorités ou dans les organismes d’Audit qu’elles approuvent.
#11
Les meilleures personnes de confiance dans le cas d’audit de code sont les universitaires. Ils ont les connaissances techniques ( ce sont souvent eux, bien avant les grosses boites privées, qui font avancer le domaine de la sécurité informatique), le temps pour décortiquer ce genre de soft/techno/protocoles en plus de leurs faibles heures de cours ( :p ) et la réputation d’impartialité pour peser sur la popularité d’un soft.
Pour donner des exemples, des gars comme Bruce Schneier, Matthew D. Green, etc …
#12
Effectivement, j’aime beaucoup cette solution offerte par les universités que tu énonces.
Bon, il faut quand même faire gaffe, surtout en France, on voit régulièrement des universitaires d’une nullitée totale (en particulier en informatique), donner leurs avis sur tout et sur rien, voir faire de la politique engagée. Niveau confiance en leur objectivé scientifique, ça dégrade un peu le bouzin.