FR3055720A1 - Procede de stockage securise d’un fichier source numerique. - Google Patents
Procede de stockage securise d’un fichier source numerique. Download PDFInfo
- Publication number
- FR3055720A1 FR3055720A1 FR1658279A FR1658279A FR3055720A1 FR 3055720 A1 FR3055720 A1 FR 3055720A1 FR 1658279 A FR1658279 A FR 1658279A FR 1658279 A FR1658279 A FR 1658279A FR 3055720 A1 FR3055720 A1 FR 3055720A1
- Authority
- FR
- France
- Prior art keywords
- source file
- fragments
- data
- file
- bytes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 26
- 239000012634 fragment Substances 0.000 claims abstract description 147
- 238000013467 fragmentation Methods 0.000 claims abstract description 13
- 238000006062 fragmentation reaction Methods 0.000 claims abstract description 13
- 230000000873 masking effect Effects 0.000 claims description 13
- 230000002441 reversible effect Effects 0.000 claims description 8
- 238000004590 computer program Methods 0.000 claims description 3
- 230000006870 function Effects 0.000 description 13
- 230000015654 memory Effects 0.000 description 12
- 238000013500 data storage Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 230000001131 transforming effect Effects 0.000 description 3
- 238000005054 agglomeration Methods 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 239000011159 matrix material Substances 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 101000603877 Homo sapiens Nuclear receptor subfamily 1 group I member 2 Proteins 0.000 description 1
- 101001098560 Homo sapiens Proteinase-activated receptor 2 Proteins 0.000 description 1
- 101000713170 Homo sapiens Solute carrier family 52, riboflavin transporter, member 1 Proteins 0.000 description 1
- 102100036863 Solute carrier family 52, riboflavin transporter, member 1 Human genes 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000004927 fusion Effects 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000000284 resting effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Bioethics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
Abstract
L'invention concerne 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 - enregistrer ledit ensemble de fragments (Gi). Il est essentiellement caractérisé en ce que - L'étape d'enregistrement des fragments (Gi) est mise en œuvre 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).
Description
® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE © N° de publication : 3 055 720 (à n’utiliser que pour les commandes de reproduction) © N° d’enregistrement national : 16 58279
COURBEVOIE © Int Cl8 : G 06 F21/78 (2017.01), G 06 F 3/06
DEMANDE DE BREVET D'INVENTION A1
| ©) Date de dépôt : 06.09.16. (© Priorité : | © Demandeur(s) : BINET OLIVIER— FR. |
| @ Inventeur(s) : BINET OLIVIER. | |
| ®) Date de mise à la disposition du public de la demande : 09.03.18 Bulletin 18/10. | |
| ©) Liste des documents cités dans le rapport de recherche préliminaire : Se reporter à la fin du présent fascicule | |
| (© Références à d’autres documents nationaux apparentés : | ® Titulaire(s) : BINET OLIVIER. |
| ©) Demande(s) d’extension : | (© Mandataire(s) : INPUT IP. |
PROCEDE DE STOCKAGE SECURISE D'UN FICHIER SOURCE NUMERIQUE.
FR 3 055 720 - A1
L'invention concerne 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
- 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 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).
E=abcdefghijklm _cm|-|
I + I ï—
F=abcdetghijklmcmh ... J G=gablmmckdiehhf|c
Gl=gabl G2=mmck G3=dieh G4=hfjc i i I
H1=” H2=*”‘ H3=” H4=”” i i I i
Gl=gabl G2=mmck G3=dieh G4=hfjc —
G=gabimmckdiehhfjc i
F=abcdelghijklmcmh ·” i
E=abcdelghijklm
PROCEDE DE STOCKAGE SECURISE D’UN FICHIER SOURCE NUMERIOUE.
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
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
- enregistrer ledit ensemble de fragments (Gi).
II 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 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).
Les espaces de stockage distincts peuvent être connectés informatiquement entre eux, ou non.
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
- 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 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 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
- 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 :
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.
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, 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 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 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.
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.
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 ;
- 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 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 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 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 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é, 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 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 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 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
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 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 à 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 ;
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, 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 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 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é ;
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 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.
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 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 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.
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 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.
Par exemple, le premier nuage est un nuage Dropbox (marque déposée).
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.
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 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 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.
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 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.
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.
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.
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 différentes valeurs d’octets soit effectuée selon l’algorithme suivant :
tableauHistogramme = tableau [256] d’entiers
Initialiser tableauHistogramme à 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 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 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 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, 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é 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.
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 pas nul) respectant la distribution de l’histogramme, en l’espèce si N=100, on ajoute :
octets dont la valeur est 2, octets dont la valeur est 17, octets dont la valeur est 42, octets dont la valeur est 54, octets dont la valeur est 72, octets dont la valeur est 99, octets dont la valeur est 124, octets dont la valeur est 201, et octets dont la valeur est 253.
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).
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 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%.
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 fragmentation décrite ultérieurement.
1.2 Mélange des octets
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.
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 :
- 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.
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.
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), f1 é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 f1.
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 œuvre par un algorithme utilisant les 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.
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.
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.
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 ciaprès.
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 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 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
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 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 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.
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.
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 concernant :
le fragment considéré, le type de fragment, l’index du fragment (numéro d’ordre), des informations concernant le fichier source, 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 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.
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 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 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
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.
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 œuvre à 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 œuvre, 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é.
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.
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 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 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.
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.
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 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.
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 :
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.
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 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 .
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.
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.
Pour un octet source donné « O » 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 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(O1,O2,...,Om) = O
Par exemple, la somme des octets 01 à Om, modulo 256, est une solution. Dans cet 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 »
| 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 |
Le masquage d’un octet permet de dissimuler totalement la valeur de l’octet dans un 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.
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é
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.
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 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 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 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.
2. Stockage des données
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 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 du fichier source.
De cette façon, aucun fournisseur de stockage n’a accès au fichier source dans son intégralité.
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.
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 à 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 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.
La longueur des données significatives peut être ajoutée en entête des fragments stockés sur les différents espaces de stockage.
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 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é,...)
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.
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 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 à celuici. 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.
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 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.
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.
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, « 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 :
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 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 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 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, 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, 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 • 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 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, 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 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.
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 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 • 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.
De préférence, on considère par défaut que le fichier source est mélangé.
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.
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 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.
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).
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.
Claims (10)
- 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 œuvre 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.
- 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 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).
- 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- 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 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 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- 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.
- 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.1 /2
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1658279A FR3055720B1 (fr) | 2016-09-06 | 2016-09-06 | Procede de stockage securise d’un fichier source numerique. |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1658279 | 2016-09-06 | ||
| FR1658279A FR3055720B1 (fr) | 2016-09-06 | 2016-09-06 | Procede de stockage securise d’un fichier source numerique. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3055720A1 true FR3055720A1 (fr) | 2018-03-09 |
| FR3055720B1 FR3055720B1 (fr) | 2019-12-06 |
Family
ID=57906698
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1658279A Expired - Fee Related FR3055720B1 (fr) | 2016-09-06 | 2016-09-06 | Procede de stockage securise d’un fichier source numerique. |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3055720B1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110474949A (zh) * | 2019-06-26 | 2019-11-19 | 北京广利核系统工程有限公司 | Windows环境下与核电站安全级保护系统通讯的方法和装置 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016073148A1 (fr) * | 2014-11-07 | 2016-05-12 | Qualcomm Incorporated | Utilisation du hachage d'un nom de fichier pour commander le codage/décodage d'un fichier numérique |
| US20160147471A1 (en) * | 2014-11-21 | 2016-05-26 | Security First Corp. | Gateway for cloud-based secure storage |
-
2016
- 2016-09-06 FR FR1658279A patent/FR3055720B1/fr not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016073148A1 (fr) * | 2014-11-07 | 2016-05-12 | Qualcomm Incorporated | Utilisation du hachage d'un nom de fichier pour commander le codage/décodage d'un fichier numérique |
| US20160147471A1 (en) * | 2014-11-21 | 2016-05-26 | Security First Corp. | Gateway for cloud-based secure storage |
Non-Patent Citations (3)
| Title |
|---|
| ANONYMOUS: "Data masking - Wikipedia, the free encyclopedia", 27 March 2013 (2013-03-27), pages 1 - 5, XP055181852, Retrieved from the Internet <URL:http://en.wikipedia.org/w/index.php?title=Data_masking&oldid=552392298> [retrieved on 20150409] * |
| ANONYMOUS: "Padding (cryptography) - Wikipedia, the free encyclopedia", 28 September 2012 (2012-09-28), XP055154479, Retrieved from the Internet <URL:http://en.wikipedia.org/w/index.php?title=Padding_(cryptography)&oldid=515078455> [retrieved on 20141124] * |
| DETRISTAN ET AL: ".:: Phrack Magazine ::.", 10 June 2016 (2016-06-10), XP055376661, Retrieved from the Internet <URL:http://phrack.org/issues/61/9.html> [retrieved on 20170529] * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110474949A (zh) * | 2019-06-26 | 2019-11-19 | 北京广利核系统工程有限公司 | Windows环境下与核电站安全级保护系统通讯的方法和装置 |
| CN110474949B (zh) * | 2019-06-26 | 2023-12-15 | 北京广利核系统工程有限公司 | Windows环境下与核电站安全级保护系统通讯的方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3055720B1 (fr) | 2019-12-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5647754B1 (ja) | 記憶システムにおけるコンテンツの削除のためのコンピュータ化システム、方法、コンピュータ・プログラム、およびデータ記憶媒体（記憶システムにおけるコンテンツの削除） | |
| EP2494491B1 (fr) | Identification par controle de donnees biometriques d'utilisateur | |
| EP2323306A1 (fr) | Procédé de transmission de données sécurisé et systeme de chiffrement et de dechiffrement permettant une telle transmission | |
| WO2012093216A1 (fr) | Dispositif et procède de stockage en ligne, dispositif et procède d'émission, dispositif et procède de réception | |
| EP3304409B1 (fr) | Sécurisation de données numériques | |
| EP3363143B1 (fr) | Méthode d'interrogation confidentielle d'une base de données chiffrée | |
| FR2853175A1 (fr) | Procede et systeme de cryptage | |
| FR3100631A1 (fr) | Méthode d’authentification sélective d’un utilisateur de chaine de blocs auprès d’un contrat intelligent | |
| US20230155815A1 (en) | Secure integer comparison using binary trees | |
| EP3861670A1 (fr) | Methode de transchiffrement a faible latence de calcul appliquee au chiffrement homomorphe | |
| FR3055720A1 (fr) | Procede de stockage securise d’un fichier source numerique. | |
| US11356254B1 (en) | Encryption using indexed data from large data pads | |
| FR3062499A1 (fr) | Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant | |
| Santos et al. | Enhancing medical data security on public cloud | |
| FR3107416A1 (fr) | Tokenisation aléatoire efficace dans un environnement dématérialisé | |
| FR2916317A1 (fr) | Protection d'execution d'un calcul cryptographique | |
| EP3545448A1 (fr) | Procédé d'insertion de données à la volée dans une base de données tatouées et dispositif associé | |
| EP3777007A1 (fr) | Procédés, dispositifs et programmes d'ordinateur pour le chiffrement et le déchiffrement de données pour la transmission ou le stockage de données | |
| EP3776871B1 (fr) | Récupération d'effacement dans un système de stockage distribué | |
| Coles | Evaluating Social Media as a Medium of Private Communication Through Steganographic Images | |
| FR3107128A1 (fr) | Procédé et dispositif d'évaluation de correspondance d'ensembles de données structurées protégées par le chiffrement | |
| Sankari et al. | Proposed iPrivacy based image encryption in mobile cloud | |
| FR3060148A1 (fr) | Procede d'emission d'un message, procede de reception, dispositif d'emission, dispositif de reception et systeme de communication associes | |
| EP4262141A1 (fr) | Methode d'interrogation confidentielle multi-utilsateur de la présence d'un enregistrement dans une base de données | |
| FR3105850A1 (fr) | Procédé de codage d'un motif d'intégrité cryptographique de faible taille et dispositifs associés |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20180309 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| FC | Decision of inpi director general to approve request for restoration |
Effective date: 20190711 |
|
| RN | Application for restoration |
Effective date: 20190710 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| ST | Notification of lapse |
Effective date: 20240505 |