FR3141538A1 - Procede et dispositif de stockage en ligne reparti de fichiers dans un contexte zero confiance - Google Patents

Abstract

La présente invention concerne un procédé et un système de stockage sécurisé zéro connaissance géré par un serveur relai connecté à une pluralité de services de stockage en ligne, le fichier à stocker étant divisé en une pluralité de fragments sauvegardés sur la pluralité de services de stockage en ligne, chaque service de stockage en ligne étant à même de vérifier l’identité de l’utilisateur requérant un fichier, l’identifiant du fichier original et le lien entre l’identifiant du fichier original et l’identifiant de fragment sans acquérir de connaissance sur l’identifiant du fichier original. [Fig. 3b]

Description

PROCEDE ET DISPOSITIF DE STOCKAGE EN LIGNE REPARTI DE FICHIERS DANS UN CONTEXTE ZERO CONFIANCE

La présente invention concerne le domaine du stockage de fichiers informatiques en ligne auprès d’une pluralité de services de stockage dans un contexte où la sécurité du service n’implique pas de relation de confiance entre les différents acteurs.

Les services de stockage en ligne de fichiers informatiques se sont développés ces dernières années. Les grands noms de l’informatique, proposent presque tous leur propre service. Aux côtés de ses grands acteurs, de multiples sociétés ont également développé leur propre service à destination tant des particuliers que des entreprises. Ces dernières sont nombreuses aujourd’hui à adopter ces services pour sauvegarder leurs données.

L’utilisation d’un service de stockage en ligne permet en effet d’éviter la mise en place et la gestion au quotidien d’un stockage, de ses sauvegardes et de sa sécurité. Il permet également de mutualiser les coûts du service entre les différents clients.

La sécurité informatique est également un sujet de plus en plus sensible. Les exemples de piratage d’entreprises et de services en ligne se multiplient. Même sans intention malveillante, un exemple récent d’incendie dans un centre de données d’un important acteur de services en ligne a pu provoquer la perte de leurs données pour un nombre important de ses clients.

Dans ce contexte, l’amélioration de la sécurité et de la fiabilité des services de stockage en ligne est un souci constant.

L’invention se place dans le contexte où un service sécurisé de stockage en ligne est géré par un serveur relai (proxy serveren anglais) qui fait le lien entre l’utilisateur du service et une pluralité de services de stockage en ligne. Le terme serveur est ici utilisé de manière fonctionnelle et peut référer à diverses implémentations physiques du serveur relai comprenant un ou plusieurs serveurs physiques. Le terme utilisateur désigne un terminal informatique utilisé par l’utilisateur humain pour accéder au service. Lorsque nous utilisons ce terme d’utilisateur dans la description des procédés proposés, il s’agit d’actions effectuées par le terminal de l’utilisateur sous son contrôle et non pas d’actions faites par l’utilisateur humain.

L’utilisateur du service sécurisé de stockage en ligne ne communique qu’avec le serveur relai et n’a pas connaissances des différents services de stockage en ligne utilisés. De même, chaque service de stockage en ligne ne communique qu’avec le serveur relai et n’a pas connaissance des autres services en ligne ni de l’utilisateur.

Le fonctionnement général du service sécurisé de stockage en ligne est illustré par la . L’utilisateur 101 transmet au serveur relai 102 un fichier 106 à stocker. Le serveur relai 102 applique au fichier 106 une fonction de dispersion générant des fragments 107, 108, 109 à partir du fichier initial 106. Ces fragments sont stockés par le serveur relai 102 sur les différents services de stockage en ligne 103, 104, 105. C’est l’opération de téléversement (uploaden anglais).

Lorsque l’utilisateur 101 veut retrouver le fichier stocké, il soumet une requête en téléchargement (downloaden anglais) au serveur relai 102. Le serveur relai 102 requiert alors les différents fragments 107, 108, 109 aux différents services de stockage en ligne 103, 104, 105. A partir de ces fragments 107, 108, 109, il reconstitue le fichier initial 106 et le transmet à l’utilisateur 101.

La figure illustre trois services de stockage en ligne. Cette figure n’est qu’un exemple et le nombre de services en ligne utilisé par un mode de réalisation particulier de l’invention peut être quelconque avec un minimum de deux services. De manière similaire, la figure illustre la sauvegarde d’un seul fragment par service de stockage en ligne. Dans la pratique, plusieurs fragments peuvent être stockés sur un même service de stockage en ligne.

Avantageusement, ces fragments comportent un certain degré de redondance pour permettre la reconstitution du fichier initial à partir seulement d’un sous-ensemble de l’intégralité des fragments disponibles pour ce fichier. Cette propriété apporte la résilience du système face à la perte potentielle ou la compromission d’un service de stockage en ligne.

Avantageusement, les communications entre l’utilisateur et le serveur relai ainsi qu’entre le serveur relai et les services de stockage en ligne utilisent des tunnels chiffrés permettant de garantir la confidentialité des échanges. Chaque acteur du système est authentifié auprès des acteurs avec lesquels il communique. L’utilisateur, en particulier, doit être authentifié auprès du système qui lui délivre un jeton d’accès qui peut être vérifié par le serveur relai et/ou les services de stockage en ligne.

L’utilisateur dispose également d’une clé de signature lui permettant de signer ses messages. Cette signature peut être vérifiée, et donc les messages authentifiés comme provenant bien de l’utilisateur par le serveur relai et les services de stockage en ligne. Cette clé de signature peut être symétrique ou asymétrique.

Avantageusement, la fonction de dispersion permet de garantir que la connaissance d’un seul fragment ne permet pas à un service de stockage en ligne de reconstituer le fichier initial. Dans le cas où le système utilise de la redondance et où plusieurs fragments sont stockés sur un même service de stockage en ligne, le système assure que le nombre de fragments stockés sur un même service de stockage en ligne ne permet pas de reconstituer le service.

En termes de sécurité, il est avantageux de proposer un service de stockage dit zéro confiance entre les différents acteurs. Ainsi la compromission de l’un des acteurs ne compromet pas la sécurité de la solution. Dans le cas présent, la zéro confiance se traduit par trois contraintes que l’on souhaite voir respecter par le système.

Selon une première contrainte, un service de stockage en ligne doit être capable de vérifier qu’une requête reçue du serveur relai provient bien de l’utilisateur légitime. Cette contrainte doit garantir que le serveur relai n’est pas en capacité de forger une requête valide qui ne proviendrait pas effectivement de l’utilisateur légitime. Ainsi, la compromission du serveur relai, par exemple par son piratage par des individus malveillants, ne permet pas aux pirates d’obtenir les fichiers des utilisateurs.

Selon une seconde contrainte, un service de stockage en ligne ne doit pas être en capacité d’identifier que deux fragments qui sont stockés par son service sont issus d’un même fichier original. Ainsi, chaque fragment est indépendant et ne peut être associé à d’autres fragments du même fichier original afin d’interdire toute reconstruction de ce fichier original, même partielle, par le service de stockage en ligne.

Selon une troisième contrainte, un service de stockage en ligne doit être en mesure de vérifier la validité du lien entre le fragment qu’il possède et le fichier original. Ceci en respectant la seconde contrainte qui ne lui permet pas d’obtenir ce lien.

L’invention vise à offrir un service sécurisé de stockage en ligne sur la base d’un serveur relai et d’une pluralité de services de stockage en ligne respectant ces contraintes.

Selon un aspect de l’invention il est proposé un procédé de stockage sécurisé d’un fichier original caractérisé en ce qu’il comprend les étapes suivantes :
- réception du fichier original, transmis par un dispositif utilisateur, par un serveur relai connecté à une pluralité de services de stockage en ligne, le fichier original étant associé à un identifiant de fichier original ;
- génération par le serveur relai d’une pluralité de fragments à partir du fichier original, chaque fragment étant associé à un identifiant de fragment ;
- transmission pour sauvegarde par le serveur relai de chaque fragment à un service de stockage en ligne parmi la pluralité de service de stockage en ligne ;
où pour télécharger le fichier original stocké, le procédé comprend les étapes suivantes :
- réception par le serveur relai d’une requête pour le fichier original comprenant l’identifiant de fichier original et un ensemble de données utilisateur ;
pour chaque fragment :
- transmission d’une requête pour le fragment comprenant l’identifiant de fragment et un ensemble de donnée de fragment au service de stockage en ligne ;
- vérification par le service de stockage en ligne, à partir des données de fragment, sans acquérir de connaissance sur l’identifiant de fichier original, que :
- la requête provient de l’utilisateur ayant transmis la requête pour le fichier original ;
- l’identifiant de fragment de la requête de fragment correspond à l’identifiant du fichier original ;
- lorsque la vérification est positive transmission du fragment au serveur relai ;
- génération du fichier original à partir des fragments reçus ; et
- transmission du fichier original au dispositif utilisateur.

Selon un mode de réalisation :
- l’ensemble de données utilisateur et l’ensemble de données fragment comprennent une version chiffrée et signée de l’identifiant de fichier original permettant de vérifier que la requête provient de l’utilisateur ayant transmis la requête pour le fichier original.

Selon un mode de réalisation :
- le serveur relai génère une preuve zéro connaissance basée sur l’identifiant du fichier original et sur l’identifiant de fragment permettant de vérifier que l’identifiant de fragment de la requête de fragment correspond à l’identifiant du fichier original sans apporter de connaissance sur l’identifiant original, cette preuve zéro connaissance étant comprise dans l’ensemble de données fragment.

Selon un mode de réalisation :
- le dispositif utilisateur génère un premier engagement basé sur l’identifiant de fichier original, cet engagement étant compris dans les données utilisateur et dans les données fragment ;
- le serveur relai génère un second engagement conjoint basé l’identifiant de fichier original et sur l’identifiant de fragment, cet engagement conjoint étant compris dans les données fragment ;
- le service de stockage en ligne vérifie conjointement les premier et second engagements.

Selon un autre aspect de l’invention il est proposé un programme d’ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l’invention lorsque ledit programme est exécuté sur un ordinateur.

Selon un autre aspect de l’invention il est proposé un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l’invention.

Selon un autre aspect de l’invention il est proposé un système comprenant un dispositif utilisateur, un serveur relai et une pluralité de service de stockage en ligne configurés pour mettre en œuvre un procédé selon l’invention.

Aux dessins annexés, donnés à titre d'exemples non limitatifs :

la illustre l’architecture générale et le fonctionnement d’un service sécurisé de stockage en ligne selon un mode de réalisation de l’invention;

les figures 2a et 2b illustrent le fonctionnement général du téléversement et du téléchargement d’un fichier;

Les figures 3a et 3b illustrent un premier mode de réalisation de l’invention ;

La illustre un second mode de réalisation

La est un bloc-diagramme schématique d'un dispositif de traitement de l’information pour la mise en œuvre d'un ou plusieurs modes de réalisation de l'invention.

Les figures 2a et 2b illustrent le fonctionnement général du téléversement, , et du téléchargement, , d’un fichier.

Sur ces figures un seul service de stockage en ligne 203 est représenté. Le même fonctionnement s’applique à la pluralité de services de stockage en ligne connectés au serveur relai 202.

Le téléversement du fichier est illustré par la . L’utilisateur 201 transmet le fichier original à sauvegarder 204 au serveur relai 202. Ce dernier attribue un identifiant 207 Id_o au fichier original, le transmet à l’utilisateur 201 qui le stocke 210.

Le serveur relai applique la fonction de dispersion pour générer les fragments à partir du fichier original. Le fonctionnement de la fonction de dispersion n’est pas le sujet du présent document. La figure illustre un fragment 205 de cette pluralité de fragments. Le fragment 205 est transmis au service de stockage en ligne 203 qui lui attribue un identifiant de fragment Id_f 206 et mémorise le lien 208 entre le fragment 205 et son identifiant Id_f 206. Le service de stockage en ligne transmet cet identifiant de fragment 206 au serveur relai qui mémorise l’association 209 entre l’identifiant du fichier original Id_o et l’identifiant de fragment Id_f. Les autres fragments générés par le serveur relai reçoivent le même traitement non représenté sur la figure.

Le téléchargement illustré par la présente un fonctionnement symétrique. L’utilisateur 201 transmet au serveur relai 202 une requête comprenant l’identifiant Id_o 207 du fichier qu’il souhaite télécharger. Le serveur relai retrouve l’identifiant de fragment associé Id_f qu’il utilise pour construire une requête comprenant cet identifiant qu’il transmet au service de stockage en ligne 203. A l’aide de l’identifiant de fragment Id_f, le service de stockage en ligne 203 retrouve le fragment associé 205 et le transmet au serveur relai 202. Ce dernier, quand il a récupéré la totalité des fragments, ou au moins un nombre suffisant si la redondance est mise en œuvre, reconstruit le fichier original 204 en utilisant la fonction inverse de la fonction de dispersion. Le serveur relai peut alors transmettre le fichier original 204 ainsi obtenu à l’utilisateur.

Dans ce contexte, les trois contraintes pour atteindre le niveau de sécurité désiré zéro confiance se traduisent par les contraintes suivantes :

Selon la première contrainte, le service de stockage en ligne doit être en mesure de vérifier que la requête reçue pour le fragment provient bien de l’utilisateur légitime. Selon la seconde contrainte, le service de stockage en ligne ne doit pas être en mesure de connaître l’identifiant Id_o du fichier original. Selon la troisième contrainte, le service de stockage en ligne doit être en mesure de vérifier que l’identifiant de fragment demandé Id_f correspond bien à l’identifiant du fichier original Id_o, et cela sans connaître cet identifiant du fichier original Id_o selon la seconde contrainte.

Les solutions proposées dans ce document pour permettre de répondre aux contraintes de sécurité exposées sont basée sur l’utilisation d’outils cryptographiques. Parmi ces outils nous citerons les fonctions suivantes :

La fonction KEYGEN qui permet de générer une clé cryptographique. La clé générée peut être une clé symétrique ou asymétrique.

Une clé symétrique est une clé partagée entre deux acteurs qui permet le chiffrement d’un contenu pour obtenir un contenu chiffré. La même clé est nécessaire pour déchiffrer le contenu chiffré et retrouver le contenu d’origine. Cette clé constitue un secret partagé entre l’émetteur du contenu chiffré qui procède au chiffrement et le récepteur du contenu chiffré qui procède au déchiffrement.

Une clé asymétrique est composée d’une paire de clés, une clé dite privée et une clé dite publique. Pour échanger du contenu chiffré entre deux acteurs, chacun possède sa propre clé asymétrique. Chaque acteur garde secret sa clé privée et diffuse sa clé publique. Dans ce cas, l’émetteur qui procède au chiffrement d’un contenu chiffre celui-ci à l’aide de sa clé privée et de la clé publique du récepteur. Ce dernier déchiffre le contenu à l’aide de sa propre clé privée et de la clé publique de l’émetteur.

La fonction ENC(k, m) représente le chiffrement d’un contenu ‘m’ à l’aide de la clé ‘k’. Il s’agit ici d’une clé symétrique, typiquement issue de la fonction KEYGEN. Une clé asymétrique peut également être utilisée.

La fonction DEC(k, c) représente le déchiffrement d’un contenu chiffré ‘c’ à l’aide de la clé ‘k’. C’est la fonction inverse de la fonction ENC(k, m).

La fonction SIGN(k, m) produit une signature cryptographique du contenu ‘m’ à l’aide de la clé ‘k’. Cette fonction ne chiffre pas le contenu et le laisse lisible. L’émetteur d’un contenu ‘m’ peut signer ce contenu à l’aide de cette fonction. Il transmet alors le contenu ‘m’ et la signature ainsi calculée. Le récepteur du contenu ‘m’ peut vérifier la signature, par exemple à l’aide de la même fonction et de la même clé ou des fonctions de vérification selon le mode de réalisation. Si la signature ainsi obtenue correspond à la signature reçue, cela signifie que le contenu ‘c’ n’a pas été altéré et qu’il a bien été signé par le possesseur de la clé ‘k’. Dans le mode de réalisation privilégié, la clé de signature est différente de la clé utilisée pour chiffrer/déchiffrer les messages.

La fonction HASH(m) est une fonction mathématique non inversible qui produit à partir d’un contenu ‘m’ de longueur quelconque une valeur de taille fixe. La probabilité que deux contenus différents m1 et m2 produise la même valeur de hash est suffisamment faible pour que l’on considère la fonction HASH comme permettant de vérifier l’intégrité du contenu ‘m’.

La fonction ZK-proof(m) utilisée par un producteur P, produit une preuve que P connaît le secret S, m étant le résultat de la fonction f connue appliquée à S. La preuve pouvant être vérifiée par un vérificateur V qui peut alors vérifier que P connaît S, sans qu’aucune connaissance sur S ne soit transmise à V. Différentes fonctions ZK-proof sont connues et peuvent être utilisées indifféremment dans les différents modes de réalisation de l’invention. Par exemple, des fonctions ZK-proof sont décrites dans les documents suivants : « Pinocchio: Parno, B., Howell, J., Gentry, C., and Raykova, M. Pinocchio: Nearly practical verifiable computation. In 2013 IEEE Symposium on Security and Privacy, SP 2013, Berkeley, CA, USA, May 19-22, 2013 (2013), pp. 238–252 », ou « Ligero: Scott Ames, Carmit Hazay, Yuval Ishai, and Muthuramakrishnan Venkitasubramaniam. Ligero: Lightweight sublinear arguments without a trusted setup. In ACM CCS 2017, pages 2087–2104. ACM Press, 2017 ».

Les figures 3a et 3b illustrent un premier mode de réalisation de l’invention. La illustre le téléversement selon ce mode de réalisation, tandis que la illustre le téléchargement.

Pour réaliser le téléversement, l’utilisateur 201, transmet le fichier original 204 à stocker au serveur relai 202. Ce dernier applique la fonction de dispersion et génère les fragments issus du fichier original. Il associe également le fichier original à l’identifiant de fichier original 207 Id_o qu’il transmet en retour à l’utilisateur 201. Nous décrivons le traitement d’un de ces fragments, le fragment 205 qui est transmis au service de stockage en ligne 203 pour stockage. Le service de stockage en ligne 203 mémorise le fragment et l’associe à un identifiant de fragment Id_f qui est renvoyé au serveur relai. Le serveur relai calcule alors un hash des deux identifiants, l’identifiant du fichier original Id_o et de l’identifiant du fragment Id_f, qui correspond à l’application de la fonction de hash aux deux identifiants : « HASH(Id_o, Id_f) » également noté en raccourci « H(Id_o, Id_f) ». Cette valeur de hash est transmise au service de stockage en ligne qui le mémorise avec l’identifiant Id_f et l’associe au fragment via l’association 308. Alternativement, l’identifiant de fragment Id_f peut être généré directement par le serveur relai qui peut alors calculer le hash directement afin d’éviter un aller-retour avec le service de stockage. L’utilisateur dispose également d’une clé de signature « Sign_key » qu’il mémorise 310 ainsi que l’identifiant de fichier original Id_o. Cette clé est typiquement une clé asymétrique grâce à laquelle, l’utilisateur peut signer E à l’aide de sa clé privée. Le serveur relai et le service de stockage en ligne sont capables de vérifier cette signature à l’aide de la clé publique, mais ne sont pas capables de générer une éventuelle fausse signature sans connaître la clé privée de l’utilisateur.

Concernant le téléchargement, l’utilisateur génère une clé K à l’aide de la fonction KEYGEN. A l’aide de cette clé, l’utilisateur chiffre l’identifiant du fichier original Id_o pour obtenir un identifiant chiffré E=ENC(K, Id_o). Il utilise ensuite sa clé de signature pour signer l’identifiant chiffré E ainsi obtenu.

Ensuite, l’utilisateur transmet au serveur relai, référence 307, la clé K, l’identifiant chiffré E et sa signature SIGN(Sign_key, E).

Le serveur relai est alors en mesure de vérifier que l’identifiant chiffré E est bien émis par l’utilisateur en vérifiant la signature électronique de E. Il peut également déchiffrer l’identifiant du fichier d’origine à l’aide de la clé K. Il peut alors retrouver l’identifiant du fragment Id_f à l’aide de l’association mémorisée, référence 209, entre l’identifiant du fichier original et l’identifiant du fragment. Enfin, le serveur relai calcule la preuve ZK-proof(H(DEC(K, E), Id_f)).

Le serveur transmet alors au service de stockage en ligne, référence 306, l’identifiant Id_f du fragment demandé, la preuve ZK-proof(H(DEC(K, E), Id_f)), l’identifiant chiffré E et sa signature par l’utilisateur SIGN(Sign_key, E).

Le service de stockage en ligne est alors en mesure de vérifier la preuve ZK-proof(H(DEC(K, E), Id_f)), ce qui permet de vérifier que le serveur relai possède bien la connaissance de la clé K sans avoir accès à cette clé K. Il faut comprendre que ici, la fonction f(x) de la preuve correspond à la fonction H(DEC(x, E), Id_f). Cela permet au service de stockage en ligne de valider que la valeur chiffrée de Id_o, c’est-à-dire E a bien été utilisée pour le calcul. Il peut également vérifier que cette valeur chiffrée provient bien de l’utilisateur en vérifiant la signature de E. La valeur de hash permet quant à elle de vérifier le lien entre Id_o et Id_f, et ceci toujours sans acquérir de connaissance sur Id_o.

Il peut être constaté que les trois contraintes zéro-connaissance sont respectées par le système lors de l’étape de téléchargement. Le service de stockage en ligne peut vérifier que la requête reçue provient bien de l’utilisateur légitime par la vérification de la signature de la valeur chiffrée de Id_o, première contrainte. Le service de stockage en ligne n’obtient aucune information sur l’identifiant du fichier original Id_o, seconde contrainte. Le service de stockage en ligne peut finalement vérifier que l’identifiant de fragment demandé, Id_f, correspond bien à l’identifiant du fichier original Id_o, via le hash des deux identifiants, toujours sans connaître Id_o, troisième contrainte. Le système proposé permet également de garantir que le serveur relai ne peut pas forger une requête ne provenant pas de l’utilisateur car il ne peut pas générer une signature valide de E.

Une fois ces contraintes vérifiées, le service de stockage en ligne transmet le fragment demandé 205 au serveur relai qui reconstitue, à l’aide de l’ensemble des fragments ainsi récupérés, le fichier initial 204 pour le transmettre à l’utilisateur.

Le système proposé permet de garantir la sécurité des données des utilisateurs, même en cas de compromission du serveur relai ou d’un ou des services de stockage en ligne utilisés.

La illustre un second mode de réalisation. Contrairement au premier mode de réalisation qui est basé sur une preuve de calcul (proof of computationen anglais), ce second mode de réalisation est basé sur une preuve de connaissance (proof of knowledgeen anglais).

Pour éviter le stockage de Id_o, un engagement conjoint (joint commitmenten anglais) des deux identifiants Id_o et Id_f permet au serveur relai de prouver au service de stockage en ligne le lien entre Id_o et Id_f sans révéler d’information sur Id_o. Ce faisant, il est possible de satisfaire les seconde et troisième contraintes.

Il est également possible d’utiliser un second engagement par l’utilisateur pour permettre au serveur relai de prouver au service de stockage en ligne la connaissance de l’identifiant de fichier original Id_o. L’utilisateur peut également signer ce second engagement pour apporter en plus la preuve que cet identifiant de fichier original est bien issu de l’utilisateur. La vérification séparée des deux engagements ne permet pas de vérifier que la valeur de l’identifiant du fichier original Id_o utilisée lors de chacun des engagements est la même. Pour ce faire et ainsi permettre le respect des trois contraintes, il est nécessaire de procéder à une unique étape de vérification conjointe des deux engagements. Ainsi, la vérification permet de garantir, en cas de succès, que le même identifiant Id_o a été utilisée lors de la génération des deux engagements. La vérification de cet identifiant Id_o est alors complète et permet de satisfaire également la première contrainte.

La preuve de connaissance permettant la vérification conjointe des deux engagements peut, par exemple, être basée sur un ensemble de représentations linéaires décrite par [MAU09] (Ueli M. Maurer: Unifying Zero-Knowledge Proofs of Knowledge. AFRICACRYPT 2009) qui généralise les preuves de Schnorr [SCH89] (Schnorr, C.P.: Efficient identification and signatures for smart cards. CRYPTO 1989).

Dans un exemple de réalisation, la preuve de connaissance peut fonctionner comme suit :

Soit le prouveur et le vérificateur. Soient les espaces et ou est un groupe cyclique d’ordre . Soient trois générateurs publics distincts de H, par distincts il faut comprendre que leur logs discrets dans H ne doivent pas être liés mathématiquement.

Définissons l’homomorphisme de groupe qui associe à la valeur , la valeur . Il est à noter ici que les deux composantes du couple définissant l’homomorphisme de groupe vont permettre d’exprimer chacun respectivement les deux engagements utilisés dans ce mode de réalisation. C’est la forme de cet homomorphisme de groupe qui va permettre la vérification conjointe des deux engagements permettant de valider que la même valeur de Id_o est utilisée dans le calcul des deux engagements.

Soit un secret connu de , mais pas de . La valeur associée à dans le groupe est la valeur . Cette valeur est supposée connue de qui va l’utiliser pour vérifier que est bien en possession de . La vérification peut se dérouler de la manière suivante :

Dans une première étape, génère un nombre aléatoire correspondant à l’aléa de mise en gage du prouveur P et transmet à l’engagement associé .

Dans une seconde étape génère un challenge aléatoire , et transmet cette valeur à . Alternativement, il est possible de rendre la preuve non interactive, en remplaçant cette étape par une transformation de Fiat-Shamir.

Dans une troisième étape calcule :

;

Cette valeur est transmise à . Ce dernier peut alors calculer la valeur correspondant à dans et vérifier que cette valeur est bien égale à .

Cet exemple de preuve de connaissance peut être utilisée dans le système de stockage de fichiers. D’autres preuves de connaissance pourraient également être utilisées de manière similaire.

La illustre un mode de réalisation basé sur les preuves de connaissances comme celles qui vient d’être décrite.

Concernant le téléversement, ce dernier est similaire au téléversement utilisé dans le mode de réalisation précédent sauf sur le calcul d’un engagement conjoint par le serveur relai des deux identifiants Id_o et Id_f. Rand_f étant un nombre aléatoire généré par le serveur relai. Cet engagement conjoint est transmis au service de stockage en ligne et mémorisé par ce dernier associé, référence 408, au fragment. La valeur aléatoire Rand_f est mémorisée, référence 409, par le serveur relai.

Concernant le téléchargement, lors d’une première étape 410, l’utilisateur calcule un premier engagement à l’aide d’un nombre aléatoire qu’il génère pour l’occasion. L’utilisateur signe cet engagement à l’aide de sa clé de signature Sign_key. L’utilisateur transmet alors l’identifiant de fichier original Id_o, la signature de l’engagement et la valeur aléatoire Rand_n utilisée pour le calcul de l’engagement au serveur relai.

Lors d’une étape 407, les valeurs de Id_o, de la valeur aléatoire Rand_n et la signature du premier engagement sont transmises au serveur relai. Il n’est pas nécessaire de transmettre l’engagement lui-même, car ce dernier peut être calculé par le serveur relai à l’aide des valeurs transmises. Il faut rappeler ici que les valeurs générateur du groupe H sont supposées connues de l’ensemble des acteurs du système.

Lors de l’étape 411, le serveur relai calcule le premier engagement E, ainsi que le second engagement , à l’aide d’une valeur aléatoire Rand_f qui correspond à celle utilisée lors du téléversement. Une autre valeur aléatoire est générée et utilisée pour le calcul de la valeur correspondante K correspondant à l’engagement de k, . Le serveur relai calcule alors la valeur , qui correspond au challenge du vérificateur V et finalement la valeurr= k+ c .( Id_f , Id_o , Rand_f , Rand_n )qui correspond au témoin de preuve.

Lors de l’étape 408, les valeurs Id_f, l’engagement de k K, le témoin de preuve r, E et la signature de E par l’utilisateur sont transmises au service de stockage en ligne.

Lors de l’étape 412, le service de stockage est alors en mesure de procéder aux calculs suivants :

Le service de stockage en ligne vérifie la signature du premier engagement E, ce qui permet de valider que la valeur Id_o utilisée est bien issue de l’utilisateur. Il calcule ensuite le challenge , , la valeur , la valeur . Finalement, la vérification que permet de vérifier de manière conjointe les deux engagements E et L, ce qui permet de valider la connaissance par le serveur relai de l’identifiant de fichier original et le lien entre cet identifiant et l’identifiant du fragment demandé Id_f. Les trois contraintes sont donc vérifiées, ce qui permet de valider le transfert du fragment 205 au serveur relai. Ce dernier peut alors, une fois qu’il a reçu tous les fragments de tous les services de stockage en ligne, reconstituer le fichier original 204 et le transmettre à l’utilisateur.

La est un bloc-diagramme schématique d'un dispositif de traitement de l’information 500 pour la mise en œuvre d'un ou plusieurs modes de réalisation de l'invention. Le dispositif 500 de traitement de l’information peut être un périphérique tel qu'un micro-ordinateur, un poste de travail ou un terminal mobile de télécommunication. Le dispositif 500 comporte un bus de communication connecté à :

- une unité centrale de traitement 501, tel qu'un microprocesseur, notée CPU;

- une mémoire à accès aléatoire 502, notée RAM, pour mémoriser le code exécutable du procédé de réalisation de l'invention ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en œuvre du procédé selon des modes de réalisation de l'invention ; la capacité de mémoire du dispositif peut être complétée par une mémoire RAM optionnelle connectée à un port d'extension, par exemple ;

- une mémoire morte 503, notée ROM, pour stocker des programmes informatiques pour la mise en œuvre des modes de réalisation de l'invention ;

- une interface réseau 504 est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmis ou reçus. L'interface réseau 504 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil). Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur 501 ;

- une interface utilisateur 505 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur ;

- un dispositif de stockage 506 tel que décrit dans l’invention et noté HD ;

- un module d’entrée/sortie 507 pour la réception / l'envoi de données depuis / vers des périphériques externes tels que disque dur, support de stockage amovible ou autres.

Le code exécutable peut être stocké dans une mémoire morte 503, sur le dispositif de stockage 506 ou sur un support amovible numérique tel que par exemple un disque. Selon une variante, le code exécutable des programmes peut être reçu au moyen d'un réseau de communication, via l'interface réseau 504, afin d'être stocké dans l'un des moyens de stockage du dispositif de communication 500, tel que le dispositif de stockage 506, avant d'être exécuté.

L'unité centrale de traitement 501 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation de l'invention, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 501 est capable d'exécuter des instructions de la mémoire RAM principale 502, relatives à une application logicielle. Un tel logiciel, lorsqu'il est exécuté par le processeur 501, provoque l’exécution des procédés décrits.

Dans ce mode de réalisation, l'appareil est un appareil programmable qui utilise un logiciel pour mettre en œuvre l'invention. Toutefois, à titre subsidiaire, la présente invention peut être mise en œuvre dans le matériel (par exemple, sous la forme d'un circuit intégré spécifique ou ASIC).

Claims (7)

1. Procédé de stockage sécurisé d’un fichier original caractérisé en ce qu’il comprend les étapes suivantes :
   - réception du fichier original, transmis par un dispositif utilisateur, par un serveur relai connecté à une pluralité de services de stockage en ligne, le fichier original étant associé à un identifiant de fichier original ;
   - génération par le serveur relai d’une pluralité de fragments à partir du fichier original, chaque fragment étant associé à un identifiant de fragment ;
   - transmission pour sauvegarde par le serveur relai de chaque fragment à un service de stockage en ligne parmi la pluralité de service de stockage en ligne ;
   où pour télécharger le fichier original stocké, le procédé comprend les étapes suivantes :
   - réception par le serveur relai d’une requête pour le fichier original comprenant l’identifiant de fichier original et un ensemble de données utilisateur ;
   pour chaque fragment :
   - transmission d’une requête pour le fragment comprenant l’identifiant de fragment et un ensemble de donnée de fragment au service de stockage en ligne ;
   - vérification par le service de stockage en ligne, à partir des données de fragment, sans acquérir de connaissance sur l’identifiant de fichier original, que :
   - la requête provient de l’utilisateur ayant transmis la requête pour le fichier original ;
   - l’identifiant de fragment de la requête de fragment correspond à l’identifiant du fichier original ;
   - lorsque la vérification est positif transmission du fragment au serveur relai ;
   - génération du fichier original à partir des fragments reçus ; et
   - transmission du fichier original au dispositif utilisateur.
2. Procédé selon la revendication 1, caractérisé en ce que :
   - l’ensemble de données utilisateur et l’ensemble de données fragment comprennent une version chiffrée et signée de l’identifiant de fichier original permettant de vérifier que la requête provient de l’utilisateur ayant transmis la requête pour le fichier original.
3. Procédé selon la revendication 1, caractérisé en ce que :
   - le serveur relai génère une preuve zéro connaissance basée sur l’identifiant du fichier original et sur l’identifiant de fragment permettant de vérifier que l’identifiant de fragment de la requête de fragment correspond à l’identifiant du fichier original sans apporter de connaissance sur l’identifiant original, cette preuve zéro connaissance étant comprise dans l’ensemble de données fragment.
4. Procédé selon la revendication 1, caractérisé en ce que :
   - le dispositif utilisateur génère un premier engagement basé sur l’identifiant de fichier original, cet engagement étant compris dans les données utilisateur et dans les données fragment ;
   - le serveur relai génère un second engagement conjoint basé l’identifiant de fichier original et sur l’identifiant de fragment, cet engagement conjoint étant compris dans les données fragment ;
   - le service de stockage en ligne vérifie conjointement les premier et second engagements.
5. Programme d’ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l’une quelconque des revendications 1 à 4 lorsque ledit programme est exécuté sur un ordinateur.
6. Moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 4.
7. Système comprenant un dispositif utilisateur, un serveur relai et une pluralité de service de stockage en ligne configurés pour mettre en œuvre un procédé selon l’une des revendications 1 à 4.