1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
---
title: Nos créations
description: Les logiciels que l'on développe
weight: 30
sort_by: weight
draft: false
date: 2024-01-24
extra:
parent: infrastructures/services.md
---
Cette section recense les logiciels développés par Deuxfleurs pour les besoins spécifiques de son infrastructure : [Garage](@infrastructures/garage.md), [Bottin](@infrastructures/bottin.md), [Guichet](@infrastructures/guichet.md), [Tricot](@infrastructures/tricot.md), [Diplonat](@infrastructures/diplonat.md)...\
Cette page en particulier présente nos choix de conception.
# Principes de conception
Deuxfleurs reconnaît l'importance sociale des choix techniques.
N'importe quel outil est imbibé de l'idéologie de la société qui l'a vu naître – et en retour, il impose son idéologie aux sociétés à venir.
Sachant cela, on arbitre nos choix techniques en regardant en premier lieu ce qu'ils vont impliquer socialement.
Cela fait de nos infrastructures une bizarrerie pour qui est habitué⋅e aux pratiques de l'informatique industrielle.
Nous 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
- Je ne veux pas que le contenu de mes messages et des fichiers que je partage soient accessibles à des tiers (_e.g._ une photo que j'ai prise, mes réactions).
- Je ne veux pas que les métadonnées autour de mes actions soient accessibles à des tiers (_e.g._ les salons de discussions auxquels je prends part, l'horodatage des messages, les personnes avec qui j'échange).
- Je ne veux pas que mes métadonnées de communication soient accessibles (_e.g._ quand je me connecte à un service, depuis où, si j'intéragis sur le réseau, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocole (autres personnes dans le salon de communication, horodatage, etc.).
#### Courrier électronique (de l'e-mail au mixnet)
- Je ne veux pas que le contenu de mes e-mails et pièces jointes soit lisibles par des tiers (_e.g._ le doc que j'ai joint).
- Je ne veux pas que les métadonnées autour de mon message soient accessibles (_e.g._ le destinataire, l'expéditeur, l'horodatage, le client e-mail utilisé, le sujet du mail, le dossier dans lequel il est stocké).
- Je ne veux pas que mes métadonnées de communication soient accessibles (_e.g._ quand je me connecte au service e-mail, depuis où, quand j'intéragis sur le réseau).
Ces données peuvent permettre d'inférer des informations importantes sur mes correspondant⋅es et moi-même (destinataires, présence de pièce jointe, etc.).
#### Synchronisation et collaboration sur des fichiers
- Je ne veux pas que le contenu de mes fichiers soit accessible à des personnes non autorisées.
- Je ne veux pas que les métadonnées de mes fichiers soient accessibles (_e.g._ nom du fichier, dossier, format, taille, hash, etc.).
- Je ne veux pas que mes métadonnées de communication soient accessibles (_e.g._ quand j'accède au document, depuis où, qui d'autre, combien de fois, etc.).
Ces données peuvent permettre d'inférer des informations importantes sur mes correspondant⋅es et moi-même (taille, collaborateurs, type, etc.).
## Modèles d'attaquants
Dans le domaine de la sécurité, on commence toujours par décrire l'« attaquant » : ses capacités, le temps dont iel dispose...
Car il n'existe aucune défense qui protège de toutes les attaques : il faut donc savoir contre qui on est en mesure de se défendre, ou pas.
Suivent quelques attaquants potentiels :
- Administrateur Système (_e.g._ utilise ses accès privilégiés pour accéder volontairement ou non à du contenu privé)
- Hébergeur de la machine non administrateur (_e.g._ branche un clavier et un écran sur l'ordi et récupère un accès admin)
- Développeurs (_e.g._ ajout d'une porte dérobée au moment de l'écriture du code d'un logiciel qu'on utilise)
- Chaîne logistique (_e.g._ ajout d'une porte dérobée au moment de déployer un logiciel sur les serveurs ou le terminal de l'utilisateur)
- Opérateur Internet (_e.g._ Orange), voit passer une partie de notre trafic
- Regroupement d'opérateurs Internet (cf "Tor netflow")
- Personne externe via Internet (_e.g._ hacker)
- Personne externe physique (_e.g._ voleur)
- Regroupement d'acteurs (_e.g._ opérateurs internet, externe physique ET internet)
- Usager⋅es, qui peuvent se faire pirateur leurs données par ailleurs (_e.g._ téléphone non protégé)
## 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 :
- centralisé, pas chiffré (Messenger)
- centralisé, chiffé de bout en bout (il y en a une grande quantité, la meilleure étant peut-être Signal)
- fédéré, pas chiffré (E-mail, IRC, Matrix sans chiffrement de boût en boût (E2EE), XMPP sans Omemo)
- fédéré, chiffré (XMPP + Omemo, Matrix + E2EE)
- distribué, chiffré (Tox, Retroshare)
- distribué avec des mécanisme d'anonymat fort (Freenet, Mix networks)
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 :
- Par exemple dans une architecture de cluster à-la-Deuxfleurs, on pourrait différencier les lieux où on stocke les données en fonction du niveau de privacy : par exemple seuls les serveurs chez X seraient habilités à déchiffrer le contenu pour le servir sur des protocoles standards (S3, IMAP, Matrix), et les serveurs chez les autres seraient uniquement là pour stocker de la donnée entièrement chiffrée
- On peut imaginer que les clefs de chiffrement ne soient jamais stockées en clair nulle part : elles pourraient être stockées avec une passphrase qui serait le mot de passe de l'utilisateur (+ éventuellement un mécanisme de secret de shamir pour répartir les morceaux de clefs sur plusieurs machines), et c'est seulement au dernier moment (en RAM) qu'elles existent en version déchiffrée
- Enfin, on peut imaginer que Deuxfleurs fournisse à la place (ou en plus) du protocole standard un protocole entièrement chiffrée + un logiciel proxy que les utilisateurices pourraient installer sur leur machine pour avoir accès au protocole standard avec toutes leurs applications habituelles. Cette dernière option permettrait d'avoir le même niveau de sécurité que la solution consistant à définir de nouveaux protocoles, sans pour autant compromettre l'interopérabilité avec l'écosystème existant.
## Ressources
- [https://about.psyc.eu/Federation](https://git.deuxfleurs.fr/Deuxfleurs/nixcfg) et [https://about.psyc.eu/PSYC2](https://about.psyc.eu/PSYC2)
- Définition d'un mixnet : [https://www.youtube.com/watch?v=dQtk0NcTseg](https://www.youtube.com/watch?v=dQtk0NcTseg)
|
