Brevet FR3055720A1 — publié le 20180309

PROCEDE DE STOCKAGE SECURISE D'UN FICHIER SOURCE NUMERIQUE. DOMAINE DE L'INVENTION La présente invention concerne le domaine du stockage de données, en particulier le stockage sécurisé. Le stockage de données est bien connu depuis la création des mémoires et a évolué au cours du temps et des besoins. Plusieurs techniques de sauvegarde sont connues, par exemple les architectures dites SLED pour « Single Large Expensive Disk » qui sont fondées sur l'utilisation d'un seul et même disque dur de grande capacité les architectures de type RAID pour « Redundant Array of Independent Disks » ou « regroupement redondant de disques indépendants ». Cependant, une architecture SLED pose notamment un problème de sécurité en ce que les données sont stockées sur un seul disque dur et une architecture RAID comprend un contrôleur RAID qui est lui-même un composant matériel et qui peut tomber en panne. Par ailleurs, il existe une forte tendance aujourd'hui à utiliser le « cloud computing », c'est- à-dire utiliser un fournisseur de service de sauvegarde de données qui stocke les données sur un réseau informatique en nuage dont il gère notamment les accès. Le réseau informatique comprend un ensemble d'au moins un serveur informatique distant, accessible par l'intermédiaire d'un réseau, généralement l'Internet. Dans ce contexte de sous-traitance de stockage de données, la question de confidentialité des données est généralement traitée via des algorithmes de cryptographie, connus en soi et basés sur une clef de cryptage, le risque de sécurité reposant alors le plus souvent sur la clef de cryptage, difficile à mémoriser par un être humain, et qui doit être conservée localement et protégée. La présente invention vise à proposer une nouvelle solution de stockage sécurisé de données tout à fait astucieuse. RESUME DE L'INVENTION 3055720 2 Plus précisément, l'invention concerne selon un premier de ses objets, un procédé de stockage d'un fichier source numérique (E) comprenant un ensemble de données, le procédé comprenant des étapes consistant à : fragmenter ledit fichier source en un ensemble de fragments (Gi), et 5 enregistrer ledit ensemble de fragments (Gi). Il est essentiellement caractérisé en ce que : - L'étape d'enregistrement des fragments (Gi) est mise en oeuvre sur un ensemble d'espaces de stockage, la totalité desdits fragments (Gi) étant enregistrés sur au moins deux 10 espaces de stockage distincts, Et en ce qu'il comprend, préalablement à l'étape de fragmentation, au moins l'une des étapes parmi : ajouter audit fichier source (E) un ensemble de données ou d'octets pour générer un fichier source complété (F) ; et 15 mélanger les octets dudit fichier source complété (F) pour générer un fichier source complété mélangé (G). Les espaces de stockage distincts peuvent être connectés informatiquement entre eux, ou non. 20 On peut prévoir que l'étape d'ajout comprend en outre des étapes consistant à : - lire le fichier source et identifier la typologie des informations contenues dans le fichier source ; - établir un histogramme d'utilisation des valeurs d'octets dans le fichier source ; et 25 - choisir les données ajoutées aléatoirement de façon à ne pas modifier ledit histogramme d'utilisation des octets du fichier source. On peut prévoir que l'étape de mélange consiste à modifier la position de chaque octet dans le fichier source ; de sorte que pour un octet donné, la position dudit octet après mélange 30 selon un algorithme déterministe et réversible est différente de la position dudit octet avant mélange ; l'étape de mélange étant de préférence effectuée après l'étape d'ajout de données et avant l'étape de fragmentation. On peut prévoir en outre une étape consistant à ajouter des informations de service en 35 entête de chaque fragment de l'ensemble de fragments (Gi). On peut prévoir en outre une étape de cryptage consistant à crypter l'un au moins parmi : - le fichier source, et 3055720 3 - au moins l'un des fragments parmi l'ensemble de fragments (Gi). On peut prévoir en outre, à tout moment précédant l'étape de stockage, une étape de masquage consistant à masquer au moins l'un des ensembles parmi : 5 tout ou partie des informations de service, les données du fichier source, les fragments du fichier source, une ou des clé(s) de cryptage, et une ou des clé(s) de décryptage. 10 On peut prévoir en outre une étape consistant à stocker dans un premier espace de stockage au mois l'un parmi : - un ensemble d'au moins une clef de cryptage et - un ensemble d'au moins une clef de décryptage, 15 ledit ensemble d'au moins une clef de cryptage et ledit ensemble d'au moins une clef de décryptage étant utilisés respectivement pour le cryptage et le décryptage des fragments (Gi) stockés dans un deuxième espace de stockage, différent du premier espace de stockage. On peut prévoir en outre une étape consistant à créer, à partir du fichier source, un 20 ensemble d'au moins un fichier de parité. On peut prévoir en outre des étapes consistant à : rapatrier sur un même ordinateur la totalité des fragments correspondant audit fichier source et enregistrés sur lesdits au moins deux espaces de stockage 25 distincts ; réordonner lesdits fragments ; et supprimer les données ajoutées lors de l'étape d'ajout ; et, le cas échéant, décrypter lesdits fragments si ceux-ci ont été cryptés ; et dé-masquer lesdits fragments si ceux-ci ont été masqués. 30 Selon un autre de ses objets, l'invention concerne un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'invention, lorsque ledit programme est exécuté sur un ordinateur. 35 Grâce à la présente invention, - Les prestataires fournissant le stockage en nuage n'ont chacun accès qu'à un fragment du fichier source, ou à un fragment masqué du fichier source, ce qui rend beaucoup plus difficile l'accès aux données du fichier source, même non cryptées ; 3055720 4 - Le décodage, par le fournisseur d'accès à Internet ou par un tiers mal intentionné, des flux de communication entre la station de l'utilisateur et les serveurs des fournisseurs de stockage, même si ces flux sont non cryptés, présente également une complexité accrue, car les échanges se font vers plusieurs adresses différentes et en utilisant des protocoles 5 potentiellement différents ; - Le stockage étant réalisé sur plusieurs espaces de stockage différents, les différentes communications sont exécutées en parallèle de façon de préférence asynchrone, ce qui permet d'optimiser les temps de transit, et qui compense la durée de reconstruction du fichier source ; - Dans le cas où les fragments de fichiers sont stockés en clair dans les nuages, la 10 reconstruction des données ne nécessite qu'un traitement de fusion et d'ordonnancement, ce qui est suffisamment rapide pour être peu gênant pour l'utilisateur et procure un premier niveau de sécurisation ; - Le fait de sélectionner des prestataires de stockage en nuage différents permet de s'affranchir de la dépendance à une seule entité : le vol des identifiants d'un des comptes de 15 stockage ne compromet pas la confidentialité des données ; - Au prix d'une augmentation raisonnable du volume de données transférées, le mécanisme des fichiers de parité permet de s'affranchir de l'inaccessibilité d'un des espaces de stockage ; - outre la confidentialité des données, le procédé permet d'agglomérer les capacités de 20 stockage de différentes offres gratuites ou à faible coût mais limitées en termes de volume, afin de disposer de gros volumes de stockage sécurisés. L'invention peut être mise en oeuvre pour tout espace de stockage. Par exemple, pour une organisation qui possède elle-même un ensemble d'au moins un espace de stockage privé, 25 le stockage peut être effectué sur l'un au moins parmi : - ledit ensemble d'au moins un espace de stockage privé, et - un ensemble d'au moins un nuage. D'autres caractéristiques et avantages de la présente invention apparaîtront plus 30 clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures annexées. DESCRIPTIF DES DESSINS 35 la figure 1 illustre différentes séquences d'étapes d'une pluralité de modes de réalisation du procédé selon l'invention, la figure 2 illustre un mode de réalisation d'un histogramme selon l'invention, et 3055720 5 la figure 3 illustre de façon simplifiée le stockage et la reconstruction d'un fichier selon un mode de réalisation de l'invention. DESCRIPTION DETAILLEE 5 Il est fait référence aux définitions suivantes : Clef de cryptage : fichier contenant les informations permettant le cryptage d'un fichier source en un fichier crypté selon un algorithme de cryptage prédéterminé ; Clef de décryptage : fichier contenant les informations permettant le décryptage 10 d'un fichier crypté en un fichier source. La clef de décryptage peut être identique à la clef de cryptage ou dépendre de celle-ci ; - Confidentialité : Protection des informations contenues dans un fichier de façon à ce que la consultation de ces informations par un individu non autorisé nécessite un effort supérieur à la seule lecture dudit fichier ; par extension, action consistant 15 à restreindre l'accessibilité au contenu d'un fichier. - Cryptage : opération de transformation d'un fichier source (clair) en un fichier de destination différent (codé) qui masque les informations contenues dans le fichier source, en utilisant une clef de cryptage connue seulement d'un ensemble d'utilisateurs autorisés et inconnue des tiers ; 20 - Décryptage : opération inverse du cryptage, c'est-à-dire une opération de transformation d'un fichier codé (ayant subi une opération de cryptage) en un fichier source (clair), en utilisant une clef de décryptage connue seulement d'un ensemble d'utilisateurs autorisés et inconnue des tiers ; - Espace de stockage : support matériel (mémoires, serveurs, etc.) individuel, 25 permettant de stocker des données numériques (fichiers informatiques) grâce à un logiciel de sauvegarde ; - Fichier : ensemble structuré de données informatiques. Un fichier est constitué d'octets et enregistré sous un format particulier ; - Informations de service : informations ajoutées à des données utiles, c'est-à-dire 30 signifiantes en elles-mêmes, de façon à documenter la méthode utilisée pour leur codage ou leur transmission. Ces informations correspondent, dans la description OSI des protocoles d'échange de données, aux informations ajoutées par la couche présentation. - Nuage : Espaces de stockage connectés informatiquement entre eux et à des 35 ordinateurs tiers susceptibles de les utiliser par l'intermédiaire d'un réseau informatique, par exemple l'Internet ; et gérés par un fournisseur de service donné ; 3055720 6 Service de stockage en ligne ou service de stockage : service proposé à titre gratuit ou onéreux par un fournisseur de service proposant des espaces de stockage dans un réseau informatique en nuage dont il est le gérant, et accessibles depuis un réseau informatique, par exemple l'Internet, à l'aide de 5 protocoles d'échange standards ou propriétaires, et mis à disposition d'utilisateurs en vue d'y conserver des fichiers ; un service de stockage utilisant une infrastructure en réseau privé peut être mis à disposition d'utilisateurs autorisés, éventuellement externes à l'organisation du fournisseur de service, en vue d'être utilisé à des fins de stockage d'informations. 10 Au sens de la présente invention, on entend indistinctement stockage, sauvegarde et archivage. On prévoit un fichier initial, ou fichier source, stocké dans une mémoire, en particulier une 15 mémoire accessible à un utilisateur. Au sens de la présente invention, un fichier source est clair, c'est-à-dire non crypté. La taille du fichier source, c'est-à-dire son nombre total d'octets, est connue avant toute 20 opération sur ledit fichier source. La mémoire est par exemple intégrée dans un ordinateur personnel ou en connexion informatique avec celui-ci. L'ordinateur est connectable à au moins un réseau informatique, en particulier l'Internet, qui sera le seul exemple décrit ici par souci de concision. 25 Le réseau informatique comprend une pluralité d'espaces de stockage, qui peuvent être indépendants les uns des autres. Par exemple, chaque espace de stockage est un nuage individuel, où chaque nuage est 30 géré par un fournisseur de service attitré. Dans un nuage, les espaces de stockage de fichiers informatiques d'un premier nuage sont connectés entre eux à l'intérieur dudit premier nuage et accessibles à des ordinateurs tiers d'utilisateurs, hors dudit premier nuage, par l'intermédiaire d'un premier réseau informatique. 35 Par exemple, le premier nuage est un nuage Dropbox (marque déposée). 3055720 7 De la même manière, les espaces de stockage de fichiers informatiques d'un deuxième nuage sont connectés entre eux à l'intérieur dudit deuxième nuage et accessibles à des ordinateurs tiers d'utilisateurs, hors dudit deuxième nuage, par l'intermédiaire d'un deuxième réseau informatique. 5 Par exemple, le deuxième nuage est un nuage Onedrive (marque déposée). Le premier réseau informatique et le deuxième réseau informatique peuvent être un seul et même réseau informatique, en l'espèce l'Internet, avantageusement quel que soit le 10 protocole de communication (http, ftp, etc.). Dans ce cas, qui est le plus complexe, comme chaque nuage est géré par un fournisseur de service attitré, les nuages sont indépendants, c'est-à-dire que les espaces de stockage d'un premier nuage sont distincts des espaces de stockage d'un deuxième nuage et ne sont pas 15 directement accessibles aux ordinateurs / serveurs / espaces de stockage de fichiers informatiques du deuxième nuage. Astucieusement, la présente invention tire avantage de cette contrainte. 20 1. Avant stockage 1.1 Ajout de données On peut prévoir une étape d'ajout de données consistant à ajouter au fichier source un 25 ensemble de données, ou d'octets. Par souci de clarté, on entend par « fichier source » le fichier source brut, exempt de tout ajout de données, et par « fichier source complété » le fichier source auquel un ensemble de données ont été ajoutées. Afin d'améliorer la confidentialité du fichier source à sauvegarder, en particulier dans le cas où le fichier source est de petite taille, c'est-à-dire typiquement inférieure à une valeur seuil prédéterminée, le fichier source peut être d'abord complété par un ensemble de données, de préférence aléatoirement choisies. 30 35 Avantageusement, les données ajoutées au fichier source sont de la même nature (de même type) que les données dudit fichier source. 3055720 8 A cet effet, on prévoit par exemple une étape consistant, pour le programme d'ordinateur mettant en oeuvre le procédé présenté, à lire le fichier source et à identifier la typologie des informations contenues dans le fichier source. 5 Typiquement, le fichier source est codé en octets, chaque octet prenant une valeur unique parmi 256 valeurs possibles. On établit alors un histogramme d'utilisation des 256 valeurs possibles dans le fichier source. Par exemple, on peut prévoir que la génération de l'histogramme des occurrences des 10 différentes valeurs d'octets soit effectuée selon l'algorithme suivant : tableau Histogramme = tableau [256] d'entiers Initialiser tableau Histogramme à 256 valeurs égales à 0 Tant que le fichier source n'est pas complètement lu Lire un octet et le mémoriser dans une mémoire o 15 Incrémenter de une unité l'entier tableauHistogramme[o] Fin tant que De préférence les données ajoutées sont choisies parmi l'ensemble des données de même type, c'est-à-dire parmi les données du fichier source, de préférence selon le même 20 histogramme et par exemple aléatoirement. Par exemple, un fichier source contenant des données lisibles par un éditeur de texte est complété par des caractères de texte, éventuellement alphanumériques, ou des 25 mots, aléatoirement choisis ; un fichier source binaire est complété par des données binaires aléatoirement choisies, un ficher source comprenant une image est complété par des pixels aléatoirement choisis, 30 etc. Les données aléatoirement choisis peuvent être sélectionnées de façon à ne pas modifier l'histogramme d'utilisation des octets du fichier source. Plus précisément, à supposer que l'histogramme d'utilisation des 256 valeurs possibles dans le fichier source soit comme illustré 35 en figure 2, alors on peut prévoir de n'ajouter que des valeurs d'octet parmi celles pour lesquelles le taux d'utilisation n'est pas nul, en l'espèce les valeurs d'octet 2, 17, 42, 54, 72, 99, 124, 201 et 253. 3055720 9 Ensuite, parmi ces valeurs, on peut sélectionner aléatoirement les valeurs à ajouter. On peut aussi, parmi ces valeurs, ajouter un nombre N de valeurs (N un entier naturel prédéterminé, supérieur au nombre de valeurs d'octet pour lesquelles le taux d'utilisation n'est 5 pas nul) respectant la distribution de l'histogramme, en l'espèce si N=100, on ajoute : 45 octets dont la valeur est 2, 2 octets dont la valeur est 17, 17 octets dont la valeur est 42, 8 octets dont la valeur est 54, 10 2 octets dont la valeur est 72, 13 octets dont la valeur est 99, 8 octets dont la valeur est 124, 2 octets dont la valeur est 201, et 3 octets dont la valeur est 253. 15 Les données ajoutées sont positionnées en fin du fichier source, après le dernier octet de celui-ci. Le nombre N de données ajoutées peut être prédéterminé ou variable (choisi). 20 Dans le cas où le nombre de données N ajoutées est prédéterminé, la valeur de N est connue et enregistrée dans une mémoire. Par exemple (purement illustratif) N = 100 octets. Dans le cas où le nombre de données N ajoutées est variable, on peut prévoir selon une 25 première variante que la valeur de N est choisie de sorte que la taille du fichier source complété est supérieure ou égale à une valeur seuil prédéterminée. Selon une deuxième variante, on peut prévoir d'ajouter un nombre N de données correspondant à un pourcentage prédéterminé du nombre d'octets du fichier source, par exemple N = 10%. 30 En particulier, on peut prévoir que le nombre de données ajoutées est tel que le nombre d'octets correspondant au fichier source complété est égal à un multiple de « p », avec « p » un nombre entier prédéterminé. De préférence, la valeur de « p » correspond au nombre de fragments définis à l'étape de 35 fragmentation décrite ultérieurement. 1.2 Mélange des octets 3055720 10 Afin d'améliorer la confidentialité des données du fichier source, les octets dudit fichier source éventuellement complété (éventuellement y compris les octets de l'en-tête), peuvent être mélangés. 5 L'étape de mélange consiste à modifier (permuter) la position ou l'ordre des octets dudit fichier source éventuellement complété, grâce à un algorithme de mélange ou fonction de mélange f. On définit par : 10 - T la taille dudit fichier source éventuellement complété, - E le sous-ensemble de cardinal T des entiers naturels inférieurs strictement à T, - f, la fonction de mélange, est une fonction bijective quelconque sur l'ensemble E, dont la fonction réciproque est également définie sur l'ensemble E. L'ensemble E est donc à la fois ensemble de départ et ensemble d'arrivée de la fonction bijective f. 15 L'opération de mélange consiste à modifier la position r de l'octet occupant le rang r dans le fichier source (éventuellement complété) en f(r) pour que celui-ci occupe une position s après application de la fonction f. 20 Avec la même convention, le ré-ordonnancement du fichier ainsi mélangé consistera à modifier la position s de l'octet occupant le rang s dans le fichier mélangé en f-1(s), f-1 étant la fonction réciproque (ou inverse) de f pour que celui-ci occupe la position (initiale) r après application de la fonction inverse f-1. 25 La fonction f peut être analytiquement définie (la fonction de lecture inverse, telle que f(r)=T-r en est un exemple). La fonction f peut également être définie par une matrice ou par un algorithme, pour autant que les conditions énoncées plus haut sont satisfaites. Par exemple, l'étape de mélange est mise en oeuvre par un algorithme utilisant les 30 propriétés de la suite de Fibonnacci, classiquement utilisée pour la génération de séquences de nombres pseudo aléatoires. L'algorithme de mélange peut comprendre un ensemble de paramètres qui seront transmis dans les différents fragments décrits à la suite. 35 La taille du fichier source (éventuellement complété) mélangé est donc la même que celle du fichier source (éventuellement complété), mais l'ordre des octets du fichier source mélangé est différent de l'ordre des octets du fichier source. 3055720 11 L'algorithme de mélange est un algorithme déterministe et réversible, dont les paramètres initiaux sont connus et qui permet, à partir de ceux-ci, la remise en ordre des octets mélangés, ultérieurement lors de la reconstruction du fichier source. 5 De préférence, l'étape de mélange est effectuée après l'étape d'ajout de données. De préférence, l'étape de mélange est effectuée avant l'étape de fragmentation décrite ci-après. 10 L'opération de mélange des octets s'apparente à une opération de cryptage. Cependant, un cryptage classiquement utilisé (par exemple de type SSL) est une opération matricielle réalisée généralement sur un bloc de 16 ou 32 octets consécutifs. La connaissance de la clef suffit à décoder le bloc, et le bloc décodé est alors signifiant, c'est-à-dire porteur de sens ou 15 d'information. Au contraire, le fait de mélanger les données élémentaires (octets), couplé à la fragmentation décrite ci-après, permet de sécuriser les fragments puisqu'un fragment, même non crypté, n'est pas porteur de sens. Pour obtenir la signification du « message », c'est-à-dire 20 du fichier source, il faut être en mesure de disposer d'un fragment ordonné, ce qui nécessite de disposer de la totalité des fragments. 1.3 Fragmentation 25 On prévoit de découper le fichier source, éventuellement complété, éventuellement mélangé, en un ensemble de fragments, chaque fragment étant un ensemble d'octets consécutifs du fichier source éventuellement complété et mélangé. Par exemple la fragmentation est mise en oeuvre par un algorithme de fragmentation 30 connu notamment dans le domaine de la compression de format de type ZIP, ou dans le domaine des systèmes d'exploitation. Le nombre de fragments et la taille des fragments sont de préférence des paramètres prédéterminés. On peut prévoir que tous les fragments ont la même taille, que certains 35 fragments ont la même taille ou que les fragments ont tous des tailles différentes. De préférence, chaque fragment comprend au moins un identifiant, par exemple au moins un identifiant parmi un identifiant individuel et un identifiant du fichier source. 3055720 12 De préférence, chaque fragment porte un nom de fichier dérivant du nom du fichier source, ce qui facilite la restauration ultérieure des données. 5 Afin de permettre la reconstruction du fichier source à l'identique, il est nécessaire que chaque fragment comprenne un certain nombre d'informations dites de service, à la manière des protocoles d'échange informatique. Par exemple, les informations de service comprennent entre autre des informations 10 concernant : le fragment considéré, le type de fragment, l'index du fragment (numéro d'ordre), des informations concernant le fichier source, 15 le nombre total de fragments, la taille du fichier source, les paramètres de l'algorithme de mélange. De préférence, chaque type d'information de la liste ci-dessus est codé selon un nombre 20 d'octets prédéterminé. Les informations de service, nécessaires à la reconstruction du fichier source, doivent être conservées. De préférence, elles seront transmises et stockées avec les fragments. 25 Par exemple, les informations de service sont ajoutées en entête des différents fragments. De préférence, les octets constituant les informations de service concernant le fichier source (notamment la taille, le nombre total de fragments et les paramètres de l'algorithme de 30 mélange) peuvent être elles-mêmes fragmentées et distribuées sur les différents fragments, afin que la connaissance d'un seul fragment ne permette pas la connaissance des caractéristiques du fichier source ni les paramètres de l'algorithme de mélange. Alternativement, les octets constituant les informations de service concernant le fichier 35 source (notamment la taille, le nombre total de fragments et les paramètres de l'algorithme de mélange) peuvent être masqués en utilisant le principe de masquage décrit plus bas. 1.4 Cryptage 3055720 13 On peut prévoir une étape de cryptage du fichier source, éventuellement complété, ou des fragments, de sorte que les octets du fichier source à sauvegarder sont cryptés grâce à une clef de cryptage, de préférence selon un algorithme déterministe. 5 L'algorithme de cryptage est un algorithme réversible, qui autorise le décryptage à partir d'une clef de décryptage, identique ou différente de la clef de cryptage. L'étape de cryptage peut être mise en oeuvre à tout moment avant le stockage des fragments dans les nuages. De cette façon, aucun prestataire de stockage n'a accès à la totalité du ou des fichiers dont les données sont cryptées. 1.4.1 Clé de cryptage, clé de décryptage Dans le cas où l'étape de cryptage est mise en oeuvre, l'une au moins parmi la clé de cryptage et la clé de décryptage peut être prédéterminée et imposée à l'utilisateur une fois pour toutes, charge à l'utilisateur de les sécuriser par tout moyen qu'il juge approprié. 20 L'une au moins parmi la clé de cryptage et la clé de décryptage peut être générée aléatoirement. Pour augmenter la sécurité, on peut prévoir que la clé de décryptage est différente de la clé de décryptage. 25 On peut également prévoir de générer une clé de cryptage par espace de stockage. On peut également prévoir de générer une clé de cryptage par fragment de fichier source, ce qui permet avantageusement de limiter l'impact du vol d'une clé de cryptage ou de 30 décryptage. Grâce à ces caractéristiques, le vol de l'une au moins des clés de cryptage et de décryptage relatives à un premier fragment F1 d'un premier fichier source FS1 est sans impact sur la confidentialité des données contenues dans un deuxième fragment F2 dudit fichier 35 source FS1 ; et également sans impact sur la confidentialité des données contenues dans un fragment quelconque d'un deuxième fichier source FS2, quand bien même le deuxième fichier source FS2 est stocké dans le même espace de stockage que le premier fichier source FS1. 10 15 3055720 14 Avantageusement, afin de rendre inutile le stockage local de clefs de cryptage et de décryptage, et de complexifier le vol de ces informations, les clefs de cryptage et de décryptage, qui sont elles-mêmes des fichiers sources, peuvent être elles-mêmes stockées en clair en utilisant le principe de l'invention. 5 On peut prévoir de stocker dans un espace de stockage prédéterminé les clefs qui sont utilisées pour le stockage dans un autre espace de stockage. Par exemple, on peut prévoir de stocker dans un premier espace de stockage les clefs utilisées pour le stockage dans un deuxième espace de stockage ; de stocker dans le deuxième espace de stockage les clés 10 utilisées pour le stockage dans un troisième espace de stockage (ou dans le premier espace de stockage), et ainsi de suite. Alternativement, les clefs de cryptage peuvent être masquées en utilisant le principe décrit plus bas. 15 1.5 Masquage On peut prévoir, à tout moment précédant l'étape de stockage, une étape de masquage consistant à masquer au moins l'un des ensembles parmi : 20 tout ou partie des informations de service, les données du fichier source, les fragments du fichier source, la(les) clé(s) de cryptage, et la(les) clé(s) de décryptage. 25 L'étape de masquage peut être complémentaire ou remplacer au moins l'une quelconque des étapes de fragmentation, de mélange, et de cryptage décrites précédemment. L'étape de masquage d'un jeu de données consiste en une opération de transformation 30 d'un jeu de données numériques source en un nombre défini de jeux de données numériques cibles de même taille, de même nombre d'octets, et élaborés de façon à ce que seule la connaissance de la totalité des jeux de données numériques cibles permettent la connaissance du jeu de données numériques source, chacun des jeux de données numériques cibles étant alors stocké sous forme de fichiers ou de fragments sur les différents espaces de stockage . 35 Plus précisément, le masquage d'un jeu de données source consiste à créer un nombre prédéfini de jeux de données cibles de même taille que le jeu de données source et à en masquer les octets. 3055720 15 Par exemple, on prédétermine un nombre « m » de jeux de données cibles, avec « m » un entier naturel enregistré dans une mémoire. 5 Pour un octet source donné « 0 » d'un jeu de données source, l'étape de masquage consiste à générer m octets cibles 01 à Om. A cet effet, on prévoit : - de définir une fonction ou un algorithme f1 acceptant m paramètres et fournissant une 10 valeur d'octet unique en retour, et à partir de la fonction ou algorithme f1 : - de rechercher au moins un ensemble de m octets 01 à Om tels que f1(01,02,...,0m) = O Par exemple, la somme des octets 01 à Om, modulo 256, est une solution. Dans cet 15 exemple, si m est égal à 4, l'octet « 9 » peut être codé comme tout ensemble de 4 octets dont la somme modulo 256 est égal à « 9 », ce qui offre plus de 16 millions de possibilités de codage, parmi lesquelles par exemple, les ensembles de 4 octets suivants, dont la somme, par ligne et modulo 256, est toujours égale à « 9 » 20 25 Le masquage d'un octet permet de dissimuler totalement la valeur de l'octet dans un 30 ensemble de plusieurs octets. Ce principe peut s'appliquer à des combinaisons d'octets plutôt qu'à des octets uniques, à des parties de fichier plutôt qu'à des fichiers complets. 35 L'étape de masquage permet avantageusement une amélioration de la confidentialité des données, au prix d'une augmentation de la taille des données stockées. 1.6 Fichiers de parité 100 237 41 143 165 139 126 91 213 150 211 203 95 191 254 237 196 99 157 69 4 95 208 214 0 210 249 62 92 224 132 73 241 248 134 154 3055720 16 On peut prévoir une étape consistant à créer, à partir du fichier source, un ensemble d'au moins un fichier de parité, qui autorise la reconstruction de données (fragments) en cas de perte d'une partie desdites données. Les fichiers de parité sont générés par exemple par un système de type « Parchive » qui est un système correcteur d'erreurs générant des fichiers PAR ou PAR2 qui peut être appliqué à un ensemble de fichiers pour permettre leur reconstruction lorsqu'un ou plusieurs de ces fichiers sont manquants, incomplets ou endommagés. On peut prévoir de stocker le(s)dit(s) fichier(s) de parité en complément ou à la place des fragments du fichier source, ce qui permet de s'affranchir de l'inaccessibilité d'un des espaces de stockage. 15 1.7 Stockage des paramètres On peut prévoir de stocker au moins l'un des paramètres permettant la reconstruction du fichier source parmi : les paramètres de l'algorithme de mélange, et 20 la taille du fichier source, dans des informations d'entête des fragments, et/ou de masquer lesdits paramètres dans différents fragments. De préférence, on prévoit de stocker les paramètres sur une pluralité de fragment, par 25 exemple un paramètre par fragment. Alternativement, on peut masquer ces informations en utilisant le principe décrit plus haut. Grâce à cette caractéristique, il n'est pas nécessaire de stocker ces paramètres en local 30 sur la machine de l'utilisateur. En outre, la distribution de ces paramètres sur un ensemble de fragments augmente la confidentialité, l'accès illicite à un seul fragment ne compromettant en rien dans ce cas la confidentialité du fichier source dans son ensemble. 35 2. Stockage des données 5 10 3055720 17 On prévoit de stocker lesdits fragments sur au moins deux espaces de stockage différents. Ainsi, chaque espace de stockage n'est donc dépositaire que d'un ou de plusieurs 5 fragments mais jamais de la totalité des fragments. Et dans le cas où chaque espace de stockage est géré par un fournisseur de service respectif, chaque fournisseur de service n'a aucune connaissance de la correspondance entre le ou les fragments stockés dans son espace de stockage et la ou les parties correspondantes 10 du fichier source. De cette façon, aucun fournisseur de stockage n'a accès au fichier source dans son intégralité. 15 De préférence, les fragments sont distribués sur les espaces de stockage de sorte à ce que chaque espace de stockage ne comprenne qu'un minimum de fragments consécutifs. Par « minimum », on entend un nombre de fragments inférieur à une valeur seuil prédéterminée. Par exemple, les fragments envoyés à chaque espace de stockage sont préalablement sélectionnés de manière aléatoire parmi l'ensemble de fragments. 20 3. Reconstruction du fichier source L'opération de reconstruction, ou restauration, du fichier source nécessite de rapatrier sur un même ordinateur (une même machine utilisateur) la totalité des fragments correspondant à 25 un fichier source donné enregistrés sur les différents espaces de stockage. L'opération de reconstruction nécessite un ré-ordonnancement du ou des fichiers reconstruits à partir des fragments lus sur les espaces de stockage, et requiert la connaissance des paramètres initiaux de l'algorithme de mélange. Ces paramètres initiaux peuvent être 30 ajoutés en entête des fragments stockés sur les différents espaces de stockage. L'opération de reconstruction nécessite ensuite de supprimer les données non significatives du fichier reconstruit, c'est-à-dire les données ajoutées, ce qui requiert la connaissance de la longueur des données significatives du fichier source. 35 La longueur des données significatives peut être ajoutée en entête des fragments stockés sur les différents espaces de stockage. 3055720 18 L'opération de reconstruction peut nécessiter un décryptage du fichier reconstruit à partir des fragments lus sur les espaces de stockage. En cas de masquage, l'opération de reconstruction comprend également une opération 5 inverse de démasquage On peut prévoir que, parmi les informations de service, le type de fragment décrive la typologie du fragment (mélange, crypté, parité,...) 10 4. Exemple Un exemple de fichier source [E] est illustré sur la figure 3. Pour plus de lisibilité, le fichier source [E] est un fichier de texte comprenant la suite de lettres abcdefghijklm, soit 13 lettres au total. Pour simplifier, on assimilera ici une lettre et un octet. 15 Un histogramme d'utilisation des 256 valeurs possibles dans le fichier source est établi et la typologie des informations contenues dans le fichier source est alors identifiée. On peut imposer une valeur m correspondant au pourcentage minimum de données 20 aléatoires à ajouter, « m » étant un paramètre enregistré dans une mémoire. Par exemple si m = 20, alors on ajoute au moins 20% du nombre de données ou d'octets du fichier source à celui-ci. Ainsi, les données signifiantes du fichier source sont noyées dans un ensemble plus vaste comprenant lesdites données signifiantes et les données ajoutées, ce qui rend lesdites données signifiantes plus difficilement compréhensibles. 25 On prévoit par exemple que le nombre de données ajoutées est égal à 3. Les données aléatoires sont choisies en relation avec le contenu du fichier [E] : les données ajoutées possèdent la même typologie que celle des informations contenues dans le fichier source. Les données ajoutées sont donc des caractères alphanumériques, et en particulier des lettres 30 sélectionnées au hasard parmi les données abcdefghijklm du fichier source. En l'espèce, les données sélectionnées aléatoirement sont les lettres c, m et h. Le fichier [E] est alors complété avec cet ensemble de valeurs aléatoires cmh pour produire le fichier source compété [F] dont le contenu est abcdefghijklmcmh. 35 Pour simplifier la présente description, on considère que tous les fragments ont la même taille, dont la valeur (en l'espèce p=4) est un paramètre enregistré dans une mémoire, de façon à obtenir un ensemble de fragments de taille identique quel que soit l'espace de stockage, chaque fragment étant de taille supérieure à une valeur paramétrée. 3055720 19 La taille « s » du fichier source compété [F] est donc égale à p fois la taille d'un fragment (en l'espèce de 4 octets), elle-même supérieure à t, avec : « s » un nombre entier égal au nombre d'octet du fichier [F], en l'espèce 16, 5 « p » le nombre total de fragments, en l'espèce 4, et « t » un paramètre enregistré dans une mémoire correspondant à la taille minimale d'un fragment. Quelle que soit la taille du fichier source : 10 si le nombre total de fragments est supérieur au nombre total d'espaces de stockage, alors de préférence chaque espace de stockage comprend au moins un fragment ; si le nombre total de fragments est inférieur au nombre total d'espaces de stockage, alors de préférence chaque espace de stockage comprend au plus un 15 fragment. Une fois le fichier source compété [F] généré, les octets de celui-ci sont mélangés pour produire un fichier source compété mélangé [G] de taille s, de même taille que le fichier source compété [F], mais dans lequel l'ordre des octets du fichier [F] a été modifié, en l'espèce le 20 fichier [G] comprend la suite de lettres gablmmckdiehhfjc. Le fichier source compété mélangé [G] est alors fragmenté (découpé) en « p » fragments [Gi], en l'espèce de taille identique, auxquels on ajoute les informations de service nécessaires, à savoir pour l'exemple considéré les paramètres de l'algorithme de mélange, la taille du fichier 25 source [E], en l'espèce 13, et le nombre total de fragments, en l'espèce 4. En l'espèce, un premier fragment G1 comprend la suite de lettres gabl, un deuxième fragment G2 comprend la suite de lettres mmck, 30 un troisième fragment G3 comprend la suite de lettres dieh, et un quatrième fragment G4 comprend la suite de lettres hfjc. De préférence, chaque fragment [Gi] est nommé en utilisant le même nom que celui du fichier source [E]. Des informations d'entête sont ajoutées aux différents fragments, 35 typiquement - L'index i du fragment (l'ordre dans lequel il faudra reconstruire le fichier source), - Le nombre total de fragments p, en l'espèce 4, - La taille en octets du fichier source [E], en l'espèce 13, et 3055720 20 - Les paramètres de l'algorithme de mélange. On peut prévoir une étape de cryptage consistant à crypter chaque fragment [Gi] en un fragment crypté correspondant [Hi]. On a donc p fragments [Hi], soit en l'espèce 4 fragments 5 H1, H2, H3 et H4 dont le contenu crypté est illustré par des étoiles. Les p fragments [Hi] sont alors envoyés sur des espaces de stockage. Pour simplifier, on considère que chaque fragment est envoyé à un espace de stockage ESi respectif. En l'espèce, le premier fragment G1 est envoyé sur l'espace de stockage ES1, 10 le deuxième fragment G2 est envoyé sur l'espace de stockage ES2, le troisième fragment G3 est envoyé sur l'espace de stockage ES3, et le quatrième fragment G4 est envoyé sur l'espace de stockage ES4. La distribution des fragments sur les espaces de stockage peut être paramétrée (nombre 15 de fragments par espace de stockage, choix des fragments par espace de stockage). Pour la restauration du fichier source [E], dans une première étape, les « p » fragments [Hi] sont renvoyés depuis les espaces de stockage vers une mémoire commune MEM, par exemple un répertoire, éventuellement temporaire, d'un ordinateur. 20 Dans le cas où une étape de cryptage a été mise en oeuvre, on prévoit que les p fragments [Hi] sont décryptés en p fragments [Gi]. Les informations de service de chaque fragment Gi sont décodées afin de déterminer au 25 moins les informations suivantes : - L'index i du fragment, c'est-à-dire la position du fragment ou l'ordre dans lequel il faut reconstruire le fichier source, - Le type de fragment (parité, normal, mélangé, ..), - Le nombre total de fragments, et 30 - La taille en octets du fichier source [E]. Dans le cas où le fichier source a été mélangé, les informations de service de chaque fragment sont décodées afin de déterminer en outre les paramètres de l'algorithme de mélange. 35 De préférence, on considère par défaut que le fichier source est mélangé. 3055720 21 A partir des informations de service de chaque fragment [Gi], notamment leur index respectif, le fichier source compété mélangé [G] est reconstruit par agglomération des « p » fragments [Gi], dont les informations de service sont supprimées. 5 Une fois le fichier source compété mélangé [G] reconstruit par agglomération des « p » fragments [Gi], on prévoit de réordonner les octets dudit fichier [G] pour produire un fichier [F] de taille s, donc de même taille que le fichier [G], mais dans lequel l'ordre des octets du fichier [F] a été corrigé. Le ré-ordonnancement est possible grâce au fait que l'algorithme de mélange est un 10 algorithme déterministe et réversible. Le fichier [F] étant réordonné, on prévoit alors de supprimer dudit fichier [F] les valeurs ajoutées, en utilisant la taille du fichier source [E] à obtenir qui est transmise dans les données de service, pour re-produire le fichier source [E]. En l'espèce, l'étape de suppression des données ajoutées consiste, à partir du fichier [F] réordonné, à conserver comme fichier source [E] à obtenir tous les octets compris entre 1 et la taille du fichier source [E] à obtenir, et à supprimer tous les octets positionnés après la valeur de la taille dudit fichier source [E] à obtenir. On peut mettre en oeuvre une étape de vérification que la taille en octets du fichier source compété réordonné est égale à la taille en octets du fichier source [E] contenue dans les informations de service de chaque fragment. 25 La séquence des étapes peut différer de l'ordre décrit précédemment et répondre par exemple aux séquences illustrées sur la figure 1. L'invention peut être mise en oeuvre pour un format et une taille quelconques de fichier, y compris les fichiers de très gros volumes (> Go, incluant le To). 30 Elle est particulièrement avantageusement mise en oeuvre lorsque chaque espace de stockage au sens de la présente invention est en réalité un nuage et que les nuages sont indépendants. 15 20 35 REVENDICATIONS1. Procédé de stockage d'un fichier source numérique (E) comprenant un ensemble de données, le procédé comprenant des étapes consistant à : fragmenter ledit fichier source en un ensemble de fragments (Gi), et enregistrer ledit ensemble de fragments (Gi), Caractérisé en ce que : L'étape d'enregistrement des fragments (Gi) est mise en oeuvre sur un ensemble d'espaces de stockage, la totalité desdits fragments (Gi) étant enregistrés sur au moins deux espaces de stockage distincts, Et en ce qu'il comprend, préalablement à l'étape de fragmentation, au moins l'une des étapes parmi : ajouter audit fichier source (E) un ensemble de données ou d'octets pour générer un fichier source complété (F) ; et mélanger les octets dudit fichier source complété (F) pour générer un fichier source complété mélangé (G). 2. Procédé selon la revendication 1, dans lequel l'étape d'ajout comprend en outre des étapes consistant à : - lire le fichier source et identifier la typologie des informations contenues dans le fichier source ; - établir un histogramme d'utilisation des valeurs d'octets dans le fichier source ; et - choisir les données ajoutées aléatoirement de façon à ne pas modifier ledit histogramme d'utilisation des octets du fichier source. 25 3. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de mélange consiste à modifier la position de chaque octet dans le fichier source ; de sorte que pour un octet donné, la position dudit octet après mélange selon un algorithme déterministe et réversible est différente de la position dudit octet avant mélange ; l'étape de mélange étant de 30 préférence effectuée après l'étape d'ajout de données et avant l'étape de fragmentation. 4. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à ajouter des informations de service en entête de chaque fragment de l'ensemble de fragments (Gi). 35 5. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape de cryptage consistant à crypter l'un au moins parmi : - le fichier source, et 3055720 23 - au moins l'un des fragments parmi l'ensemble de fragments (Gi). 6. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre, à tout moment précédant l'étape de stockage, une étape de masquage consistant à masquer 5 au moins l'un des ensembles parmi : tout ou partie des informations de service, les données du fichier source, les fragments du fichier source, une ou des clé(s) de cryptage, et 10 une ou des clé(s) de décryptage. 7. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à stocker dans un premier espace de stockage au mois l'un parmi : - un ensemble d'au moins une clef de cryptage et 15 - un ensemble d'au moins une clef de décryptage, dans lequel ledit ensemble d'au moins une clef de cryptage et ledit ensemble d'au moins une clef de décryptage sont utilisés respectivement pour le cryptage et le décryptage des fragments (Gi) stockés dans un deuxième espace de stockage, différent du premier espace de stockage. 20 8. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à créer, à partir du fichier source, un ensemble d'au moins un fichier de parité. 9. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre des étapes consistant à : rapatrier sur un même ordinateur la totalité des fragments correspondant audit fichier source et enregistrés sur lesdits au moins deux espaces de stockage distincts ; réordonner lesdits fragments ; et supprimer les données ajoutées lors de l'étape d'ajout ; et, le cas échéant, décrypter lesdits fragments si ceux-ci ont été cryptés ; et dé-masquer lesdits fragments si ceux-ci ont été masqués. 10. Programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendications précédentes, lorsque ledit programme est exécuté sur un ordinateur.