CryptPad v1.10.0 est disponible, à la découverte du service collaboratif chiffré de bout en bout

CryptPad v1.10.0 est disponible, à la découverte du service collaboratif chiffré de bout en bout

Release the kraken !

Avatar de l'auteur
David Legrand

Publié dans

Internet

06/07/2017 8 minutes
47

CryptPad v1.10.0 est disponible, à la découverte du service collaboratif chiffré de bout en bout

Et si vous pouviez travailler à plusieurs sur un document, avec des échanges chiffrés sans que le serveur ne puisse avoir connaissance du contenu ? C'est la promesse de CryptPad, un projet de recherche exploitant la blockchain qui vient de publier sa nouvelle version.

Il y a quelques mois, nous entendions parler d'un nouveau projet né un soir d'Halloween, exploitant le chiffrementCryptPad. Son objectif était de proposer une solution de partage de document et de travail collaboratif en temps réel.

Un représentant de son équipe, Pierre Bondoerffer, était présent à Pas Sage en Seine la semaine dernière afin de présenter l'outil, et annoncer la nouvelle version 1.10.0 (Kraken) qui est désormais en ligne. Celle-ci apporte quelques améliorations au niveau de l'interface et de l'ergonomie. L'occasion de nous intéresser au fonctionnement du projet et de faire le point.

Une solution qui se veut complète, collaborative et chiffrée E2E

Tout d'abord : qu'est-ce que CryptPad ? L'équipe semble vouloir proposer une forme d'alternative assez simple à Google Drive/Docs, dans la mesure ou l'on retrouve un espace de stockage accompagné de quelques applications d'édition de documents, de code source, de présentation ou de sondage.

Le tout est encore relativement basique, mais le point fort du service se situe de toutes façons dans le fait qu'il s'annonce comme Zero Knowledge, un concept à ne pas confondre avec la preuve à divulgation nulle de connaissance. Ici, il s'agit du fait que le service ne détient pas les clefs de chiffrement utilisées par les utilisateurs en local et ne peut donc pas consulter le contenu. On parle en général de solution de bout en bout, ou E2E (End-to-end) pour les intimes.

Il est donc possible de partager un document, de l'éditer à plusieurs, sans que celui-ci soit stocké en clair sur le serveur. L'usage est ainsi considéré comme privé, mais pas anonyme, prévient l'équipe qui renvoie vers l'utilisation de Tor ou d'un VPN pour ajouter un telle couche de protection.

Basé sur Node.jsCKEditor, CodeMirror et le moteur temps-réel maison ChainPad, son code source est diffusé sous licence AGPL v3 via un dépôt GitHub. Il est proposé sous forme hébergée, mais vous pouvez aussi l'utiliser sur votre propre serveur. Les adeptes de Docker ont droit à une solution spécifique, un package (de test) étant aussi disponible pour Yunohost.

Il est édité par XWiki Labs et en partie financé jusqu'en 2019 par Bpifrance à travers le projet OpenPaaS::NG Research. Le reste du financement doit venir des abonnements, du support pour des tiers, ou du sponsoring pour la mise en place d'une ou plusieurs fonctionnalités en particulier.

Une question d'éthique avant tout

Si le site n'est pas très prolixe (et manque de mentions légales), on peut en apprendre un peu plus sur le projet du côté de son blog officiel. Dans son article initial de février dernier, Caleb James DeLisle explique ses motivations : le besoin d'un service éthique, hors de la pratique de la gratuité contre des données, capable de prouver sa bonne foi à l'utilisateur à travers son concept de « Zero Knowledge ».

Il fait d'ailleurs la différence entre ce discours et l'annonce de solutions « sécurisées », aux modèles économiques divers. Au passage, il assure la promotion d'autres services open source du genre tels que Cryptomator, nCryptPretty Easy Privacy ou encore Riot.im, voire même de solutions propriétaires.

Les mois suivants ont été l'occasion de corriger quelques failles, d'ajouter les abonnements puis diverses fonctionnalités. Malheureusement pas de mettre en place de manière plus visible et lisible une documentation permettant de détailler le fonctionnement de l'ensemble. Une page descriptive est accessible par ici.

Du chiffrement symétrique et de la blockchain

Il faut surtout aller du côté du projet ChainPad pour voir de quoi il retourne. Aussi développé par XWiki Labs, il exploite un chiffrement symétrique (via NaCL) et une clef qui est partagée entre tous les participants. Celle-ci est présente dans l'URL de partage du document (via l'identificateur de fragment), ce qui nécessitera donc de procéder avec prudence. 

L'évolution du document est gérée par transformation opérationnelle. Le dispositif utilise la blockchain telle qu'imaginée par Satoshi Nakamoto et une structure CRDT (Conflict-free replicated data type) notamment utilisée dans Git. Le transport des messages est effectué par des websockets et l'API maison Netflux.

Ici, les blocs contiennent des « Patchs » qui sont un ensemble de modifications apportées au document. Chaque bloc est identifié par une empreinte (SHA256), qui servira notamment à indiquer la référence d'un état précédent. Chaque participant pourra vérifier et valider un patch, avant que celui-ci ne soit appliqué.

Dans la pratique, l'équipe explique le fonctionnement de la sorte : lorsqu'un utilisateur effectue des modifications au sein du document (Authoritative), il créé des opérations qui sont placées dans un espace connu sous le petit nom d'Uncommitted Work.

De manière périodique, ce dernier sera transféré au serveur sous la forme d'un Patch puis renvoyé vers l'ensemble des clients. Lorsqu'un Patch est reçu, il est examiné afin d'en déterminer la validité pour être accepté ou rejeté. Si tout se passe bien, il est appliqué au document directement ou de manière différée selon les cas.

Au final, on se retrouve avec un système qui permet de gérer l'évolution d'un fichier avec une décentralisation du consensus, sans nécessité d'en connaître le contenu. Le stockage semble pouvoir être adapté à différentes solution. Par défaut il s'agit de fichiers mais il est possible de miser plutôt sur une base de données.

Dans la pratique, comment ça marche ?

Pour tester CryptPad, rien de plus simple. Il vous suffit de vous rendre sur le site et de choisir de Créer un pad anonymement. Il vous sera proposé d'indiquer un nom (vous pouvez rester anonyme), vous arriverez ensuite directement dans l'interface d'édition. 

Celle-ci reprend des morceaux de ce que l'on connait avec EtherPad ou encore Google Docs, ce qui ne sera pas forcément du goût de tout le monde. Vous pourrez modifier le titre du document via une ligne auto-éditable sur la partie haute. À sa gauche, un bouton en forme de disque dur vous renverra vers l'interface de gestion des fichiers CryptDrive. 

  • CryptPad 1.10.0
  • CryptPad 1.10.0
  • CryptPad 1.10.0
  • CryptPad 1.10.0

Un bandeau sur la gauche affichera la liste des participants à l'édition du document ou ceux qui sont simplement en train de le regarder. Le lien de partage permet en effet de faire la différence. Pour rappel, celui-ci devra être diffusé avec attention, pour éviter tout problème. On regrettera d'ailleurs de ne pas pouvoir le réinitialiser en cas de fuite.

En haut à droite différentes icônes indiqueront le statut, la latence du système en ms ou permettront d'accéder aux paramètres du compte. Il sera aussi possible d'importer ou d'exporter un pad, de le supprimer, de le sauvegarder comme modèle ou d'en créer un nouveau.

La barre d'édition pourra être cachée. Elle contient l'essentiel des fonctionnalités nécessaire à un tel outil, sans trop de fioritures. Ne vous attendez par contre pas à une gestion de thèmes ou d'options avancées comme vous le trouveriez dans un outil tel que Word. 

Dans l'ensemble le fonctionnement est plutôt réactif, même avec quelques utilisateurs et à travers une connexion classique (ADSL/FTTH). Il faudra néanmoins voir si cela ne pose pas trop de souci si le nombre d'intervenants devient très important et que la qualité des connexions se fait moins bonne.

Usage anonyme, gratuit ou via l'offre payante

On appréciera que l'utilisation sans compte soit assez complète, avec paramètres et accès au Drive. Mais attention, les fichiers non utilisés pourront être supprimés au bout de trois mois. Pour pérenniser votre usage, vous pouvez vous inscrire sur le site avec un simple nom d'utilisateur et un mot de passe. Celui-ci ne pourra pas être modifié pour le moment.

Par défaut, 50 Mo de stockage vous est alloué, et les données des pads de votre navigateur peuvent être importées. Des abonnements sont proposés, chacun incluant un nombre de pads illimité avec des options différentes :

  • 5 euros HT par mois : 1 utilisateur, 5 Go de stockage, support communautaire
  • 10 euros HT par mois : 2 utilisateurs, 20 Go de stockage, support communautaire
  • 15 euros HT par mois : 5 utilisateurs, 50 Go de stockage, support 1 jour ouvré (en français)

Ceux qui veulent simplement soutenir le projet peuvent le faire à travers des dons ou aider à sa traduction. Reste maintenant à voir le projet évoluer, celui-ci devant convaincre des utilisateurs de le suivre pour durer. Il faudra d'ailleurs qu'il subisse un audit complet, ce qui n'a pas encore été le cas.

L'équipe pourrait alors par exemple miser sur une intégration à des offres d'hébergeurs ou s'associer à des outils comme Cozy, qui apparaît comme un bon complément et dont la v3 devrait être bientôt mise en ligne.

CryptPad 1.10.0

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une solution qui se veut complète, collaborative et chiffrée E2E

Une question d'éthique avant tout

Du chiffrement symétrique et de la blockchain

Dans la pratique, comment ça marche ?

Usage anonyme, gratuit ou via l'offre payante

Fermer

Commentaires (47)


Qu’est ce qu’il appel “Pad” ?



C’est cher pour la taille de stockage…


Un pad = un document texte. Contrairement à EtherpadLite/Framapad, on dirait qu’un pad a un “propriétaire”.


Ya un truc qui me chiffonne :

Tu écoutes les communications de quelqu’un (opérateur, blackbox, regarder sur son épaule à la bibliothèque,…)

-> Tu as les requêtes HTTP

-> Tu as l’URL

-> Tu as l’ID du pad + la clé de chiffrement

-> …


C’est du HTTPS


Y’a pas de gestion de droits spécifique, tu est utilisateur ou simple lecteur d’un document.


Il vaut toujours mieux passer par du HTTPS - aussi, l’URL complète n’est pas envoyée par les navigateurs modernes au moment de la requête car l’ID et la clé du pad se trouve dans l’identificateur de fragment.


Peux-t-on imaginer voir cet outil arriver au sein du projet CHATONS ??


Chaque CHATON est libre de proposer les outils qu’il veut, donc je ne vois pas ce qui empêcherait une telle initiative. 


Je peux te répondre qu’il suffit d’accéder à Framapad en HTTPS aussi, alors :)

Et on n’est pas à l’abri de :

* un copié-coller foireux sans https:// devant

* des yeux/appareil photo/… qui traînent

* l’historique de Firefox (qui est à son tour parfois synchronisé, donc la clé se balade un peu partout)

* l’historique de Chrome (tiens bonjour Google)

* l’historique de IE /autretrucdontj’aipluslenom (tiens bonjour Microsoft)

* les “pseudo sécurités” et autres listeners sur des machines de boulot

Bref. Je considère que conserver la clé dans l’url est une très mauvaise idée.


Oh, je n’avais pas vu en effet le “#” qui se baladait.

Ça reste tout de même peu sécurisant.


Ca fait sans doute partie des point à améliorer, mais tu as le souci avec la majorité des outils en travail collaboratif (sauf à limiter l’accès via des droits à la manière de drive par exemple). M’enfin le projet en est à ses débuts et l’équipe semble plutôt ouverte aux idées, feel free ;)



Après comme dit, l’idée est surtout de proposer un système à la fois collaboratif et E2E, et qui fonctionne. C’est là dessus que le gros du travail a porté dans un premier temps. On peut ensuite venir discuter des choses à renforcer <img data-src=" />








Salamandar a écrit :



* un copié-coller foireux sans https:// devant



&nbsp;

Normalement quand on pond un site en HTTPS, on fait une redirection du HTTP vers HTTPS pour éviter ce genre de souci.

Surtout que pour un service qui cherche à chiffrer de bout en bout, la redirection me semble la base.



Je ne sais plus quel site (fournisseur de mails) stocke la clé dans les cookies et permet un export assez facile. C’est déjà mieux que dans l’url qui est publique et en général stockée de manière peu sécurisée.



Oui c’est vrai, et je ne peux que saluer l’effort qui donne pour le moment un outil plutôt sympathique :)


C’est le cas pour cryptPad d’ailleurs, mais l’adresse en http doit forcément circuler une première fois avant la redirection, non ?


Pendant PSES, Aeris a dit “les bêtises habituelles du chiffrement ne semblent pas présentes” <img data-src=" /> Bon après comme dit, un audit complet sera de toutes façons nécessaire pour rassurer de ce côté <img data-src=" />


Bien sûr et c’est même le cas, mais la première requête reste en http.


Oui, tu as raison, c’est plus cher qu’un service de l’un des nombreux gros fournisseurs. J’entends bien! Cependant, il faut prendre en compte que développer des logiciels coûte de l’argent. Mais c’est un choix que nous avons fait. On a choisi de ne pas monétiser et transformer nos utilisateurs en produits.


Par contre, je ne comprends pas bien comment on peut avoir un nombre de pads illimités avec un espace de stockage limité… <img data-src=" />



Je chipote mais ça me fait penser à l’illimité limité des opérateurs mobiles Français.


Tiens, je te reconnais <img data-src=" />


Coucou! Merci pour cet article, si jamais tu veux nous rencontrer n’hésites pas à sonner hein <img data-src=" />


ça revient à dire que la limite vient de l’espace de stockage et pas du nombre de pad, même si, tu as raison l’un limite l’autre


j’ai adoré leur article de blog sur l’analogie du restaurant et du soup kitchen



https://blog.cryptpad.fr/2017/06/02/Building-mutually-beneficial-relationships/








David_L a écrit :



C’est du HTTPS





Sans DNSSEC, ni TLSA.<img data-src=" />









Soriatane a écrit :



Normalement quand on pond un site en HTTPS, on fait une redirection du HTTP vers HTTPS pour éviter ce genre de souci.

Surtout que pour un service qui cherche à chiffrer de bout en bout, la redirection me semble la base.





Le site utilise HSTS et PFS. <img data-src=" />









Salamandar a écrit :



Bien sûr et c’est même le cas, mais la première requête reste en http.





Ta première requête, c’est quand tu te connectes au site pour la première fois, donc t’es pas sensé utiliser le service.<img data-src=" />



Amusant et bien fait


Tu n’as pas compris ma remarque. Je parlais de lorsqu’on copie le lien, comme cryptpad.fr/pad/#/1/edit/IDdupad/laclédechiffrement/

Et donc sans https. D’abord le navigateur tentera une requête http, et le serveur lui dira “non, https”.


Tant mieux <img data-src=" />


Hmm, je viens d’essayer vite fait leur editeur de code et je ne trouve pas C++/C/C#/Java dans les langages… Un peu bizarre quand meme.. Surtout qu’ils en ont plein que je ne connais pas <img data-src=" />


Comme précisé dans les commentaires, le service semble utiliser HSTS.Donc une première visite sur le site et/ou un navigateur avec une liste à jour, force toute requête HTTP vers le HTTPS sans requête initiale en HTTP (donc à aucun moment “théorique”, sauf toute première connexion).


Coucou! Le C/C++ est ‘clike’ dans la liste! ;)


Quel est l’intérêt de la blockchain des patchs lorsqu’on édite un document chiffré ?



Je peux comprendre l’intérêt d’avoir un consensus public lorsque tout le monde peut patcher un document. Mais dans un document chiffré, je ne vois pas trop qui pourrait proposer un patch sinon quelqu’un qui connait déjà la clé de chiffrement du document.



<img data-src=" />


Je vois “usage anonyme, gratuit ou via l’offre payante” mais il n’y a de détails que sur l’offre payante (d’ailleurs je ne retrouve pas cette page sur le site).



L’offre max présentée dans l’article permet 15 utilisateurs et ça me semble peu, il &nbsp;y a moyen d’avoir plus d’utilisateurs ?



Bonne initiative en tout cas.


Tiens, ça ma rappelle furieusement Zer0bin ça.


Sauf erreur quand ton navigateur fait une requête vers http://sousdomaine.domaine.eu/tructressecret/, il commence par une requête DNS pour identifier le serveur de sousdomaine.domaine.eu et quand il a l’IP du serveur il le contacte et seulement ensuite il lui demande la page (ou ressource) tructressecret.

Et c’est pendant cette prise de contact que le serveur va lui dire: “je ne cause qu’en TLS avec tel ou tel algorithme. Ton navigateur répond: “Ok, moi je connais ces algorithme là”.

Le navigateur se mettent d’accord sur les algorithme, font les échanges de clés et commence la connexion chiffrée.

Et c’est ensuite que le navigateur dit il me faut la page http://sousdomaine.domaine.eu/tructressecret/Lors des premiers échanges, cette information sensible n’est pas dévoilée.


Éviter les conflits d’édition ? (Je dis ça juste comme ça, j’y connais rien)


La blockchain permet aux clients d’arriver à un consencus en cas de conflit d’édition, sans intervention du serveur.

&nbsp;







Mihashi a écrit :



Éviter les conflits d’édition ? (Je dis ça juste comme ça, j’y connais rien)





Oui, exactement :)



La page est accessible depuis les éditeurs et CryptDrive, en cliquant sur le bouton “Supporter CryptPad”.

https://accounts.cryptpad.fr/


Oui, c’est dans la même idée! La différence ici est que ZeroBin n’est pas en temps réel ;)


Dans tous les cas, le navigateur ne communiquera jamais les clés ou identifiants de documents, vu qu’ils se trouvent dans l’identificateur de fragment. Au pire, il y aura une requête en HTTP vers http://cryptpad.fr/pad/ mais c’est tout ce que le serveur voit!


Ah, ok.



C’est pas un peu overkill comme solution pour gérer un conflit d’édition au sein d’un relativement petit groupe d’éditeurs autorisés, de plus sur un document dont le stockage est centralisé.



Une simple notification “This document has been modifed. Please refresh your browser” aurait le même effet. Non ?


Ça à beau être centralisé, le serveur n’a pas accès aux données, il ne peut donc pas gérer les conflits. C’est aux participants de gérer ça entre eux.


heu… Le serveur est tout de même au courant que le document a été modifié (même s’il ne sait pas déchiffré le contenu). Non ?



Ou alors je ne comprend pas à quoi servent les Go de stockage de l’offre.


Les participants ne vont pas tous recharger le document à chaque fois que seule personne le modifie. C’est plus vraiment du travail collaboratif en live sinon.

Les conflits d’édition c’est seulement si deux utilisateurs modifient la même portion du document (et ça le serveur ne le sait pas).


Dans ce cas là il vaut mieux tout simplement enlever la partie temps réel <img data-src=" />



C’est une simple blockchain sans preuve de travail, elle ne fait que lier des patchs (ainsi que leur signature) entre eux et permet entre autres de résoudre les conflits sans intervention ni du serveur (qui ne connais pas le contenu des documents, uniquement les patchs) ni de l’utilisateur.


Y a vraiment un truc qui doit m’échapper…



S’il y a conflit la blockchain ne valide qu’une des deux modifications. Donc l’autre modification est perdue et doit être re-soumise sur la nouvelle version du document. Ce qui est équivalent à faire un “refresh” du document et recoller ses modifs. non ?


Perso, en ce moment j’utilise&nbsphttp://www.qownnotes.org/ couplé avec mon serveur NextCloud pour partager mes notes entre mes devices, je vais regarder ce CryptPad, je pense qu’il sera plus facile avec de partager des notes vu que c’est du travail collaboratif <img data-src=" />