FR3121524A1 - Procédé et système informatique de stockage decentralisé et de partage de fichiers numériques certifiés - Google Patents

Abstract

PROCÉDÉ ET SYSTÈME INFORMATIQUE DE STOCKAGE DECENTRALISÉ ET DE PARTAGE DE FICHIERS NUMÉRIQUES CERTIFIÉS Le procédé est mis en œuvre dans un système informatique de stockage décentralisé et de partage de fichiers numériques (DSS), le système étant déployé à travers le réseau Internet (IP) et coopérant avec un réseau de stockage décentralisé (DSN) et un réseau de chaîne de blocs (BKC). Le procédé gère un stockage séparé des fichiers numériques et de leurs métadonnées qui sont cryptés et signés avant leurs enregistrements dans le réseau de stockage décentralisé. Le procédé gère un accès aux données enregistrées en deux phases de restitution lancées typiquement par clic sur un lien d’accès. La première phase produit l’affichage d’un certificat descriptif de dépôt de fichier numérique intégrant les métadonnées, des données de certification obtenues par le réseau de chaîne de blocs et un lien d’accès au téléchargement du fichier numérique. Fig.1

Description

PROCÉDÉ ET SYSTÈME INFORMATIQUE DE STOCKAGE DECENTRALISÉ ET DE PARTAGE DE FICHIERS NUMÉRIQUES CERTIFIÉS

L’invention concerne de manière générale le stockage des fichiers numériques. Plus particulièrement, l’invention se rapporte à un procédé de stockage décentralisé et de partage de fichiers numériques certifiés et à un système informatique pour la mise en œuvre de celui-ci.

Le stockage, l’accessibilité, l’authenticité et la sécurité des données est un enjeu majeur dans nos sociétés modernes tournées résolument vers le tout numérique. La quantité de données générées quotidiennement par les différentes activités économiques et sociétales ne cesse d’augmenter. Le stockage local de ses données est une solution de moins en moins pertinente depuis plusieurs années, au profit d’un stockage externalisé accessible en ligne. En effet, le stockage de données accessible en ligne offre différents avantages comme ceux de décharger le propriétaire des données des problématiques de dimensionnement et maintenance des supports de stockage.

Les systèmes de stockage en ligne des principaux acteurs actuels sont pour la plupart proposés sous la forme d’un service informatique en nuage, dit « cloud service » en anglais, mais restent construits sur un modèle centralisé client-serveur. Le modèle centralisé a des avantages, mais il a aussi des fragilités inhérentes, comme par exemple son exposition aux attaques, aux défaillances du matériel, aux incendies et autres impondérables, et il requiert la confiance du client en un seul acteur. Par ailleurs, les gros acteurs du stockage de données en ligne sont ceux qui généralement inspirent la plus grande confiance des clients, ce qui conduit à une concentration qui fragilise d’autant plus le stockage externe centralisé en tant que solution globale.

Dans un système de stockage décentralisé, le stockage des données est assuré de manière distribuée, avec des duplications, par un réseau de serveurs qui collaborent selon un protocole de type dit « P2P » (pour « Peer-to-Peer » en anglais). Un tel système est structurellement plus robuste, car il n’a pas de point de défaillance unique. Ainsi, par exemple, un réseau de stockage décentralisé bâti sur le protocole « IPFS » (pour « InterPlanetary File System® » en anglais) offre un fonctionnement robuste et efficace, sans nécessité de confiance mutuelle entre les serveurs nœuds du réseau. Le stockage décentralisé des données repose sur un très grand nombre de serveurs nœuds n’ayant aucune relation particulière entre eux, hormis le fait d’héberger un même protocole de type « P2P ». Les serveurs nœuds peuvent être incités à un comportement vertueux par l’octroi de récompenses pour leur travail, par exemple sous forme de jetons monétisables, comme dans le réseau de stockage décentralisé Filecoin® ou Aleph.im®. Le stockage décentralisé apparaît comme une solution promise à un bel avenir, et cela d’autant plus qu’elle est avantageuse pour les clients sur le plan économique. Dans les serveurs nœuds, la confidentialité des données stockées peut être assurée par un cryptage procuré par le protocole. Ce cryptage est suffisant pour les applications usuelles manipulant des données peu critiques. Des inquiétudes existent cependant pour certaines applications requérant une sécurité maximale au regard des risques de perte, modification, divulgation ou fuite des données.

Les professionnels de l’industrie du numérique se doivent de proposer des solutions nouvelles répondant aux exigences croissantes en matière de sécurité des données. En effet, une large part des actes délictueux et des atteintes aux droits des personnes et à leur vie privée trouvent aujourd’hui leur origine dans le piratage, le vol et la falsification de données et de documents à travers les réseaux de communication de données, comme Internet. La technologie de la chaîne de blocs, dite « blockchain » en anglais, se développe depuis quelques années et offre des possibilités d’application intéressantes pour la certification, en éliminant la nécessité de tiers de confiance. Ainsi, le demandeur a divulgué dans sa demande au brevet US2020099511A1, et brevet délivré US10715313B2, un système de certification et publication de documents et de données de petite taille, comme des diplômes, qui met en œuvre une certification par chaîne de blocs. Cependant, les chaînes de blocs ne sont pas conçues pour stocker dans leurs blocs des données de masse accessibles en ligne. En effet, leur capacité d’enregistrement de données est limitée et les coûts des transactions d’enregistrement sont généralement dissuasifs.

Par ailleurs, le droit à l’oubli des utilisateurs des systèmes de stockage décentralisée doit pouvoir être garanti pour une conformité notamment avec le règlement européen sur la protection des données dit « RGPD ».

Il est souhaitable de proposer une solution de stockage décentralisé et de partage de fichiers numériques certifiés ne présentant pas les inconvénients susmentionnés de la technique antérieure, offrant de nouvelles possibilités à un coût accessible pour des applications de stockage et de gestion documentaire exigeant une haute sécurité des données.

Selon un premier aspect, l’invention concerne un procédé mis en œuvre par ordinateur dans un système informatique de stockage décentralisé et de partage de fichiers numériques, le système étant déployé à travers un réseau étendu de communication de données, ayant des ressources matérielles et logicielles localisées dans au moins un serveur informatique accessible à travers le réseau et coopérant avec un réseau de stockage décentralisé et un réseau de chaîne de blocs. Conformément à l’invention, le procédé comprend A) une génération de clés de cryptage/décryptage et signature de données de fichier numérique comprenant au moins une clé de permanence effaçable, les clés étant associées à un compte d’utilisateur du système et la clé de permanence effaçable étant effaçable à l’initiative de l’utilisateur pour une interdiction définitive d’accès à des données de fichier numérique de celui-ci ; B) un processus d’enregistrement d’un fichier numérique et de métadonnées descriptives dans le réseau de stockage décentralisé, exécuté à l’initiative d’un utilisateur du système et comprenant les étapes de B-1) crypter et signer le fichier numérique, enregistrer dans le réseau de stockage décentralisé le fichier numérique crypté et signé accompagné de preuves d’authentification et générer des premières données d’accès pour un accès au fichier numérique, et B-2) regrouper les métadonnées et les premières données d’accès, crypter et signer le regroupement obtenu de métadonnées et premières données d’accès, enregistrer dans le réseau de stockage décentralisé le regroupement de métadonnées et premières données d’accès crypté et signé accompagnées de preuves d’authentification et générer des deuxièmes données d’accès pour un accès au regroupement de métadonnées et premières données d’accès ; et C) un processus d’accès aux métadonnées et au fichier numérique enregistrés dans le réseau de stockage décentralisé, exécuté à l’initiative d’un utilisateur du système possédant les deuxièmes données d’accès et comprenant les étapes de C-1), à partir desdites deuxièmes données d’accès, récupérer dans le réseau de stockage décentralisé le regroupement de métadonnées et premières données d’accès crypté et signé accompagnées de leurs preuves d’authentification, vérifier sa signature et décrypter celui-ci, C-2) générer et afficher, ou donner accès à, des données d’un certificat descriptif de dépôt de fichier numérique intégrant les métadonnées décryptées obtenues à l’étape C-1), des données de certification du fichier numérique récupérées dans le réseau de chaîne de blocs et un lien d’accès au fichier numérique qui est dérivé des premières données d’accès décryptées obtenues à l’étape C-1), et C-3), suite à une action d’un utilisateur dudit système sur le lien d’accès présent dans le certificat descriptif de dépôt de fichier numérique, et à partir des premières données d’accès obtenues l’étape à C-1), récupérer dans le réseau de stockage décentralisé le fichier numérique crypté et signé accompagné de ses preuves d’authentification, vérifier sa signature et décrypter celui-ci pour une fourniture à l’utilisateur.

Selon une caractéristique particulière du procédé, le processus d’enregistrement de fichier numérique B) comprend également une étape, exécutée après l’étape B-2), de B-3) regrouper les deuxièmes données d’accès et des données de conditions d’accès/partage pour le certificat descriptif de dépôt de fichier numérique incluant le lien d’accès au fichier numérique, crypter et signer le regroupement obtenu de deuxièmes données d’accès et données de conditions d’accès/partage, enregistrer dans le réseau de stockage décentralisé le regroupement de deuxièmes données d’accès et données de conditions d’accès/partage crypté et signé accompagnées de preuves d’authentification et générer des troisièmes données d’accès pour un accès au regroupement de deuxièmes données d’accès et données de conditions d’accès/partage ; et le processus d’accès C) comprend également une étape complémentaire de C-0) récupérer, à partir des troisièmes données d’accès, le regroupement de deuxièmes données d’accès et données de conditions d’accès/partage crypté et signé accompagnées de leurs preuves d’authentification dans le réseau de stockage décentralisé ou le réseau de chaîne de blocs, vérifier sa signature et décrypter celui-ci, interdire ou autoriser la poursuite de l’exécution du processus d’accès C) en fonction des données de conditions d’accès/partage.

Selon une autre caractéristique particulière du procédé, le certificat descriptif de dépôt de fichier numérique est affiché sous la forme d’une page hypertexte de type dit « HTML » ou est restitué sous la forme de données brutes.

Selon encore une autre caractéristique particulière du procédé, la génération de clés A) comprend une génération d’au moins une clé permanente et d’au moins une clé intermédiaire pour les opérations de cryptage/décryptage, la clé permanente, la clé intermédiaire et la clé de permanence effaçable étant utilisées conjointement pour la dérivation d’une clé de cryptage/décryptage.

Selon encore une autre caractéristique particulière du procédé, la génération de clés A) comprend une génération d’au moins une paire de clé privé/clé publique pour les opérations de signature, ou une génération d’au moins une paire de clé privé/clé publique pour les opérations de signature qui sont accessibles via des clés externes d’utilisateur.

Selon encore une autre caractéristique particulière du procédé, au moins une des clés est conservée dans une boîte noire transactionnelle dite « HSM » incluse dans les ressources du système.

L’invention concerne aussi un système informatique de stockage décentralisé et de partage de fichiers numériques, le système étant déployé à travers un réseau étendu de communication de données, ayant des ressources matérielles et logicielles localisées dans au moins un serveur informatique accessible à travers le réseau et coopérant avec un réseau de stockage décentralisé et un réseau de chaîne de blocs. Conformément à l’invention, le système comprend des moyens agencés de façon à permettre la mise en œuvre du procédé décrit brièvement ci-dessus.

L’invention concerne aussi un ensemble comprenant un système informatique de stockage décentralisé et de partage de fichiers numériques comme décrit ci-dessus, un réseau de stockage décentralisé et un réseau de chaîne de blocs, le réseau de chaîne de blocs coopérant avec le système à travers des modules logiciels, dits « contrats intelligents », pour l’enregistrement et la lecture dans le réseau de chaîne de blocs de données de certification associées aux fichiers numériques.

Selon une autre caractéristique particulière de l’ensemble, le réseau de chaîne de blocs comprend une machine virtuelle pour l’exécution des modules logiciels de contrats intelligents.

Selon encore une autre caractéristique particulière de l’ensemble, le réseau de stockage décentralisé est un réseau implémentant un protocole de type dit « IPFS ».

L’invention procure de nombreux avantages pour le stockage des données, en termes de sécurité, de pérennité, de souveraineté et d’indépendance.

Concernant la sécurité, les fichiers ne peuvent être ni modifiés, ni perdus. Ils ne peuvent être consultés ou partagés qu’avec les habilitations requises, celles-ci pouvant être contrôlées par tout système d’identification, y compris des identifiants décentralisés.

Concernant la pérennité, les fichiers peuvent être conservés sans modification possible et avec une preuve de leur authenticité sur une longue période, a minima les périodes légales d’archivage.

Concernant la souveraineté, les fichiers ne peuvent pas être consultés par le service d’hébergement des données utilisé. Le stockage peut ainsi être mis en œuvre facilement, par exemple, au sein d’un environnement de type consortium d’acteurs ou d’un système en nuage, comme un système en nuage européen.

Concernant l’indépendance, le stockage n’est pas dépendant d’un acteur ou d’un opérateur centralisé, comme un opérateur de service de stockage en nuage ou un opérateur de coffre-fort numérique.

De manière générale, l’invention procure une technologie de création d’un registre virtuel sous la forme d’un “coffre-fort décentralisé” protégé par des méthodes cryptographiques. On notera que l’invention ne concerne pas la conception ou le déploiement d’une technologie de service de stockage en nuage ou d’hébergement, mais la fourniture d’un service compatible avec tout système en nuage, hébergeur et système d’information.

L’invention couvre de nombreux besoins et trouve des applications de type « BtoC », « BtoB » ou « BtoG ». Ainsi, par exemple, dans une application « BtoC », les individus ont accès à un espace d’archivage sur un stockage distribué public, en d’autres termes, à un service de type Dropbox® à l’épreuve du temps, du piratage ou de la collecte de données. Dans une application « BtoB », par exemple dans une entreprise multisite, les utilisateurs ont accès à un « coffre-fort partagé » multisites, ou multiserveurs, permettant le stockage, l’authentification et la sécurisation de données stratégiques et/ou sensibles, sans avoir à modifier les process métiers utilisant ces données.

Dans une application « BtoG », par exemple dans un organisme public national ou international, l’invention autorise la création d’un “registre partagé souverain” permettant la mise en sécurité et l’exploitation de données ou documents sensibles.

D’autres avantages et caractéristiques de la présente invention apparaîtront plus clairement à la lecture de la description détaillée ci-dessous de plusieurs formes de réalisation particulières de l’invention, en référence aux dessins annexés, dans lesquels :

La est un bloc-diagramme montrant l’architecture générale d’une forme de réalisation particulière d’un système informatique de stockage décentralisé et de partage de fichiers numériques certifiés selon l’invention.

La est un bloc-diagramme illustratif du processus de stockage d’un fichier numérique, conformément au procédé de stockage décentralisé et de partage de fichiers numériques certifiés selon l’invention.

La est un bloc-diagramme illustratif du processus d’accès à un fichier numérique stocké, conformément au procédé de stockage décentralisé et de partage de fichiers numériques certifiés selon l’invention.

Dans la description qui suit, certains détails spécifiques indiqués, tels que des techniques, des protocoles, des moyens fonctionnels particuliers et autres, sont fournis pour faciliter la compréhension de l’invention et ne doivent pas être considérés comme limitatifs. Par ailleurs, des méthodes, dispositifs, technologies et autres bien connus de l’homme du métier sont omis afin de ne pas obscurcir la description de l’invention avec des détails inutiles à sa compréhension.

De manière générale, on notera que les termes « fichier numérique » doivent être interprétés ici dans le sens le plus large et recouvrent tous types de données, y compris des données binaires, comme des images et des documents pdf®, et les fichiers multimédia.

En référence à la , il est décrit maintenant ci-dessus l’architecture générale, matérielle et logicielle, d’une forme de réalisation particulière DSS d’un système informatique de stockage décentralisé et partage de fichiers numériques certifiés selon l’invention.

Comme représenté schématiquement à la , le système informatique de stockage décentralisé et partage de fichiers numériques certifiés DSS est déployé via un réseau étendu de communication de données IP, typiquement ici le réseau Internet, et utilise des ressources matérielles et logicielles accessibles via le réseau IP.

Le système DSS interagit avec une pluralité de dispositifs informatiques d’utilisateur U_DIS et fait appel non exclusivement pour son fonctionnement à un réseau de stockage décentralisé DSN et à un réseau de chaîne de blocs BKC.

Dans l’exemple de réalisation de la , le système informatique de stockage décentralisé et partage de fichiers numériques certifiés DSS utilise des ressources logicielles et matérielles d’un fournisseur de services informatiques en nuage SCP dit « cloud service provider » en anglais. Un système logiciel SW du système DSS est hébergé ici dans au moins un serveur informatique SRC du fournisseur de services informatiques en nuage SCP. Plus précisément, le système logiciel SW est hébergé dans un dispositif de stockage de données D_ST dédié tel qu’un ou plusieurs disques durs.

Le serveur informatique SRC comprend un processeur PU incluant une ou plusieurs unités de traitement dites « CPU » (non représentées) et des mémoires volatiles et non-volatiles dites « RAM » et « ROM » (non représentées). Le processeur PU est en communication de données et coopère notamment avec le dispositif de stockage de données D_ST et une boîte noire transactionnelle HSM, dite « Hardware Security Module » ou « HSM » en anglais, et des périphériques matériels conventionnels tels que les interfaces réseau NI et d’autres dispositifs (non représentés). Comme bien connu de l’homme du métier, une boîte noire transactionnelle, dite simplement « module HSM » par la suite, est un dispositif cryptographique inviolable offrant une sécurité maximale pour la génération, le stockage et la protection des clefs cryptographiques.

Par ailleurs, on notera qu’une base de données cryptée DHS dédiée à la gestion de l’historique des données pourra être prévue dans le système DSS selon l’invention, par exemple, à travers un serveur de type PostgreSQL®.

Le système logiciel SW contenu dans le dispositif de stockage de données D_ST autorise la mise en œuvre du système informatique de stockage décentralisé et partage de fichiers numériques certifiés selon l’invention par l’exécution d’instructions de code de programme par le processeur PU.

Dans le système informatique de stockage décentralisé et partage de fichiers numériques certifiés DSS selon l’invention, différents systèmes et dispositifs informatiques communiquent et interagissent en échangeant des instructions et des données à travers le réseau internet IP. Ainsi, au moins une entité administratrice ADMIN et des utilisateurs USER sont connectés au système DSS à travers leurs systèmes ou dispositifs informatiques, à savoir, A_DIS et U_DIS, respectivement. Les utilisateurs USER accèdent au système DSS au moyen de leurs ordinateurs, tablettes et/ou smartphones afin de stocker et partager des fichiers numériques certifiés. Les utilisateurs sont émetteurs et/ou destinataires des fichiers numériques qui sont stockés par le système DSS dans le réseau de stockage décentralisé DSN. La chaîne de blocs BKC est utilisée par le système DSS notamment pour la certification des fichiers numériques, la vérification des habilitations et de l’identité de l’utilisateur USER.

Le système logiciel SW comprend un module logiciel USER_MANAG ayant à charge la création, la gestion et la sécurité des comptes d’utilisateur sous la supervision de l’entité administratrice ADMIN du système DSS. Selon les applications, des procédures KYC/KYB (pour « Know Your Customer » / « Know Your Business ») seront mises en place, de façon à ce que le système DSS puisse certifier l’origine d’un fichier numérique, c’est-à-dire l’utilisateur émetteur de celui-ci. A la création d’un compte d’utilisateur, le module logiciel USER_MANAG commande la mise en place dans la chaîne de blocs BKC de programmes dits « contrats intelligents » USER_SC liés au compte d’utilisateur, et valide la génération de clés qui sont explicitées par la suite.

Les utilisateurs ont accès aux services du système DSS selon l’invention typiquement à travers une plateforme web WEB_PLATF, ayant une adresse web « URL » (pour « Uniform Resource Locator » en anglais), ou à travers une interface de programmation « API » (pour « Application Programmable Interface » en anglais), qui sont implémentées par le système logiciel SW.

Le système logiciel SW comprend également des applications logicielles APPs, typiquement des applications décentralisées, qui gèrent notamment des fonctions de cryptage/décryptage des fichiers, les écritures et lectures dans les réseaux DSN et BKC et d’autres opérations.

Dans cette forme de réalisation particulière, le réseau de chaîne de blocs BKC est typiquement un réseau compatible avec le réseau Ethereum® et sa machine virtuelle dite « EVM » (pour « Ethereum® Virtual Machine » en anglais). La machine virtuelle « EVM » procure dans la chaîne de blocs BKC un ensemble d’instructions de traitement pour l’exécution des contrats intelligents. Pour davantage d’information sur la technologie des chaînes de blocs et des contrats intelligents, on se réfèrera utilement par exemple aux articles « Ethereum: A Next-Generation Generalized Smart Contract and Decentralized Application Platform » (Vitalik Buterin, Ethereum, 2017) et « Ethereum: A Secure Decentralized Generalized Transaction Ledger » (Gavin Wood, Ethereum, 2014.

Comme montré schématiquement à la , différents contrats intelligents SC sont programmés dans le réseau de chaîne de blocs BKC, dont les contrats intelligents d’utilisateur USER_SC susmentionnés et des contrats intelligents ADMIN_VALIDATOR_SC. Les contrats intelligents USER_SC comprennent notamment des contrats USER_CPT, USER_STOR et CREDITS qui interviennent respectivement dans la gestion de l’identité certifiée de l’utilisateur, du stockage décentralisé des fichiers numériques de l’utilisateur et des données de crédit disponible de l’utilisateur pour le paiement en jetons des coûts, notamment, les coûts des transactions avec les réseaux BKC et DSN et les coûts du service fourni par le système DSS. Les contrats intelligents ADMIN_VALIDATOR_SC sont relatifs à l’identité certifiée de l’entité administratrice/ validatrice du système DSS. Dans la présente invention, le caractère immuable des enregistrements effectués dans le réseau de chaîne de blocs BKC et les différentes fonctions mises en place grâce aux contrats intelligents autorisent la certification des fichiers numériques stockés et partagés. On se réfèrera notamment au brevet US10715313B2 de la demanderesse pour davantage de détails sur les mécanismes mis en œuvre dans la certification par chaîne de blocs.

Le réseau de stockage décentralisé DSN est ici du type « IPFS » (pour « InterPlanetary File System® » en anglais). Le protocole de communication « IPFS » gère le stockage des fichiers dans plusieurs nœuds du réseau DSN et offre de meilleures performances comparativement à un stockage centralisé, en termes notamment de vitesse d’écriture/lecture, de latence, de disponibilité et de débit.

D’autres solutions de stockage décentralisé pourront être utilisées selon les applications de l’invention. Ainsi, par exemple, il pourra être utilisé un stockage décentralisé dans un environnement de type « blockchain layer 2 » offrant un stockage de fichiers « hors chaîne ». Les solutions de stockage décentralisé des réseaux tels que Aleph.im®, Bluzelle® et autres sont utilisables aussi dans des applications de l’invention. Par ailleurs, le système d’adressage utilisé pour le stockage des fichiers garantit l’immutabilité de ceux-ci et la possibilité de vérifier leur intégrité. De plus, la duplication du stockage offre une garantie contre la perte ou la non disponibilité des fichiers.

En référence plus particulièrement au bloc-diagramme de la , il est maintenant décrit différentes fonctions accomplies dans le système DSS de l’invention pour l’enregistrement des fichiers numériques dans le réseau de stockage décentralisé DSN. Conformément à l’invention, les fichiers numériques et leurs métadonnées sont enregistrés séparément de manière décentralisée. De plus, des conditions d’accès/partage des fichiers, tels qu’une accessibilité limitée dans la durée, peuvent être établies spécifiquement pour chaque fichier.

Comme visible à la , trois blocs fonctionnels BE0 à BE2 sont essentiellement mis à contribution pour gérer le stockage décentralisé des fichiers numériques et de leurs métadonnées, ainsi que leurs certifications et les conditions d’accès/partage. Dans la suite de la description, il est considéré un fichier numérique F_DAT, ayant des métadonnées M_DAT, appartenant à un utilisateur USER qui ordonne son enregistrement dans le réseau de stockage décentralisé DSN. Le processus exécute ici les blocs fonctionnels BE0 à BE2 successivement comme représenté de manière simplifiée à la .

Conformément au procédé de l’invention, dans une première phase, le bloc fonctionnel BE0 traite le fichier numérique F_DAT, l’enregistre dans le réseau de stockage décentralisé DSN et délivre en sortie des données d’accès CDA0 pour un accès au fichier numérique F_DAT enregistré. Contrairement aux traitements ultérieurs effectués par les blocs BE1 et BE2, les données d’accès CDA0 contiennent une adresse AD0 et non une clé, comme AK1 ou AK1_L mentionnées plus bas, ceci afin de garantir une non exposition d’un lien permanent d’accès au fichier numérique F_DAT. Ce principe de non exposition consiste en une méthode d’appel particulière des données d’accès CDA0 contenant une vérification de la bonne validité de la clé AK1 ou AK1_L contenue dans des données d’accès CDA1 ou CDA1_L, mentionnées plus bas, et donnant accès à la fonction de téléchargement du fichier numérique F_DAT via les données d’accès CDA0.

Dans une deuxième phase, des métadonnées M_DAT fournies par l’utilisateur USER et descriptives du fichier numérique F_DAT sont regroupées avec les données d’accès CDA0 par une fonction RG1. Le regroupement obtenu (M_DAT, CDA0) est ensuite traité par le bloc fonctionnel BE1 et transmis pour un enregistrement dans le réseau de stockage décentralisé DSN, ou le réseau de chaîne de blocs BKC, selon la forme de réalisation. Le bloc fonctionnel BE1 délivre en sortie des données d’accès CDA1 nécessaires pour un accès aux métadonnées M_DAT et aux données d’accès CDA0 enregistrées ensemble dans le réseau DSN.

Dans une troisième phase, le bloc fonctionnel BE2 gère en premier lieu l’ajout éventuel par l’utilisateur USER d’une ou plusieurs conditions d’accès/partage CDP pour l’accès au fichier numérique F_DAT et à ses métadonnées M_DAT qui ont été stockés dans le réseau de stockage décentralisé DSN. L’utilisateur USER peut ainsi, par exemple, définir une période ou durée d’accessibilité, limiter cette accessibilité à un ou plusieurs autres utilisateurs du système DSS et définir différentes autres conditions liées à l’authentification des tiers utilisateurs USER avec lesquels il partage ses données. L’utilisation de cette fonctionnalité par l’utilisateur USER est soumise à une signature préalable S_USER par celui-ci au moyen d’une clé privée PR qui est explicitée plus bas.

Dans le bloc fonctionnel BE2, les conditions d’accès/partage CDP sont regroupées avec les données d’accès CDA1 par une fonction RG2, puis le regroupement obtenu (CDP, CDA1) est traité et enregistré dans le réseau de stockage décentralisé DSN. Le bloc fonctionnel BE2 délivre en sortie des données d’accès désignées CDA1(L). Une fonction de détection CD1 et une fonction de sélection SEL1, représentées schématiquement, déterminent les données d’accès CDA1(L). Ainsi, lorsque la fonction de détection CD1 détecte qu’aucune condition d’accès/partage CDP n’a été établie par l’utilisateur USER, l’entrée E1 de la fonction de sélection SEL est ouverte et les données d’accès CDA1(L) sont déterminées comme étant CDA1, soit CDA1(L)=CDA1. Dans le cas contraire, c’est l’entrée E2 de la fonction de sélection SEL qui est ouverte et les données d’accès CDA1(L) sont déterminées comme étant des données d’accès avec limitation CDA1_L, soit CDA1(L)= CDA1_L. Les données d’accès CDA1(L) sont les seules données d’accès rendues disponibles aux utilisateurs USER pour un accès ultérieur au fichier numérique F_DAT et à ses métadonnées M_DAT.

Les blocs fonctionnels BE0, BE1 et BE2 traitent le fichier numérique F_DAT, le regroupement de données (M_DAT, CDA0) et le regroupement de données (CDP, CDA1) avec des algorithmes de cryptage et signature CS0, CS1 et CS2, respectivement. Les algorithmes CS0, CS1 et CS2 requièrent chacun trois clés MK, PK et IK pour le cryptage et la clé PR susmentionnée pour la signature.

La clé MK est une clé privée permanente associée au compte d’utilisateur. La clé PK et la clé IK sont respectivement une clé privée de permanence et une clé privée intermédiaire qui sont propres au fichier numérique traité F_DAT traité par l’algorithme CS0 ou aux regroupements de données (M_DAT, CDA0) et (CDP, CDA1) traités respectivement par les algorithmes CS1 et CS2.

La clé PR est permanente et est associée au compte d’utilisateur, la clé PR étant ici la clé privée d’une paire PR/PU, avec PU étant une clé publique. Dans une forme de réalisation particulière, les clés PR et PU pourront être respectivement la clé privée et l’adresse du compte d’utilisateur dans le réseau de chaîne de blocs BKC.

Les clés privées MK et PK sont générées typiquement par un générateur de nombres aléatoires de haute performance qui est intégré dans le module HSM. Au moins l’une des clés privées MK, PK, est gardée en toute sécurité dans ce module HSM. La clé intermédiaire IK est aussi un nombre aléatoire fourni par le générateur de nombres aléatoires du module HSM. Les clés PR et PU seront typiquement générées par un algorithme de génération aléatoire, de préférence hébergé dans le module HSM, et sont utilisées pour la signature des données qui est décrite plus bas. La clé privée PR est gardée typiquement dans le module HSM. Dans une forme de réalisation particulière, il est rendu possible l’utilisation de clés externes d’utilisateur, non générées par le système DSS, qui sont déjà en possession de l’utilisateur USER et qui lui permettent d’accéder à la paire de clés privé/clé publique PR/PU susmentionnées générées par le système DSS.

La clé de permanence PK est effacée lorsque l’utilisateur USER propriétaire du fichier numérique F_DAT le demande par une commande ERASE, en faisant valoir son droit à l’oubli. L’effacement de la clé de permanence PK rend impossible la lecture du fichier numérique F_DAT enregistré dans le réseau DSN, ainsi que de ses métadonnées M_DAT, comme cela apparaîtra plus clairement par la suite.

Dans chacun des algorithmes CS0, CS1 et CS2, une clé de cryptage KAES dédiée est calculée avec une fonction de dérivation de clé K_D à partir des clés MK, PK et IK correspondantes. Dans les algorithmes CS0, CS1 et CS2, les clés de cryptage KAES calculées sont utilisées pour le cryptage du fichier numérique F_DAT, du regroupement de données (M_DAT, CDA0) et du regroupement de données (CDP, CDA1), respectivement. Ainsi, une fonction de cryptage CRYPT, réalisant par exemple un cryptage symétrique au standard AES (pour « Advanced Encryption Standard ») avec 256 bits, est utilisée pour crypter le fichier numérique F_DAT, le regroupement de données (M_DAT, CDA0) et le regroupement de données (CDP, CDA1). Les clés IK et KAES sont effacées par les algorithmes CS0, CS1 et CS2 après chaque opération de cryptage ou de décryptage.

Le fichier numérique F_DAT, le regroupement de données (M_DAT, CDA0) et le regroupement de données (CDP, CDA1), auxquels sont adjoints des données ID_PROOF0 et ID_PROOF1, chacun signés numériquement avant d’être transmis pour enregistrement au réseau de stockage décentralisé DSN. Les données ID_PROOF0, ID_PROOF1, contiennent l’ensemble des informations nécessaires à l’identification de l’utilisateur USER émetteur, notamment sa clé publique PU, ainsi qu’à l’authentification par empreinte dite « hash », comme décrit ci-après, du fichier F_DAT et du fichier crypté F_DAT_C, ou bien des métadonnées M_DAT et des métadonnées cryptées M_DAT_C, selon l’étape considérée. Typiquement, dans chacun des algorithmes CS0, CS1 et CS2, une fonction de signature numérique SIGN exécute une fonction de hachage sur les données F_DAT et les données cryptées F_DAT_C, (M_DAT, CDA0)_C et (CDP, CDA1)_C du fichier numérique F_DAT, du regroupement de données (M_DAT, CDA0, ID_PROOF0) et du regroupement de données (CDP, CDA1, ID_PROOF1), respectivement. La fonction de hachage fournit un condensat, dit empreinte ou « hash », des données F_DAT et données cryptées F_DAT_C, (M_DAT, CDA0)_C, ID_PROOF0) ou (CDP, CDA1)_C, ID_PROOF1) selon l’algorithme CS0, CS1 ou CS2 considéré, respectivement, qui est ensuite crypté avec la clé privée PR correspondante. L’empreinte cryptée avec la clé privée PR est la signature qui est jointe aux données cryptées F_DAT_C, (M_DAT, CDA0)_C ou (CDP, CDA1)_C selon l’algorithme CS0, CS1 ou CS2 considéré, respectivement, pour être enregistrée conjointement à celles-ci dans le réseau de stockage décentralisé DSN, constituant ainsi le fichier complet de preuves d’authenticité de chaque enregistrement sur le réseau DSN ou BKC, noté PROOF0, PROOF1 ou PROOF2 selon l’étape considérée. Les données cryptées et signées (F_DAT_C ; PROOF0), ((M_DAT, CDA0)_C ; PROOF1) et ((CDP, CDA1)_C ; PROOF2) sont transmises pour enregistrement au réseau de stockage décentralisé DSN qui délivre en sortie des adresses d’enregistrement AD0, AD1 et AD2, respectivement.

De manière générale, les réseaux de stockage décentralisé, comme le réseau DSN ici, incorporent une couche de cryptage/décryptage dans l’interface d’entrée/sortie des données. Ainsi, les données transmises en entrée à un réseau de stockage décentralisé pour un enregistrement sont cryptées par la couche de cryptage/décryptage avant d’être transmises à des nœuds du réseau qui assurent leur stockage, et sont décryptées par cette même couche de cryptage/décryptage avant d’être délivrées en sortie par le réseau de stockage décentralisé. Les opérations de cryptage internes du réseau de stockage décentralisé ne doivent bien évidemment pas être confondues par le lecteur avec les opérations de cryptage et signature réalisées par les blocs fonctionnels BE0, BE1 et BE2 et décrites plus haut. Dans la présente invention, les opérations de cryptage et signature réalisées par les blocs fonctionnels BE0, BE1 et BE2 sécurisent les données contre une violation lors de leur stockage décentralisé. Dans la présente invention, compte-tenu que les données sont signées, lorsque les données sont récupérées en sortie du réseau de stockage décentralisé, une vérification de la signature des données, incluant la signature des preuves (PROOF) permet au processus de savoir si les données restituées sont les mêmes, ou pas, que celles précédemment transmises pour stockage.

En référence toujours à la , les algorithmes CS0, CS1 et CS2 comprennent également différentes routines logicielles MGTE qui interagissent avec les fonctions et les composants impliqués, notamment pour gérer les échanges avec le réseau de stockage décentralisé DSN, les contrats intelligents USER_SC des utilisateurs USER dans le réseau de chaîne de blocs BKC et le module HSM, et pour établir et délivrer en sortie les données d’accès CDA0 et CDA1(L) susmentionnées Les adresses d’enregistrement AD0, AD1 et AD2 susmentionnées sont réceptionnées par les routines logicielles MGTE. Les routines logicielles MGTE établissent les données d’accès CDA0, CDA1 et CDA1_L sous la forme d’un lien « URL », ou adresse web, et d’une clé d’accès AK, notée AK0, AK1 et AK1_L respectivement pour CDA0, CDA1 et CDA1_L. Typiquement, la clé d’accès AK renvoie vers une table coffre-fort idData sécurisée via le module HSM et vers la clé intermédiaire IK. La table coffre-fort idData conserve la clé PK, ainsi que l’adresse d’enregistrement AD (AD0, AD1 ou AD3) dans le réseau de stockage décentralisé DSN, ou le réseau de chaîne de blocs BKC, et des identifiants de contrats intelligents d’utilisateur USER_SC et de transactions d’enregistrement dans le réseau de chaîne de blocs BKC. Les interactions des routines logicielles MGTE avec les contrats intelligents USER_SC permettent notamment au processus de vérifier les droits de l’utilisateur USER à utiliser le système DSS et d’enregistrer dans la chaîne de blocs BKC les informations prouvant qu’il est bien à l’origine, ou propriétaire, des données enregistrées dans le réseau de stockage décentralisé DSN. Ces informations enregistrées dans la chaîne de blocs BKC autorisent une certification par le système DSS selon l’invention des fichiers numériques stockés. En d’autres termes, le système DSS est en mesure de certifier que le fichier numérique restitué après stockage est bien dans son intégralité le fichier numérique enregistré par l’utilisateur USER, à telle date et avec d’autres précisions et des preuves selon l’application.

En référence plus particulièrement au bloc-diagramme de la , il est maintenant décrit différentes fonctions accomplies dans le système DSS de l’invention pour l’accès aux fichiers numériques enregistrés dans le réseau de stockage décentralisé DSN.

Comme visible à la , trois blocs fonctionnels BL2 à BL0 sont essentiellement mis à contribution pour gérer l’accès aux fichiers numériques et à leurs métadonnées stockées dans le réseau de stockage décentralisé DSN, ainsi qu’aux conditions d’accès/partage et aux données de certification. Le processus exécute ici les blocs fonctionnels BL2 à BL0 successivement, comme représenté de manière simplifiée à la . Le bloc fonctionnel BL2 récupère et gère les conditions d’accès/partage CDP et est exécuté lorsque le processus détecte que de telles conditions ont été établies lors de l’enregistrement du fichier numérique F_DAT et de ses métadonnées M_DAT.

Des algorithmes de vérification de signature numérique et décryptage DS2, DS1 et DS0 sont prévus dans les blocs fonctionnels BL2, BL1 et BL0 pour traiter les données cryptées et signées ((CDP, CDA1)_C ; PROOF2), ((M_DAT, CDA0)_C ; PROOF1) et (F_DAT_C ; PROOF0), respectivement, après lecture de celles-ci dans le réseau de stockage décentralisé DSN. Dans les algorithmes de vérification de signature numérique et décryptage DS2, DS1 et DS0, une fonction de vérification de signature numérique V_SIGN exécute son traitement sur les données cryptées et signées ((CDP, CDA1)_C ; PROOF2), ((M_DAT, CDA0)_C ; PROOF1) et (F_DAT_C ; PROOF0), respectivement, avant leur décryptage par une fonction de décryptage DCRYP.

Typiquement, dans les algorithmes DS2, DS1 et DS0, la fonction de vérification de signature numérique V_SIGN récupèrent les signatures SIG2, SIG1 et SIG0 qui sont jointes aux données cryptées (CDP, CDA1)_C, (M_DAT, CDA0)_C et F_DAT_C, respectivement. Dans les algorithmes DS2, DS1 et DS0, la fonction V_SIGN déchiffre les signatures SIG2, SIG1 et SIG0 au moyen de la clé publique PU susmentionnée pour obtenir les empreintes originales correspondantes des données cryptées (CDP, CDA1)_C, (M_DAT, CDA0)_C et F_DAT_C, respectivement. Ces empreintes originales sont ensuite comparées à des empreintes locales correspondantes obtenues par la fonction V_SIGN en appliquant une fonction de hachage, identique à celle utilisée par la fonction de signature numérique SIGN (cf. ), aux données cryptées (CDP, CDA1)_C, (M_DAT, CDA0)_C et F_DAT_C, respectivement. Les données cryptées (CDP, CDA1)_C, (M_DAT, CDA0)_C ou F_DAT_C considérées sont validées par la fonction V_SIGN comme étant identiques à celles enregistrées initialement dans le réseau DSN lorsque l’empreinte originale et l’empreinte locale correspondante coïncident.

Dans les algorithmes DS2, DS1 et DS0, la fonction de décryptage DCRYP décrypte les données cryptées (CDP, CDA1)_C, (M_DAT, CDA0)_C et F_DAT_C transmises par la fonction de vérification de signature numérique V_SIGN, respectivement. La clé de cryptage KAES susmentionnée, utilisée pour le cryptage des données, est nécessaire pour le décryptage de celles-ci. La clé de cryptage KAES est calculée avec la fonction de dérivation de clé K_D à partir des clés MK, PK et IK correspondantes qui sont récupérées. Après chaque opération de décryptage, les clés IK et KAES sont effacées par les algorithmes DS2, DS1 et CD0. Si la clé de permanence PK a été effacée par l’utilisateur USER propriétaire du fichier numérique F_DA, faisant valoir son droit à l’oubli, au moyen de la commande ERASE (cf. ), la clé de cryptage KAES n’est pas calculable et le fichier numérique F_DAT et ses métadonnées M_DAT sont alors définitivement inaccessibles.

Conformément au procédé de l’invention, le processus de téléchargement des métadonnées M_DATA et du fichier numérique F_DAT se déroule en deux phases, déclenchées chacune par un clic d’un utilisateur USER sur un lien « URL » de données d’accès.

Comme représenté schématiquement à la , le processus de téléchargement est lancé par un premier clic CL1 de l’utilisateur USER sur un lien « URL » des données d’accès CDA1(L). Cette l’adresse web « URL » est celle d’une page hypertexte « HTML » de consultation d’un certificat descriptif de dépôt de fichier numérique CDD correspondant au fichier numérique F_DAT, ou bien un lien d’accès direct aux données de ce certificat CDD. Dans une autre forme de réalisation, le certificat descriptif de dépôt de fichier numérique CDD pourra être fourni sous la forme de données brutes. Comme visible dans le certificat CDD illustré à la , celui-ci comprend typiquement du texte, et éventuellement une image, issus des métadonnées M_DAT, ainsi que des données et preuve(s) de certification PROOF et un lien d’accès « URL » (CDA0), associé à une icône de téléchargement LD, pour un téléchargement du fichier numérique F_DAT. Le téléchargement du fichier numérique F_DAT est lancé par un deuxième clic CL2 de l’utilisateur USER sur l’icône de téléchargement LD.

Le traitement effectué par le bloc fonctionnel BL1 et préalablement celui effectué par le bloc fonctionnel BL2 si des conditions d’accès/partage CDP ont été établies sont exécutés pour récupérer les données nécessaires à la construction et l’affichage du certificat CDD. L’utilisateur USER doit être en possession du certificat CDD pour pouvoir lancer le traitement du bloc fonctionnel BL0 et accéder au fichier numérique F_DAT.

Le clic CL1 commande l’exécution d’une fonction de détection CD2 qui détecte si les données d’accès CDA1(L) incorporent ou pas des conditions d’accès/partage CDP. Dans le cas où les données d’accès CDA1(L) n’incorporent pas de conditions d’accès/partage CDP, alors les données d’accès CDA1(L)=CDA1 sont dirigées vers le bloc fonctionnel BL1 par une fonction de sélection SEL2 dont une entrée E3 est ouverte par la fonction de détection CD2. Dans le cas contraire, les données d’accès CDA1(L)=CDA1_L sont dirigées vers le bloc fonctionnel BL2 pour récupérer les conditions d’accès/partage CDP et les données d’accès CDA1 à partir des données cryptées et signées ((CDP, CDA1)_C ; PROOF2) stockées dans le réseau de stockage décentralisé DSN.

Dans le bloc fonctionnel BL2, des routines logicielles MGTL traitent les données d’accès CDA1_L incluant la clé d’accès AK1_L (cf. ) et obtiennent l’adresse d’enregistrement AD2 des données cryptées et signées ((CDP, CDA1)_C ; PROOF2) dans le réseau DSN, ainsi que les clés MK, PK, IK et PU nécessaires aux opérations de vérification de signature et de décryptage de celles-ci, notamment via des interactions avec les contrats intelligents d’utilisateur USER_SC et la table coffre-fort idData susmentionnée.

Avec l’adresse d’enregistrement AD2, les données cryptées et signées ((CDP, CDA1)_C ; PROOF2) sont récupérées par le processus dans le réseau DSN et traitées ensuite par l’algorithme de décryptage et de vérification de signature DS2, comme décrit plus haut. La fonction de décryptage DCRYPT fournit en sortie les conditions d’accès/partage CDP et les données d’accès CDA1.

Dans le cas où les conditions d’accès/partage CDP sont satisfaites par un utilisateur demandeur USER voulant un accès au métadonnées M_DAT et au fichier numérique F_DAT, le processus se poursuit par la transmission des données d’accès CDA1 au bloc fonctionnel BL1, via une entrée E4 ouverte de la fonction de sélection SEL2. Dans le cas contraire, l’accès au métadonnées M_DAT et au fichier numérique F_DAT est refusé à l’utilisateur demandeur USER.

Dans le bloc fonctionnel BL1, les routines logicielles MGTL traitent les données d’accès CDA1 incluant la clé d’accès AK1 (cf. ) et obtiennent l’adresse d’enregistrement AD1 des données cryptées et signées ((M_DAT, CDA0)_C ; PROOF1) dans le réseau DSN, ainsi que les clés MK, PK, IK et PU nécessaires aux opérations de vérification de signature et de décryptage de celles-ci, notamment via des interactions avec les contrats intelligents d’utilisateur USER_SC et la table coffre-fort idData susmentionnée. Les données et preuve(s) de certification PROOF sont également récupérées par les routines logicielles MGTL via les interactions avec les contrats intelligents d’utilisateur USER_SC.

Avec l’adresse d’enregistrement AD1, les données cryptées et signées ((M_DAT, CDA0)_C ; PROOF1) sont récupérées par le processus dans le réseau DSN et traitées ensuite par l’algorithme de décryptage et de vérification de signature DS1, comme décrit plus haut. La fonction de décryptage DCRYPT fournit en sortie les métadonnées M_DAT et les données d’accès CDA0. Les métadonnées M_DAT, les données et preuve(s) de certification PROOF et les données d’accès CDA0 sont intégrées dans le certificat descriptif de dépôt de fichier numérique CDD susmentionné. Dans cet exemple de réalisation, le certificat CDD est présenté à l’utilisateur USER sous la forme de la page de consultation « HTML » susmentionnée.

Le deuxième clic CL2 de l’utilisateur USER sur le lien de l’icône de téléchargement LD dans le certificat CDD provoque la transmission des données d’accès CDA0 au bloc fonctionnel BL0. Les routines logicielles MGTL traitent alors les données d’accès CDA0 incluant la clé d’accès AK0 (cf. ) et obtiennent l’adresse d’enregistrement AD0 des données cryptées et signées (F_DAT_C ; PROOF0) dans le réseau DSN, ainsi que les clés MK, PK, IK et PU nécessaires aux opérations de vérification de signature et de décryptage de celles-ci, notamment via des interactions avec les contrats intelligents d’utilisateur USER_SC et la table coffre-fort idData susmentionnée.

Avec l’adresse d’enregistrement AD0, les données cryptées et signées (F_DAT_C ; PROOF0) sont récupérées par le processus dans le réseau DSN et traitées ensuite par l’algorithme de décryptage et de vérification de signature DS0, comme décrit plus haut. La fonction de décryptage DCRYPT fournit en sortie le fichier numérique F_DAT qui peut alors être téléchargé par le processus à l’intention de l’utilisateur USER.

De manière générale, on notera que l’invention est applicable avec différents types d’implémentation et de gouvernance du stockage décentralisé, qui pourra être de type privé, public ou consortium. Ainsi, par exemple, l’invention est réalisable sous la forme d’un système de fichier distribué de consortium, dit « clustered file system » en anglais, avec une capacité à décider des serveurs nœuds de stockage.

L’invention offre des applications particulièrement intéressantes dans le stockage décentralisé des données, notamment pour la gestion documentaire, lorsque les données doivent être sécurisées, certifiées, inaltérables et accessibles aisément uniquement au porteur d'une clé d’accès cryptographique. L’accès aux données et aux preuves d’authenticité est obtenu simplement par un simple clic sur un lien. La sécurité des données stockées dans les serveurs nœuds est garantie par le cryptage et la signature prévus dans l’invention. Les données stockées ne peuvent être ni lues, ni altérées, ni remplacées dans les serveurs nœuds. En d’autres termes, l’invention procure l’équivalent d’un coffre cryptographique décentralisé utilisable en réseau pour des données accessibles en ligne.

Bien entendu, l’invention ne se limite pas aux exemples de réalisation qui ont été décrits ici à titre illustratif. L’homme du métier, selon les applications de l’invention, pourra apporter différentes modifications et variantes entrant dans le champ de protection de l’invention.

Claims (10)

1. Procédé mis en œuvre par ordinateur dans un système informatique de stockage décentralisé et de partage de fichiers numériques (DSS), ledit système étant déployé à travers un réseau étendu de communication de données (IP), ayant des ressources matérielles et logicielles localisées dans au moins un serveur informatique (SRC) accessible à travers ledit réseau (IP) et coopérant avec un réseau de stockage décentralisé (DSN) et un réseau de chaîne de blocs (BKC), ledit procédé comprenant A) une génération de clés de cryptage/décryptage et signature de données de fichier numérique (MK, PK, IK, PR) comprenant au moins une clé de permanence effaçable (PK, ERASE), lesdites clés étant associées à un compte d’utilisateur (USER_CPT) dudit système (DSS) et ladite clé de permanence effaçable (PK, ERASE) étant effaçable à l’initiative de l’utilisateur (USER) pour une interdiction définitive d’accès à des données de fichier numérique (F_DAT, M_DAT) de celui-ci ; B) un processus d’enregistrement d’un fichier numérique (F_DAT) et de métadonnées descriptives (M_DAT) dans ledit réseau de stockage décentralisé (DSN), exécuté à l’initiative d’un utilisateur (USER) dudit système (DSS) et comprenant les étapes de B-1) crypter et signer (CRYPT, SIGN) ledit fichier numérique (F_DAT), enregistrer dans ledit réseau de stockage décentralisé (DSN) ledit fichier numérique crypté et signé accompagné de preuves d’authentification ((F_DAT_C ; PROOF0)) et générer des premières données d’accès (CDA0) pour un accès audit fichier numérique, et B-2) regrouper lesdites métadonnées (M_DAT) et lesdites premières données d’accès (CDA0), crypter et signer (CRYPT, SIGN) le regroupement obtenu de métadonnées et premières données d’accès ((M_DAT, CDA0)), enregistrer dans ledit réseau de stockage décentralisé (DSN), ou ledit réseau de chaîne de blocs (BKC), ledit regroupement de métadonnées et premières données d’accès crypté et signé accompagnées de preuves d’authentification (((M_DAT, CDA0)_C ; PROOF1)) et générer des deuxièmes données d’accès (CDA1) pour un accès audit regroupement de métadonnées et premières données d’accès ; et C) un processus d’accès auxdites métadonnées (M_DAT) et audit fichier numérique (F_DAT) enregistrés dans ledit réseau de stockage décentralisé (DSN), exécuté à l’initiative (CL1) d’un utilisateur (USER) dudit système (DSS) possédant lesdites deuxièmes données d’accès (CDA1) et comprenant les étapes de C-1), à partir desdites deuxièmes données d’accès (CDA1), récupérer dans ledit réseau de stockage décentralisé (DSN) ledit regroupement de métadonnées et premières données d’accès crypté et signé accompagnées de leurs preuves d’authentification (((M_DAT, CDA0)_C ; PROOF1)), vérifier sa signature (V_SIGN) et décrypter (DCRYP) celui-ci, C-2) générer et afficher, ou donner accès à, des données d’un certificat descriptif de dépôt de fichier numérique (CDD) intégrant lesdites métadonnées décryptées (M_DAT) obtenues à l’étape C-1), des données de certification (PU, PROOF0, PROOF1) dudit fichier numérique (F_DAT) récupérées dans ledit réseau de chaîne de blocs (BKC) ou ledit réseau de stockage décentralisé (DSN) et un lien d’accès (URL, LD) audit fichier numérique (F_DAT) qui est dérivé desdits premières données d’accès décryptées (CDA0) obtenues à l’étape C-1), et C-3), suite à une action (CL2) d’un utilisateur (USER) dudit système (DSS) sur ledit lien d’accès (URL, LD) présent dans ledit certificat descriptif de dépôt de fichier numérique (CDD), et à partir desdites premières données d’accès (CDA0) obtenues à l’étape C-1), récupérer dans ledit réseau de stockage décentralisé (DSN) ledit fichier numérique crypté et signé accompagné de ses preuves d’authentification ((F_DAT_C ; PROOF0)), vérifier sa signature (V_SIGN) et décrypter (DCRYP) celui-ci avant sa fourniture à l’utilisateur (USER).
2. Procédé selon la revendication 1, caractérisé en ce que ledit processus d’enregistrement de fichier numérique B) comprend également une étape, exécutée après ladite étape B-2), de B-3) regrouper lesdites deuxièmes données d’accès (CDA1) et des données de conditions d’accès/partage (CDP) pour ledit certificat descriptif de dépôt de fichier numérique (CDD) incluant ledit lien d’accès audit fichier numérique (F_DAT), crypter et signer (CRYPT, SIGN) le regroupement obtenu de deuxièmes données d’accès et données de conditions d’accès/partage (CDP, CDA1), enregistrer dans ledit réseau de stockage décentralisé (DSN), ou ledit réseau de chaîne de blocs (BKC), ledit regroupement de deuxièmes données d’accès et données de conditions d’accès/partage crypté et signé accompagnées de preuves d’authentification (((CDP, CDA1)_C ; PROOF2)) et générer des troisièmes données d’accès (CDA1_L) pour un accès audit regroupement de deuxièmes données d’accès et données de conditions d’accès/partage; et en ce que ledit processus d’accès C) comprend également une étape complémentaire de C-0) récupérer, à partir desdites troisièmes données d’accès (CDA1_L), ledit regroupement de deuxièmes données d’accès et données de conditions d’accès/partage crypté et signé accompagnées de leurs preuves d’authentification (((CDP, CDA1)_C ; PROOF2)) dans ledit réseau de stockage décentralisé (DSN) ou ledit réseau de chaîne de blocs (BKC), vérifier sa signature (V_SIGN) et décrypter (DCRYP) celui-ci, interdire ou autoriser la poursuite de l’exécution dudit processus d’accès C) en fonction desdits données de conditions d’accès/partage (CDP).
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que ledit certificat descriptif de dépôt de fichier numérique (CDD) est affiché sous la forme d’une page hypertexte de type dit « HTML » ou est restitué sous la forme de données brutes.
4. Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce que ladite génération de clés A) comprend une génération d’au moins une clé permanente (MK) et d’au moins une clé intermédiaire (IK) pour les opérations de cryptage/décryptage (CRYPT, DCRYP), ladite clé permanente (MK), ladite clé intermédiaire (IK) et ladite clé de permanence effaçable (PK) étant utilisées conjointement pour la dérivation d’une clé de cryptage/décryptage (KAES).
5. Procédé selon l’une quelconque des revendications 1 à 4, caractérisé en ce que ladite génération de clés A) comprend une génération d’au moins une paire de clé privé/clé publique (PR/PU) pour les opérations de signature (SIGN, V_SIGN), ou une génération d’au moins une paire de clé privé/clé publique (PR/PU) pour les opérations de signature (SIGN, V_SIGN) qui sont accessibles via des clés externes d’utilisateur.
6. Procédé selon l’une quelconque des revendications 1 à 5, caractérisé en ce qu’au moins une desdites clés (MK, PK, PR) est conservée dans une boîte noire transactionnelle dite « HSM » incluse dans lesdites ressources dudit système (DSS).
7. Système informatique de stockage décentralisé et de partage de fichiers numériques (DSS), ledit système étant déployé à travers un réseau étendu de communication de données (IP), ayant des ressources matérielles et logicielles localisées dans au moins un serveur informatique (SRC) accessible à travers ledit réseau (IP) et coopérant avec un réseau de stockage décentralisé (DSN) et un réseau de chaîne de blocs (BKC), caractérisé en ce qu’il comprend des moyens agencés de façon à permettre la mise en œuvre du procédé selon l’une quelconque des revendications 1 à 6.
8. Ensemble comprenant un système informatique de stockage décentralisé et de partage de fichiers numériques (DSS) selon la revendication 7, un réseau de stockage décentralisé (DSN) et un réseau de chaîne de blocs (BKC), caractérisé en ce que ledit réseau de chaîne de blocs (BKC) coopère avec ledit système (DSS) à travers des modules logiciels (USER_SC), dits « contrats intelligents », pour l’enregistrement et la lecture dans le réseau de chaîne de blocs (BKC) de données de certification (PR) associées auxdits fichiers numériques (F_DAT).
9. Ensemble selon la revendication 8, caractérisé en ce que ledit réseau de chaîne de blocs (BKC) comprend une machine virtuelle pour l’exécution desdits modules logiciels de contrats intelligents (USER_SC, AD/VAL_SC).
10. Ensemble selon la revendication 8 ou 9, caractérisé en ce que ledit réseau de stockage décentralisé (DSN) est un réseau implémentant un protocole de type dit « IPFS ».