Brevet FR3146220A1 — publié le 20240830

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. Le fichier à sauvegarder étant soumis à une fonction de transformation tout ou rien et à un chiffrement totalement homomorphe au moins partiel avant sa transmission pour sauvegarde au serveur relai. 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 server en 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 ( upload en anglais). Lorsque l’utilisateur 101 veut retrouver le fichier stocké, il soumet une requête en téléchargement ( download en 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 fichier. 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, nous nous intéressons à la confidentialité des échanges et aux moyens mis en œuvre pour assurer que le serveur relai et les services de stockage ne puissent pas accéder à l’information sauvegardée par l’utilisateur. Cette confidentialité doit être assurée sans requérir la gestion de clés dans le temps par l’utilisateur. Pour ce faire, cinq contraintes sont imposées au système. Selon une première contrainte, l’utilisateur ne doit pas devoir gérer de clés persistantes. Selon une seconde contrainte, l’utilisateur ne doit pas avoir la connaissance des services de stockage en ligne. Selon une troisième contrainte, les services de stockage en ligne ne doivent pas pouvoir acquérir de connaissance, même partielle du contenu original stocké par l’utilisateur. Selon une quatrième contrainte, le serveur relai ne doit pas être en mesure d’acquérir la moindre information sur le contenu original de l’utilisateur. Selon une cinquième contrainte, l’utilisateur ne doit avoir besoin que d’une requête pour obtenir une réponse valide du service. 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 pour téléverser un fichier original: - réception du fichier original, transmis par un dispositif utilisateur, par un serveur relai connecté à une pluralité de services de stockage en ligne ; - application d’une fonction de dispersion par le serveur relai pour générer une pluralité de fragments à partir du fichier original reçu ; - 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 ; caractérisé en ce que : - le fichier original est transformé en pseudo-message par le dispositif utilisateur à l’aide d’une fonction de transformation tout ou rien ; - le pseudo-message est chiffré, au moins en partie, par le dispositif utilisateur à l’aide d’une clés secrète partagée avec la pluralité de service de stockage en ligne, le chiffrement étant homomorphe, le fichier original reçu par le serveur relai étant le pseudo-message chiffré ; - la fonction de dispersion est appliquée sur le pseudo-message chiffré et génère des fragments chiffrés ; - les fragments chiffrés sont déchiffrés par les services de stockage en ligne avant stockage. Un mode de réalisation est caractérisé en ce que : - la clé secrète est partagée entre le dispositif utilisateur et les services de stockage en ligne par un protocole d’échange de clé sécurisé. Un mode de réalisation est caractérisé en ce que : - le protocole d’échange de clé sécurisé est le protocole de Diffie-Hellman. Un mode de réalisation est caractérisé en ce que : - le protocole d’échange de clé sécurisé est le protocole d’échange de clé sécurisé. Un mode de réalisation est caractérisé en ce que : - le protocole de Diffie-Hellman est basé sur une première clé asymétrique générée par le dispositif utilisateur et une seconde clé asymétrique partagée par les services de stockage en ligne. Un mode de réalisation est caractérisé en ce que : - une nouvelle première clé asymétrique est générée avant chaque échange par le dispositif utilisateur. Un mode de réalisation est caractérisé en ce qu’il comporte en outre les étape suivantes pour le téléchargement : - chiffrement des fragments par les services de stockage en ligne à l’aide d’une clé secrète partagée avec le dispositif utilisateur; - réception par le serveur relai des fragments chiffrés ; - application de la fonction de dispersion inverse par le serveur relai sur les fragments chiffrés pour générer un pseudo-message chiffré ; - transmission du pseudo-message chiffré au dispositif utilisateur ; - déchiffrement du pseudo-message chiffré par le dispositif utilisateur ; - application de la fonction inverse de transformation tout ou rien par le dispositif utilisateur pour retrouver le fichier original. 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. 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 mode de réalisation de l’invention ; 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, figure 2b, 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 figure 2b 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. 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 la clé publique du récepteur. Ce dernier déchiffre le contenu à l’aide de sa propre clé privée . 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 AONT (pour All Or Nothing Transform en anglais) est une fonction de transformation tout ou rien, c’est-à-dire sans clé, inversible, aléatoire ayant la propriété d’être très difficilement inversible si l’on ne connaît pas l’intégralité de son résultat. Cette fonction prend en entrée un message et génère un pseudo-message. L’opération inverse permettant de retrouver le message original à partir du pseudo-message nécessite de connaître l’intégralité du pseudo-message. Un simple fragment du pseudo-message ne permet pas de reconstruire, même partiellement, le message d’origine. Différents exemples de telles fonctions sont connus de l’homme du métier, dont la fonction décrite par Ronald L. Rivest dans son article de 1997 intitulé « All-Or-Nothing Encryption and The Package Transform ». La transformation proposée par Rivest consiste à prétraiter le texte en clair en effectuant un XOR de chaque bloc de texte en clair avec l'index de ce bloc chiffré par une clé choisie au hasard, puis en ajoutant un bloc supplémentaire calculé en effectuant un XOR de cette clé aléatoire et des hashs de tous les blocs prétraités. Le résultat de ce prétraitement est appelé le pseudo-message et sert d'entrée à l'algorithme de chiffrement. Pour annuler la transformation du paquet, il faut hacher tous les blocs du pseudo-message sauf le dernier, faire un XOR de tous les hachages avec le dernier bloc pour récupérer la clé aléatoire, puis utiliser la clé aléatoire pour reconvertir chaque bloc prétraité en son bloc original en clair. De cette façon, il est impossible de récupérer le texte en clair original sans avoir accès à l’intégralité des blocs du pseudo-message. D’autres fonctions AONT ont été proposées depuis. Dans le cadre de ce document, toute fonction AONT peut être utilisée indifféremment. La fonction HEenc(k, m) est une fonction de chiffrement homomorphe d’un message m par une clé k ayant la propriété suivante par rapport à une loi définie par deux opérateurs ( , ) : HEenc(k, m1) HEenc(k, m2) = HEenc(k, m1 m2) ; La fonction HEenc(k, m) est dite totalement homomorphe si la propriété d’homomorphisme est valable vis-à-vis de deux lois et qui permettent d’exprimer toute fonction calculable. Le chiffrement homomorphe permet d’effectuer des calculs sur des données chiffrées sans nécessiter leur déchiffrement. Le cas d’usage connu de ces méthodes de chiffrement est la sous-traitance de calculs à une entité non sûre. Les données à traiter sont chiffrées par une telle fonction totalement homomorphe avant leur transmission à l’entité. Cette dernière peut alors effectuer les traitements demandés sur les données chiffrées sans pouvoir accéder à ces données. Le résultat reçu de l’entité peut être décodé par le donneur d’ordre. Un exemple de fonction d’encodage totalement homomorphe est décrit dans l’article scientifique: I. Chillotti, N. Gama, M. Georgieva, and M. Izabachène. TFHE: Fast Fully Homomorphic Encryptionover the Torus. In Journal of Cryptology, volume 33. La fonction Diffie Hellman DH-Key permet un échange de clés entre deux agents, nommés par convention Alice et Bob, tel que cet échange permet aux deux agents de partager un secret sans que les échanges ne révèlent ce secret. Si Alice dispose d’une clé secrète DH_S_A et d’une clé publique correspondante DH_P_A, tandis que Bob dispose de la clé secrète DH_S_B et de la clé publique correspondante DH_P_B, et que Alice et Bob s’échangent leurs clés publiques DH_P_A et DH_P_B, la fonction Diffie Hellman permet aux deux agents Alice et Bob de calculer la même valeur K, pouvant servir de clé, de la façon suivante : K = DH-Key(DH_P_B, DH_S_A) = DH-Key(DH_P_A, DH_S_B) ; Un agent malveillant interceptant les échanges entre Alice et Bob n’acquière la connaissance que des clés publiques de Alice et Bob qui ne permettent pas, en l’absence des clés privées, le calcul de K. La clé K permet ensuite à Alice et Bob, par exemple, de chiffrer leurs communications. L’invention repose sur la mise en œuvre d’un chiffrement du fichier à sauvegarder par l’utilisateur. Nous rappelons que l’une des contraintes est de ne pas devoir imposer une gestion de clés persistantes à l’utilisateur. Les fragments issus du fichier à sauvegarder sont donc stockés en clair par les services de stockage. Ce chiffrement vise à protéger la confidentialité du fichier d’origine pendant les communications et en particulier lors de la manipulation du fichier par le serveur relai pour générer les fragments. De ce fait, le fichier ne doit pas être déchiffrer par le serveur relai qui doit travailler sur la version chiffrée du fichier. Pour permettre cette manipulation du fichier chiffré par le serveur relai sans compromettre le déchiffrement des fragments par les services de stockage, un chiffrement totalement homomorphe est privilégié. Toutefois, dans certains modes de réalisation, en fonction du type d’opérations mathématiques mises en œuvre par la fonction de dispersion, un chiffrement simplement homomorphe peut être utilisé. Il est également souhaité que le serveur relai ne puisse pas déchiffrer le fichier et accéder à son contenu. De plus, l’utilisateur n’a pas de connaissance à priori des services de stockage utilisés, il communique uniquement avec le serveur relai. Ces contraintes doivent tout de même permettre le chiffrement du fichier par l’utilisateur et le déchiffrement par le service de stockage des fragments qui lui sont confiés. Pour permettre de respecter ces contraintes, il est proposé d’utiliser un protocole sécurisé d’échange de clé privée entre l’utilisateur et les services de stockage. Plusieurs protocoles peuvent être utilisés, par exemple le protocole d’échange de clé dit de Diffie-Hellman, ou encore l’algorithme de Kyber décrit dans l’article « CRYSTALS-Kyber Algorithm Specifications And Supporting Documentation (version 3.02) », par Roberto Avanzi, Joppe Bos, Léo Ducas, Eike Kiltz, Tancrède Lepoint, Vadim Lyubashevsky, John M. Schanck, Peter Schwabe, Gregor Seiler, Damien Stehlé, et soumis au concours NIST. Avantageusement les services de stockage en ligne partagent une même clé asymétrique, c’est-à-dire composée d’une clé publique et d’une clé secrète. L’utilisateur peut, quant à lui, générer une nouvelle clé asymétrique pour chaque échange. Cette génération d’une nouvelle clé par l’utilisateur n’est pas obligatoire mais permet de changer la clé partagée K servant à chiffrer le fichier à chaque échange. Ainsi, lors de chaque échange, le protocole de Diffie-Hellman permet de générer une clé K dédiée à l’échange, partagée entre l’utilisateur et l’ensemble des services de stockage et inconnue du serveur relai, bien que ce dernier ait la connaissance de tous les échanges entre l’utilisateur et les services de stockage en ligne. Cette génération d’une nouvelle clé par l’utilisateur n’est pas obligatoire mais permet de changer la clé partagée K servant à chiffrer le fichier à chaque échange. La façon dont les services de stockage en ligne obtiennent la clé asymétrique qu’ils partagent est en dehors de la portée de ce document. Cette clé peut être configurée à l’initialisation du système ou partagée ensuite. La seule contrainte est qu’il faut garantir que le serveur relai ne puisse pas en acquérir la connaissance. Il est de plus souhaité que les services de stockage en ligne utilisés pour stocker les fragments ne puissent pas acquérir de connaissances sur le fichier original. Or les fragments sont stockés non chiffrés par ces services de stockage en ligne. Pour respecter ces contraintes, il est proposé que l’utilisateur encode le fichier original en utilisant une fonction AONT pour générer un pseudo-message à partir du fichier original. C’est ce pseudo-message et non le fichier original qui est alors chiffré et transmis au serveur relai pour stockage par les services de stockage en ligne. Du fait des propriétés de la fonction AONT, l’ensemble du pseudo-message est nécessaire pour le décoder et retrouver le fichier original. Ainsi, chaque service de stockage en ligne ne possédant par définition que d’un ou plusieurs fragments du pseudo-message est incapable d’accéder ne serait-ce qu’à un fragment du fichier original. De plus, l’utilisation de la fonction AONT possède un avantage supplémentaire. En effet, comme il est nécessaire d’accéder à l’intégralité du pseudo-message pour le décoder, il n’est pas nécessaire de chiffrer l’intégralité du pseudo-message pour en protéger l’accès. Le chiffrement d’une seule partie, même minime, du pseudo-message offre le même degré de protection que le chiffrement de l’intégralité du pseudo-message. Cette propriété peut être mise en œuvre pour limiter les ressources en calcul nécessaires à la méthode proposée en ne chiffrant qu’une partie minime du pseudo-message. Ceci est d’autant plus intéressant que les fonctions de chiffrement totalement homomorphes sont coûteuses en calcul. Pour résumer, le procédé de stockage proposé, comprend pour l’opération de téléversement une première étape d’application d’une fonction AONT par l’utilisateur sur le fichier original pour obtenir un pseudo-message correspondant au fichier original. Ensuite, l’utilisateur chiffre au moins une partie du pseudo message pour obtenir un pseudo-message chiffré. Ce chiffrement est du type totalement homomorphe. Il est effectué à l’aide d’une clé secrète partagée entre l’utilisateur et les services de stockage en ligne. Dans un mode de réalisation, cette clé secrète est échangée à l’aide du protocole de Diffie-Hellman entre l’utilisateur et les services de stockage. Le pseudo-message chiffré est transmis au serveur relai. Il est à noter ici que l’on qualifie le pseudo-message de pseudo-message chiffré même dans le cas d’un chiffrement partiel du pseudo-message. En effet, du fait de l’utilisation de la fonction AONT, même dans le cas d’un chiffrement partiel, les parties non chiffrées du pseudo-message ne sont pas accessibles sans déchiffrement de la partie chiffrée. Le serveur relai applique alors la fonction de dispersion pour obtenir une pluralité de fragments chiffrés. Les fragments sont qualifiés de chiffrés ici, bien qu’en toute rigueur, le chiffrement pouvant n’affecter qu’une partie du pseudo-message, certains fragments peuvent correspondre à une partie non chiffrée du pseudo-message, ceci pour la raison expliquée ci-dessus à propos du pseudo-message chiffré. Ces fragments chiffrés sont répartis sur les différents services de stockage en ligne. Ils sont alors déchiffrés et stockés en clair par le service de stockage en ligne. L’opération de téléchargement est symétrique. Elle est également basée sur un chiffrement homomorphe utilisant une clé partagée entre l’utilisateur est les services de stockage en ligne. Cette clé secrète peut, dans un exemple de réalisation, être échangée par le protocole de Diffie-Hellman suite à une éventuelle génération d’une nouvelle clé asymétrique par l’utilisateur. Les services de stockage en ligne chiffrent alors tout ou partie des fragments à leur disposition. Ces fragments sont alors transmis au serveur relai sur requête. Le serveur relai ayant reçu les fragments chiffrés applique la fonction de dispersion inverse pour retrouver le pseudo-message chiffré. La manipulation des données chiffrées étant rendue possible par l’utilisation d’un chiffrement totalement homomorphe. Ce pseudo-message chiffré est alors transmis sur requête à l’utilisateur qui peut le déchiffrer pour obtenir le pseudo-message non chiffré et décoder ce dernier pour retrouver le fichier original. 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, commence par générer le pseudo-message par application de la fonction AONT au fichier original. Ensuite, il obtient la clé secrète K partagée avec les services de stockage en ligne, ici le service de stockage 203. Dans un exemple de réalisation, l’utilisateur génère une clé asymétrique (DH_P_U, DH_S_U), typiquement à l’aide de la fonction KEYGEN et applique le protocole de Diffie-Hellman pour calculer la clé secrète K. Cette clé est alors utilisée pour chiffrer au moins partiellement le pseudo-message à l’aide d’un chiffrement totalement homomorphe et obtenir un pseudo-message chiffré. L’utilisateur transmet alors le pseudo-message chiffré 204 à stocker au serveur relai 202. Ce dernier applique la fonction de dispersion et génère les fragments chiffrés issus du pseudo-message chiffré. Il associe également le pseudo-message chiffré à 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 chiffrés, le fragment 205 qui est transmis au service de stockage en ligne 203 pour stockage. Ce fragment issu d’un pseudo-message chiffré est également chiffré. Le service de stockage en ligne 203 déchiffre le fragment chiffré 205, le mémorise et l’associe à un identifiant de fragment Id_f qui est renvoyé au serveur relai. 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. Concernant le téléchargement, dans ce mode de réalisation, l’utilisateur génère une nouvelle clé asymétrique à l’aide de la fonction KEYGEN pour calculer une nouvelle clé secrète K’ partagée avec les services de stockage en ligne à l’aide du protocole de Diffie-Hellman. Pour télécharger le fichier, l’utilisateur transmet, étape 307, l’identificateur du fichier original Id_o, sa clé publique DH_P_U et possiblement sa signature. La signature permet au service de stockage en ligne de vérifier que cette clé publique n’a pas été usurpée par le serveur relai. Le serveur relai relaye ces informations au service de stockage en ligne, étape 306. A l’aide de cette clé, le service de stockage en ligne peut également calculer la clé secrète K’. Le service de stockage peut alors chiffrer le fragment pour reconstituer un fragment chiffré. Ici encore, le chiffrement du pseudo-message pouvant être partiel, il est possible que tous les fragments ne soient pas effectivement chiffrés. Ces fragments seront tout de même qualifiés de fragments chiffrés car ils correspondent à des fragments issus d’un pseudo-message chiffré au moins partiellement. Ce fragment chiffré est alors transmis au serveur relai, lors de l’étape 205, accompagné de la clé publique du service de stockage en ligne DH_P_S. Alors le serveur relai, une fois en possession de l’ensemble des fragments chiffrés applique la fonction de dispersion inverse pour obtenir le pseudo-message chiffré HE(K’, AONT(fichier)). Ce dernier est transmis accompagné de la clé publique du service de stockage en ligne à l’utilisateur. A l’aide de la clé publique du stockage et en appliquant le protocole de Diffie-Hellman, l’utilisateur peut calculer la clé K’ et ainsi déchiffrer le pseudo-message qu’il ne reste alors qu’à décoder, c’est-à-dire à appliquer la fonction inverse AONT pour retrouver le fichier d’origine. Il peut être constaté que les cinq contraintes énoncées sont respectées par le système lors de l’étape de téléchargement. L’utilisateur n’est pas contraint de gérer des clés persistantes. L’utilisateur n’acquiert aucune information sur les services de stockage en ligne utilisés. Ces derniers ne peuvent acquérir aucune information sur le fichier original stocké. De même, le serveur relai bien qu’ayant connaissance de tous les échanges, ne peut acquérir d’information sur le fichier original stocké. Enfin, l’ensemble du procédé ne requiert qu’une occurrence d’échanges entre les différents acteurs du système depuis la requête émise par l’utilisateur à la réponse lui transmettant le pseudo-message chiffré à partir duquel il peut retrouver le fichier original. 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 est un bloc-diagramme schématique d'un dispositif de traitement de l’information 400 pour la mise en œuvre d'un ou plusieurs modes de réalisation de l'invention. Le dispositif 400 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 400 comporte un bus de communication connecté à : - une unité centrale de traitement 401, tel qu'un microprocesseur, notée CPU; - une mémoire à accès aléatoire 402, 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 403, 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 404 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 404 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 401 ; - une interface utilisateur 405 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur ; - un dispositif de stockage 406 tel que décrit dans l’invention et noté HD ; - un module d’entrée/sortie 407 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 403, sur le dispositif de stockage 406 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 404, afin d'être stocké dans l'un des moyens de stockage du dispositif de communication 400, tel que le dispositif de stockage 406, avant d'être exécuté. L'unité centrale de traitement 401 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 401 est capable d'exécuter des instructions de la mémoire RAM principale 402, relatives à une application logicielle. Un tel logiciel, lorsqu'il est exécuté par le processeur 401, 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). Procédé de stockage sécurisé d’un fichier original caractérisé en ce qu’il comprend les étapes suivantes pour téléverser un fichier original: - réception du fichier original, transmis par un dispositif utilisateur, par un serveur relai connecté à une pluralité de services de stockage en ligne ; - application d’une fonction de dispersion par le serveur relai pour générer une pluralité de fragments à partir du fichier original reçu ; - 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 ; caractérisé en ce que : - le fichier original est transformé en pseudo-message par le dispositif utilisateur à l’aide d’une fonction de transformation tout ou rien ; - le pseudo-message est chiffré, au moins en partie, par le dispositif utilisateur à l’aide d’une clés secrète partagée avec la pluralité de service de stockage en ligne, le chiffrement étant homomorphe, le fichier original reçu par le serveur relai étant le pseudo-message chiffré ; - la fonction de dispersion est appliquée sur le pseudo-message chiffré et génère des fragments chiffrés ; - les fragments chiffrés sont déchiffrés par les services de stockage en ligne avant stockage. Procédé selon la revendication 1, caractérisé en ce que : - la clé secrète est partagée entre le dispositif utilisateur et les services de stockage en ligne par un protocole d’échange de clé sécurisé. Procédé selon la revendication 2, caractérisé en ce que : - le protocole d’échange de clé sécurisé est le protocole de Diffie-Hellman. Procédé selon la revendication 3, caractérisé en ce que : - le protocole de Diffie-Hellman est basé sur une première clé asymétrique générée par le dispositif utilisateur et une seconde clé asymétrique partagée par les services de stockage en ligne. Procédé selon la revendication 4, caractérisé en ce que : - une nouvelle première clé asymétrique est générée avant chaque échange par le dispositif utilisateur. Procédé selon la revendication 1, caractérisé en ce qu’il comporte en outre les étape suivantes pour le téléchargement : - chiffrement des fragments par les services de stockage en ligne à l’aide d’une clé secrète partagée avec le dispositif utilisateur; - réception par le serveur relai des fragments chiffrés ; - application de la fonction de dispersion inverse par le serveur relai sur les fragments chiffrés pour générer un pseudo-message chiffré ; - transmission du pseudo-message chiffré au dispositif utilisateur ; - déchiffrement du pseudo-message chiffré par le dispositif utilisateur ; - application de la fonction inverse de transformation tout ou rien par le dispositif utilisateur pour retrouver le fichier original. 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 à 6 lorsque ledit programme est exécuté sur un ordinateur. 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 à 6. 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 à 6.