Je comprends tout à fait que de nombreuses personnes souhaitent des détails techniques. La seule raison pour laquelle je n'en ai pas donné plus jusqu'à présent c'est que j'appréhende l'avalanche de questions du type "pourquoi cette technologie et pas celle-là" ou "pourquoi pas ce langage de programmation", etc. et je ne souhaite pas rentrer dans ce type de polémique sans fin.
D'un point de vue général, et parce que c'est un objectif à moyen terme du projet, Lupo Libero sera développé de manière à être facilement décentralisable (plus d'informations à ce sujet dans le texte de la campagne de financement). Donc une des contraintes est de minimiser les traitements réalisés côté serveur. Nous souhaitons que le service soit accessible sans installer de logiciel donc il sera développé en HTML5 et javascript (avec un framework, probablement AngularJS).
Il y aura également un client lourd (optionnel) pour la synchronisation, qui n'aura pas d'interface graphique : un simple daemon, qui sera administré par l'interface web (sans passer par les serveurs). Le client lourd sera essentiellement une base de données CouchDB contenant les fichiers chiffrés de l'utilisateur et un script assurant le lien avec le système de fichier, le chiffrement/déchiffrement, l'augmentation du volume des données (voir zfec, ci-dessous) et leur découpage avant d'être stockées dans la base de données (et donc sur les serveurs, par synchronisation).
Côté serveur, il y aura un cluster de serveurs de bases de données CouchDB (et des proxies) qui aura essentiellement trois missions : stocker les données chiffrées (côté client), servir l'interface web et gérer les quotas. A peu près tout le reste sera géré côté client.
Ce qui fait défaut à la plupart de nos concurrents qui proposent du chiffrement côté client (généralement de manière optionnelle) c'est la granularité du partage : avoir tous ses fichiers chiffrés mais garder la possibilité d'en partager des sous-ensembles (un ou plusieurs fichiers ou répertoires) avec une ou plusieurs personnes sans dévoiler les autres fichiers et sans mots de passe additionnels. Elle n'est pas forcément évidente à comprendre mais il y a une réelle complexité à gérer cela : il ne faut pas chiffrer tous les fichiers avec les mêmes clés et il faut procéder à l'échange de clés de manière automatisée (par du chiffrement asymétrique) et avec les bonnes personnes.
Pour ce faire, nous nous appuieront sur le travail de chercheurs qui sont à l'origine de Wuala (à ma connaissance, le seul de nos concurrents à offrir le même niveau de sécurité, mais qui a malheureusement fait le choix du logiciel propriétaire, ce qui nous empêche de vérifier ce qu'ils font véritablement avec nos données) : CrypTree. En quelques mots, il s'agit de construire un arbre de clés hiérarchisé, qui suit la structure de l'arborescence des fichiers et qui permet, entre autres, qu'un partage d'un répertoire donne également l'accès implicitement à son contenu et au chemin pour accéder à ce répertoire. Pour ceux qui voudrait en savoir plus, le document est librement téléchargeable (des connaissances en cryptologies sont nécessaires pour comprendre ce document) : http://dcg.ethz.ch/publications/srds06.pdf.
Autre point clé, la réplication (partielle) des données. Nous utiliserons la bibliothèque de code correcteurs zfec, développée par Tahoe-lafs. Elle nous permettra, après découpage de chaque données en un certain nombre de bloc, d'augmenter le volume de chaque donnée avec des informations redondantes (un peu comme avec du RAID5) et donc d'augmenter le nombre de blocs pour chaque donnée, de manière a pouvoir résister à la perte de k blocs parmi m.
# Détails techniques
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 10.
Je comprends tout à fait que de nombreuses personnes souhaitent des détails techniques. La seule raison pour laquelle je n'en ai pas donné plus jusqu'à présent c'est que j'appréhende l'avalanche de questions du type "pourquoi cette technologie et pas celle-là" ou "pourquoi pas ce langage de programmation", etc. et je ne souhaite pas rentrer dans ce type de polémique sans fin.
D'un point de vue général, et parce que c'est un objectif à moyen terme du projet, Lupo Libero sera développé de manière à être facilement décentralisable (plus d'informations à ce sujet dans le texte de la campagne de financement). Donc une des contraintes est de minimiser les traitements réalisés côté serveur. Nous souhaitons que le service soit accessible sans installer de logiciel donc il sera développé en HTML5 et javascript (avec un framework, probablement AngularJS).
Il y aura également un client lourd (optionnel) pour la synchronisation, qui n'aura pas d'interface graphique : un simple daemon, qui sera administré par l'interface web (sans passer par les serveurs). Le client lourd sera essentiellement une base de données CouchDB contenant les fichiers chiffrés de l'utilisateur et un script assurant le lien avec le système de fichier, le chiffrement/déchiffrement, l'augmentation du volume des données (voir zfec, ci-dessous) et leur découpage avant d'être stockées dans la base de données (et donc sur les serveurs, par synchronisation).
Côté serveur, il y aura un cluster de serveurs de bases de données CouchDB (et des proxies) qui aura essentiellement trois missions : stocker les données chiffrées (côté client), servir l'interface web et gérer les quotas. A peu près tout le reste sera géré côté client.
Ce qui fait défaut à la plupart de nos concurrents qui proposent du chiffrement côté client (généralement de manière optionnelle) c'est la granularité du partage : avoir tous ses fichiers chiffrés mais garder la possibilité d'en partager des sous-ensembles (un ou plusieurs fichiers ou répertoires) avec une ou plusieurs personnes sans dévoiler les autres fichiers et sans mots de passe additionnels. Elle n'est pas forcément évidente à comprendre mais il y a une réelle complexité à gérer cela : il ne faut pas chiffrer tous les fichiers avec les mêmes clés et il faut procéder à l'échange de clés de manière automatisée (par du chiffrement asymétrique) et avec les bonnes personnes.
Pour ce faire, nous nous appuieront sur le travail de chercheurs qui sont à l'origine de Wuala (à ma connaissance, le seul de nos concurrents à offrir le même niveau de sécurité, mais qui a malheureusement fait le choix du logiciel propriétaire, ce qui nous empêche de vérifier ce qu'ils font véritablement avec nos données) : CrypTree. En quelques mots, il s'agit de construire un arbre de clés hiérarchisé, qui suit la structure de l'arborescence des fichiers et qui permet, entre autres, qu'un partage d'un répertoire donne également l'accès implicitement à son contenu et au chemin pour accéder à ce répertoire. Pour ceux qui voudrait en savoir plus, le document est librement téléchargeable (des connaissances en cryptologies sont nécessaires pour comprendre ce document) : http://dcg.ethz.ch/publications/srds06.pdf.
Autre point clé, la réplication (partielle) des données. Nous utiliserons la bibliothèque de code correcteurs zfec, développée par Tahoe-lafs. Elle nous permettra, après découpage de chaque données en un certain nombre de bloc, d'augmenter le volume de chaque donnée avec des informations redondantes (un peu comme avec du RAID5) et donc d'augmenter le nombre de blocs pour chaque donnée, de manière a pouvoir résister à la perte de k blocs parmi m.
Et voici quelques documents plus récents que nous sommes en train d'étudier pour voir si ils pourraient être utilisés pour améliorer l'infrastructure de Lupo :
- http://css.csail.mit.edu/mylar/mylar.pdf
- http://www.ieeeprojects.yavum.com/basepaper/Dotnet/Privacy-Preserving%20Multi-keyword%20Ranked%20Search%20over%20Encrypted%20Cloud%20Data.pdf.
Je vais essayer de trouver du temps pour clarifier et compléter tout cela et l'exposer sur une page du site.
Sylvain