Traitement systématique sur les fichiers enregistrés sur la plateforme

Plusieurs traitements se déroulent pour chaque fichier reçu sur la plateforme, que ce soit au travers du collecteur de fichier, de l'API ou de l'intégration avec un service tiers.

1. Prise d’empreinte numérique. Il passe une première étape d'obtention d'un numéro d'identification unique de son contenu (empreinte numérique). Cette identification permet de certifier plus tard que le fichier est identique à celui reçu initialement et n'a jamais été modifié ;

2. Horodatage. Le fichier est ensuite horodaté à l'aide du protocole OpenTimestamps. Cette étape permet de certifier que le document n'a pas pu être antidaté et que la date enregistrée dans MonButin correspond à la réalité, sans nécessiter d’avoir une absolue confiance puisque cette certification est faite par un système extérieur ;

3. Création de miniature. Une miniature est créée pour permettre l'aperçu rapide du fichier plus tard sans avoir à travailler directement avec le fichier originel archivé en sécurité ;

4. Chiffrement. Votre fichier est enfin chiffré, pour permettre un archivage plus sûr.

Seulement une fois l’ensemble de ces étapes terminées, le fichier est ensuite archivé en 2 exemplaires sur l’espace de stockage de MonButin, dans un dossier qui est propre à votre compte.

Prise d'empreinte numérique

La prise d'empreinte permet de s'assurer que le fichier n'a jamais été altéré depuis sa réception. Le mécanisme de prise d'empreinte génère une suite de caractères à partir d'un fichier. Cette suite est unique : la moindre modification sur le fichier originel entraine la génération d'une toute nouvelle série de caractères. Cette série sera toujours la même pour une source identique.

Ce mécanisme est le même utilisé généralement pour la conservation de votre mot de passe sans pouvoir retrouver le mot de passe à l'origine de la chaine de caractères générée.

Il est possible, avec les méthodes les plus anciennes, d'obtenir une même série à partir de fichiers différents. Le problème reste relativement rare.

Il est surtout à relativiser : ce qui est important, pour nous, est de s'assurer que le fichier soit identique à celui reçu initialement. Qu'il ait été remplacé par un autre, avec une signature strictement identique, se verra immédiatement.

Ce qui serait plus ennuyeux soit qu'une petite modification soit effectuée, comme changer un mot ou un montant par exemple. Pour ce cas d'utilisation, même la prise d'empreinte la moins fiable reste extrêmement fiable.

Sur MonButin, 3 empreintes différentes sont prises. L'une est, pour le moment, totalement fiable et sans «collision» connue (SHA256). Le fait de prendre 3 empreintes rend la garantie absolue : falsifier une empreinte est difficile. En falsifier 3 en même temps est probablement impossible. L'intérêt est de garder l'empreinte «sûre» en cas de besoin et de pouvoir travailler au quotidien avec les autres plus rapides, par exemple pour vérifier que le fichier n'a pas été modifié.

Les 3 empreintes sont prises à l'aide des algorithmes :

• MD5 («peu» fiable, mais rapide)

• SHA1 (moins fiable)

• SHA256 (fiable)

Horodatage sur la blockchain

L'horodatage vous permet de garder une preuve de la date et heure à laquelle a été déposé chaque fichier.

L'horodatage proposé par MonButin se base sur le projet OpenTimestamps. Il permet de s'affranchir de tout tiers de confiance et permet à chacun de valider la conformité de cette information.

Le protocole est ouvert et permet d'assurer la pérennité du protocole.

L'enregistrement des données est fait sur la blockchain Bitcoin. Bien que le protocole Bitcoin soit particulièrement décrié, il est de loin le plus populaire et rend quasiment impossible toute modification en cas d'attaque sur ce réseau. C'est, sans aucun doute, la «base de données» la plus sûre à ce jour et rend incroyablement couteuse toute tentative éventuelle de prise de contrôle si elle devait intervenir.

Création de miniature

Une miniature des fichiers envoyés est conservée pour aider à avoir un aperçu rapide du fichier sans avoir à afficher le fichier originel à chaque fois (c'est-à-dire charger depuis l'espace de stockage, déchiffrer le fichier pour enfin permettre de l'afficher).

La miniature est conservée dans un espace commun à tous les comptes pour une raison : l'accès est public et les fichiers ne sont pas chiffrés. En enregistrant chaque fichier dans un dossier séparé pour chaque compte, il devient alors facile de retrouver quel fichier appartient à qui. En mettant tous les fichiers au même endroit, il est beaucoup plus difficile de rassembler les informations d'un même compte. Ce, uniquement dans l'hypothèse où l'espace de stockage des miniatures devait être frauduleusement accédé.

Pour rendre impossible toute tentative de retrouver ou déduire le nom du fichier, le nom est généré aléatoirement sur 64 caractères. Pour vous rassurer, 64 caractères correspondent à 36^64 possibilités, soit 4E99 possibilités (4 suivi de 99 zéros, combinaisons possibles) !

À moins de connaitre le nom précis du fichier, il est complètement impossible de retrouver ou deviner le nom de ce fichier. Même en automatisant l'opération ! Par exemple, imaginons un système permettant d’essayer 1 milliard de combinaisons chaque seconde. Il faudrait 1E84 années pour toutes les essayer…! Plusieurs fois plusieurs dizaines de milliards de fois l’âge de la Terre. Bref, c’est vraiment beaucoup, et pour le moment c'est un système relativement sûr.

Chiffrement du fichier

Les fichiers conservés sont chiffrés à l'aide de l'algorithme ChaCha20. La clé de déchiffrement est unique pour chaque compte, ce qui signifie qu'un utilisateur connecté ne pourra jamais déchiffrer le fichier du voisin.

Mais ce n’est pas assez ! Avec le fichier, est conservée une chaine de caractère unique et aléatoire. Cette chaine aléatoire est utilisée en complément de la clé de déchiffrement et est conservée en base de données. Sans cette clé unique pour chaque fichier, il est impossible là encore de déchiffrer le fichier chiffré.

Donc, pour chaque fichier, une clé unique par compte ET par fichier est nécessaire. C’est à dire que chaque fichier conservé sur l'espace de stockage utilise une combinaison de chiffrement unique.

Chaque élément de chiffrement est conservé en différents espaces, sur différents serveurs :

• la clé de compte est générée au niveau de l'application ;

• la clé unique de fichier est conservée en base de données ;

• le fichier chiffré est conservé sur un espace séparé.

La finalité d'un tel découpage permet de se prémunir et rendre inutile toute tentative de lecture du contenu du fichier :

• en cas de bug, si un utilisateur devait obtenir par erreur accès aux fichiers d’un autre utilisateur, il ne pourrait absolument rien en faire ;

• en cas d'intrusion sur le serveur de stockage, aucun fichier ne serait exploitable. Il faudrait retrouver la clé unique de chaque fichier, un par un. Bon courage !