Logiciels

Cette section recense les logiciels développés par Deuxfleurs pour les besoins spécifiques de son infra.

Principes de conception

Nou essayons de suivre plusieurs principes pour une conception qui correspond au besoin tout en ayant un ensemble de logiciels homogènes.

Vie privée

Que ce soit à l'intérieur ou l'extérieur de l'association, des demandes pour d'avantage de garanties sur la vie privée ont été formulées.

Propriétés recherchées

Quelques propriétés en vrac qu'on peut, ou ne pas, désirer :

Messagerie instantanée

Courrier électronique (de l'email au mixnet)

Synchronisation et collaboration sur des fichiers

Attaquants

Quelques attaquants que l'on peut, ou ne pas, considérer :

Un exemple de ce qu'on pourrait faire

Prenons l'exemple de la messagerie instantanée. Pour l'instant, on peut définir les types de réseaux suivants :

Seule la dernière catégorie s'adresse au cas d'un "global passive attacker". On peut imaginer d'abandonner l'idée d'avoir une protection très efficace contre ce dernier car ça serait très contraignant sur le design et l'utilisabilité, et les cas où on en aurait vraiment besoin sont des cas particuliers où on peut faire l'effort d'utiliser une solution adaptée.

Pour le "grand public", passer sur des solutions fédérés chiffrés c'est un très bon début et si on arrive déjà à passer des gens sur Matrix, c'est très bien. Ceci dit, il y a quand même une faille majeure dans ces systèmes, c'est l'existence de serveurs qui centralisent des quantités plus ou moins importantes de (méta)données : il suffit que n'importe lequel soit compromis pour que toutes ces données soient exfiltrées, global passive attacker ou non. En ce qui nous concerne chez Deuxfleurs, le danger est exacerbé car on veut faire de la réplication sur plusieurs noeuds chez plusieurs personnes, donc autant d'opportunités d'avoir une sécu pétée à un endroit ou un autre.

Une marche à franchir qui pourrait être désirable pour nous, ça serait donc de faire en sorte que les serveurs aient le moins de visibilité possible sur ce qui se passe dans le réseau. Dans un système "distribué chiffré" on n'a plus de serveurs donc le problème n'existe pas, le seul danger qui reste est la possibilité de compromettre le périphérique utilisateur directement (et on sait par ailleurs que c'est possible, mais c'est pas quelque chose sur lequel on peut agir nous). Par contre les systèmes 100% distribués ne sont pas utilisables efficacement sur mobile car ils pompent la batterie, d'où l'idée de vouloir faire une approche hybride où des serveurs pourraient jouer un rôle mais avec des protocoles prévus d'une manière à ce qu'ils ne voient passer et ne stockent qu'un minimum de données en clair.

Un autre problème, c'est que dans un modèle totalement distribué se pose la question de qui gère la résilience du service et des données ? Comment tu développes un logiciel distribué qui ne perd pas de données (bitcoin n'est pas une réponse valable) ?

On peut globalement diviser les approches en deux :

  1. Définir des nouveaux protocoles client/serveur qui minimisent les métadonnées lisibles par les serveurs

  2. Rester dans le cadre des protocoles standards (IMAP, WebDav, ...), et faire une implem où les serveurs stockent le plus possible de données chiffrées (y compris toutes les métadonnées), et ont le moins souvent possible accès à la donnée en clair.

La première approche est intéressante, mais elle implique de remplacer tout l'écosystème. Ça peut être un projet de recherche intéressant, mais on ne veut pas forcément en faire le projet prioritaire de Deuxfleurs.

Concernant la seconde approche, celle-ci semble beaucoup plus à notre portée :

Ressources