DOMAINE TECHNIQUE

Le domaine de l'invention est celui des systèmes informatiques distribués pour la transmission et le partage de données numériques. L'invention se rapporte plus particulièrement à la régulation de l'accès à un fichier informatique.

TECHNIQUE ANTÉRIEURE

Un protocole de gestion des droits d'accès est par exemple nécessaire lorsqu'un utilisateur d'un serveur de calcul souhaite réaliser des calculs à partir d'un fichier chiffré par son propriétaire. Selon un tel protocole, le propriétaire peut en amont chiffrer le fichier et le téléverser sur un serveur de stockage. L'utilisateur peut ensuite télécharger le fichier chiffré depuis le serveur de stockage et demander un droit d'accès au propriétaire.

Par ailleurs, l'obtention du fichier peut être soumis à une contrepartie, par exemple financière. Il convient alors d'assurer que la transaction entre l'utilisateur et le propriétaire est équitable en ce sens que ni l'utilisateur ni le propriétaire n'utilise l'échange du fichier à son avantage en récupérant les données de l'autre mais sans envoyer ce qu'il aurait dû. Pour prendre un parallèle avec le monde réel, on ne souhaite pas qu'un vendeur livre un bien sans que l'acheteur donne de l'argent en échange ou au contraire que l'acheteur donne l'argent mais que le vendeur ne donne pas le bien en échange. Le protocole "fairswap", proposé par Stefan Dziembowski, Lisa Eckey, and Sebastian Faust. 2018. FairSwap: How To Fairly Exchange Digital Goods. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS ’18). Association for Computing Machinery, New York, NY, USA, 967-984, répond à ce besoin pour l'échange de données informatiques. Ce protocole introduit un tiers de confiance faisant office de juge des conflits entre le vendeur et l'acheteur.

Le chiffrement du fichier en amont par le propriétaire avant d'être téléversé sur le serveur de stockage complique l'intégration du protocole de gestion des droits d'accès à un protocole de transaction équitable de type fairswap car dans ce dernier chaque transaction doit reposer sur une clé unique.

Par ailleurs, en cas de conflit, le tiers de confiance prend connaissance de certains blocs du fichier. Or en laissant ce fichier sur un serveur de stockage, le tiers de confiance pourrait y télécharger l'ensemble des blocs et les déchiffrer (au moins pour ceux des blocs impliqués dans le protocole fairswap), ce qui risque de compromettre la sécurité.

EXPOSÉ DE L'INVENTION

L'invention a pour objectif de proposer un protocole de gestion des droits d'accès à un fichier chiffré par son propriétaire intégré à un protocole de transaction équitable de type fairswap, qui permette de surmonter les difficultés précédemment évoquées sans pour autant s'accompagner d'un temps de calcul trop important.

Pour ce faire, l'invention propose un procédé d'accès à un fichier par un dispositif receveur, dans lequel un encodage du fichier est stocké sur un serveur de stockage, l'encodage du fichier comprenant une pluralité de blocs chiffrés constituée d'un premier ensemble de blocs correspondant à un découpage du fichier en blocs et d'un deuxième ensemble de blocs correspondant à des valeurs des nœuds d'un premier arbre de Merkle construit à partir des blocs du premier ensemble, chaque bloc de la pluralité de blocs étant chiffré par une valeur d'identification propre à un dispositif propriétaire et spécifique du fichier et du bloc, I D-P-FBi. Ce procédé comprend la mise en œuvre des étapes suivantes par le dispositif receveur :

- pour chaque bloc de la pluralité de blocs, la réception, depuis un serveur de confiance, d'une entrée d'accès propre au dispositif receveur et spécifique du fichier et du bloc, ACL-R-FBi, la détermination de I D-P-FBi à partir de ACL-R-FBi et le déchiffrement du bloc au moyen de I D-P-FBi ;

- la construction d'un deuxième arbre de Merkle à partir des blocs déchiffrés du premier ensemble de blocs de la pluralité de blocs et la vérification d'une concordance du deuxième arbre de Merkle avec les blocs déchiffrés du deuxième ensemble de blocs de la pluralité de blocs ;

- en absence de concordance : o la création d'une contestation comprenant un ensemble de blocs non déchiffrés de la pluralité de blocs, ledit ensemble étant constitué au moins d'un bloc contesté et d'un bloc d'une vérification de Merkle du bloc contesté ; et o la transmission, au serveur de confiance, de la contestation et, pour chacun des blocs de la contestation, d'une valeur d'identification propre au dispositif receveur et spécifique du fichier et du bloc, V-R-FBi.

Certains aspects préférés mais non limitatifs de ce procédé sont les suivants :

- il comprend la mise en œuvre des étapes suivantes par le serveur de confiance : o la vérification d'une validité des V-R-FBi des blocs de la contestation ; o en cas de validité non vérifiée, le rejet de la contestation ; o en cas de validité vérifiée :

■ pour chacun des blocs de la contestation, la détermination de I D-P- FBi à partir de V-R-FBi et de ACL-R-FBi et le déchiffrement du bloc au moyen de I D-P-FBi ;

■ une vérification de Merkle de chacun des blocs contestés déchiffrés.

- il comprend les étapes préalables consistant pour le dispositif receveur à réaliser : o le téléchargement de l'encodage du fichier depuis le serveur de stockage ; o pour chaque bloc de la pluralité de blocs de l'encodage du fichier, la détermination et la transmission au serveur de confiance de V-R-FBi.

- il comprend en outre par le dispositif propriétaire, pour chaque bloc de la pluralité de blocs, les étapes préalables de : o réception, depuis le serveur de confiance, de V-R-FBi ; o la génération de ACL-R-FBi, à partir de I D-P-FBi et de V-R-FBi ; o la transmission, au serveur de confiance, de ACL-R-FBi.

- il comprend en outre la réalisation par le dispositif receveur, pour chaque bloc de la pluralité de blocs, d'un chiffrement de V-R-FBi au moyen d'une clé publique du dispositif propriétaire.

- il comprend en outre la réalisation par le dispositif propriétaire, pour chaque bloc de la pluralité de blocs, d'un déchiffrement de V-R-FBi au moyen d'une clé privée du propriétaire. - il comprend en outre la réalisation par le dispositif receveur, pour chaque bloc de la pluralité de blocs, d'un calcul et d'une transmission au serveur de confiance d'une valeur de hachage de V-R-FBi.

- Il comprend en outre la réalisation par le dispositif propriétaire, pour chaque bloc de la pluralité de blocs avant de générer ACL-R-FBi, d'une réception depuis le serveur de confiance de la valeur de hachage de V-R-FBi calculée par le dispositif receveur, d'un calcul d'une valeur de hachage à partir de V-R-FBi reçu du serveur de confiance et d'une comparaison de la valeur de hachage reçue et de la valeur de hachage calculée.

- la vérification, par le serveur de confiance, d'une validité des V-R-FBi des blocs de contestation comprend, pour chacun des blocs de contestation, le calcul d'une valeur de hachage à partir de V-R-FBi transmis par le dispositif receveur au serveur de confiance avec la contestation et la comparaison de la valeur calculée avec la valeur de hachage de V-R- FBi préalablement transmise au serveur de confiance par le dispositif receveur.

- il comprend les étapes préalables consistant pour le dispositif receveur à réaliser : o le téléchargement de l'encodage du fichier depuis le serveur de stockage ; o pour chaque bloc de la pluralité de blocs de l'encodage du fichier :

■ la détermination de V-R-FBi ;

■ le calcul et la transmission au serveur de confiance d'une première valeur de Diffie-Hellman basée sur V-R-FBi.

- Il comprend en outre par le dispositif propriétaire, les étapes préalables de : o calcul et transmission au serveur de confiance d'une deuxième valeur de Diffie- Hellman ; et o pour chaque bloc de la pluralité de blocs :

■ réception, depuis le serveur de confiance, de la première valeur de Diffie-Hellman basée sur V-R-FBi;

■ détermination d'une clé partagée de Diffie-Hellman ;

■ génération de ACL-R-FBi, à partir de I D-P-FBi et de la clé partagée de Diffie-Hellman ;

■ transmission, au serveur de confiance, de ACL-R-FBi . - la vérification, par le serveur de confiance, d'une validité des V-R-FBi des blocs de contestation comprend, pour chacun des blocs de contestation, le calcul d'une troisième valeur de Diffie-Hellman basée sur V-R-FBi transmis par le dispositif receveur au serveur de confiance avec la contestation et la comparaison de la troisième valeur de Diffie-Hellman avec la première valeur de Diffie-Hellman préalablement transmise au serveur de confiance par le dispositif receveur.

- il comprend les étapes consistant pour le dispositif propriétaire à réaliser : o la génération du premier ensemble de blocs par découpage du fichier ; o la construction du premier arbre de Merkle à partir du premier ensemble de blocs ; o la génération du deuxième ensemble de blocs à partir des nœuds du premier arbre de Merkle ; o la génération de l'encodage du fichier comprenant, pour chacun des blocs du premier et du deuxième ensemble, le chiffrement du bloc par I D-P-FBi ; o la transmission de l'encodage du fichier au serveur de stockage.

BRÈVE DESCRIPTION DES DESSINS

D'autres aspects, buts, avantages et caractéristiques de l'invention apparaîtront mieux à la lecture de la description détaillée suivante de formes de réalisation préférées de celle-ci, donnée à titre d'exemple non limitatif, et faite en référence aux dessins annexés sur lesquels :

- la figure 1 est un schéma représentant un système de partage de fichiers informatiques entre dispositifs informatiques de plusieurs organisations ;

- la figure 2 est un schéma illustrant les différentes étapes du procédé selon l'invention ;

- la figure 3 illustre les différents blocs constituant l'encodage du fichier ;

- la figure 4 illustre le chiffrement des différents blocs de l'encodage du fichier par le dispositif propriétaire ;

- la figure 5 illustre le déchiffrement du fichier par le dispositif propriétaire ;

- la figure 6 illustre une vérification de preuve de Merkle par le serveur de confiance. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS

L'invention porte sur la réalisation de transactions équitables entre des entités d'un réseau intégrant une gestion de droits d'accès à des fichiers chiffrés. On considère que les entités ont préalablement partagé ensemble un protocole de gestion des droits d'accès.

La figure 1 représente schématiquement un système 1 de partage de fichiers entre des dispositifs informatiques de plusieurs organisations Orgl, Org2, Org3, connectés sur un même réseau N, de préférence un réseau de télécommunications à distance. Le réseau N est typiquement un réseau Internet, Intranet, téléphonique 3G, 4G, 5G, DECT, Bluetooth, etc.

Dans le présent exemple, les organisations Orgl, Org2, Org3 sont des organisations de gestion de données géophysiques et/ou environnementales. On entend par « données géophysiques » des données relatives aux caractéristiques physiques de la Terre, typiquement issues de mesures. Il peut s'agir de données géologiques et/ou sismiques et/ou gravimétriques et/ou atmosphériques et/ou spatiales, etc. On entend par « données environnementales » des données ayant trait à l'environnement biologique et humain d'une zone, par exemple des données biologiques et/ou sonores et/ou chimiques et/ou hydrologiques et/ou énergétiques et/ou relatives au traitement de déchets. Ces données sont typiquement des données sensibles mises sélectivement à disposition des organisations.

Les organisations Orgl, Org2, Org3 sont par exemples distantes les unes des autres, et peuvent appartenir à des territoires différents. Chacune des organisations Orgl, Org2, Org3 est par exemple une collectivité territoriale et/ou une société privée intervenant pour la collecte ou le traitement de données et/ou une association intervenant pour la collecte ou le traitement de données et/ou une organisation propriétaire de serveurs de stockage et/ou de calcul.

On considère ici que chacune des organisations Orgl, Org2, Org3 est indépendante. Les organisations souhaitent par exemple mettre en commun sélectivement une partie de leur matériel et de leurs données, afin que chacune d'entre elles puisse s'appuyer sur au moins une partie des ressources et des données des autres organisations. En outre, ici, l'organisation Orgl possède un serveur de calcul 13 et l'organisation Org2 possède un serveur de calcul 13'. Par « serveur de calcul » on entend un serveur possédant une puissance de calcul très importante, typiquement plus importante que chacun des dispositifs 11, 11', 12, 12', 12'', .... On souhaite pouvoir mettre sélectivement l'un et/ou l'autre de ces serveurs 13 et 13' à disposition des autres organisations du réseau afin d'exécuter des traitements sur des données géophysiques et/ou environnementales.

L'invention n'est cependant pas limitée au cas de données géophysiques et/ou environnementales. Elle peut avantageusement être mise en œuvre quel que soit le type de contenu des fichiers ou le type d'organisations Orgl, Org2, Org3, ... ou également pour deux organisations. Une application à des données géophysiques et/ou environnementales est avantageuse car les traitements calculatoires desdites données peuvent nécessiter une puissance de calcul élevée. Il convient que les collectivités territoriales puissent confier temporairement certains traitements à des serveurs de calcul, sans pour autant remettre en cause l'intégrité et la confidentialité des données contenues dans les fichiers.

De manière avantageuse, tous les nœuds du système 1 (c'est-à-dire ici notamment les dispositifs 11, 11', 12, 12', 12'', ...) peuvent accéder à chacun des fichiers chiffrés fl, f2, ... sans contrôle, par exemple en passant par un système de stockage distribué, par exemple conforme au protocole IPFS, gérant les mémoires M, M', M''. Les fichiers chiffrés fl, f2, ... sont alors disponibles. L'accès aux informations contenues dans le fichier est régulé par la présence des clés de chiffrement, mais l'accès au fichier lui-même n'est de préférence pas régulé.

Dans une réalisation possible, des métadonnées sont associées à chacun des fichiers, par exemple le nom du fichier, son type, sa taille, la valeur racine (i.e. le hash-sommet) d'un arbre de Merkle construit pour le fichier (voir infra). Ces métadonnées sont transmises par le système de stockage en même temps que la liste des fichiers disponibles et permettent à un nœud de sélectionner le fichier qu'il souhaite télécharger.

Des clés privées appartenant aux différents dispositifs sont, quant à elles, stockées de façon très sécurisée. Il s'agit par exemple de valeurs numériques propres à chaque dispositif. On suppose qu'aucun des dispositifs ne partage sa clé privée, ni sur le réseau N, ni avec l'un quelconque des autres dispositifs. Ici, le système 1 comprend en outre :

• pour l'organisation Orgl, un serveur propriétaire 11 et un serveur utilisateur 12. Le serveur propriétaire 11 est configuré pour créer des fichiers chiffrés et pour calculer des entrées d'accès propres à lui-même et/ou au serveur utilisateur 12 et/ou à d'autres dispositifs présents sur le réseau N pour ces fichiers ; l'organisation Orgl comprend en outre, dans le présent exemple, un capteur Sa prévu pour collecter des données géophysiques et/ou environnementales. Le capteur Sa peut ici échanger des données avec le serveur 11.

• pour l'organisation Org2, un serveur propriétaire 11' et un serveur utilisateur 12'. Le serveur propriétaire 11' est configuré pour créer des fichiers chiffrés et pour calculer des entrées d'accès propres à lui-même et/ou au serveur utilisateur 12' et/ou à d'autres dispositifs présents sur le réseau N pour ces fichiers ; l'organisation Org2 comprend en outre, dans le présent exemple, deux capteurs Sb et Sc prévu pour collecter des données géophysiques et/ou environnementales. Les deux capteurs Sb et Sc peuvent ici échanger des données avec le serveur 11'.

• pour l'organisation Org3, un serveur utilisateur 12". L'organisation Org3 ne possède pas ici de puissance de calcul importante adaptée pour effectuer des traitements lourds sur des données géophysiques et/ou environnementales.

Le système 1 comprend en outre une mémoire M de stockage. Ici, la mémoire M appartient à l'organisation Orgl. En alternative, la mémoire M pourrait être intégrée à l'un quelconque des dispositifs de l'une des organisations Orgl, Org2, Org3, ..., ou distante de chacun de ces dispositifs.

Par ailleurs, l'organisation Org2 possède ici une mémoire M' de stockage, et l'organisation Org3 possède ici une mémoire M" de stockage.

De préférence, lorsque plusieurs mémoires (ici M, M', M") sont présentes, un espace de nommage commun est utilisé. Les mémoires M, M', M" appartiennent à un système de stockage distribué, par exemple réalisé à l'aide d'un réseau de recouvrement.

De manière préférée, chaque dispositif 11, 11', 12, 12', ... sollicite la mémoire qui est disponible dans son serveur local ; ainsi, dans l'exemple illustré sur la Figure 1, le dispositif Il peut interroger la mémoire M et le dispositif 11' peut interroger la mémoire M'. Dans la mesure où les mémoires M, M', et M" appartiennent à un même système de stockage distribué, les fichiers stockés dans les autres mémoires sont également accessibles.

De manière préférée, les enregistrements sur une mémoire ne sont pas modifiables ultérieurement. Cette dernière propriété est par exemple assurée comme service par la solution de stockage distribué utilisée.

Chaque fichier chiffré est enregistré soit sur l'une quelconque des mémoires M, M', M", ..., soit sur une mémoire distante. Dans le présent exemple, le fichier fl est stocké sur la mémoire M de l'organisation Orgl et le fichier f2 est stocké sur la mémoire M' de l'organisation Org2. D'autres fichiers, de préférence chiffrés ou éventuellement non chiffrés, peuvent être enregistrés en mémoire.

Chacun des dispositifs 11, 11', 12, 12', 12'', 13, 13' comprend des moyens de traitement comme par exemple une unité de traitement, non représentée sur la Figure 1. Chacun de ces moyens de traitement peut comprendre en mémoire un ou plusieurs produits programmes d'ordinateur comprenant des instructions de code pour la mise en œuvre des procédés décrits ci-après, et/ou peut lire un ou plusieurs moyens de stockage lisibles par ordinateur sur lesquels sont enregistrées des instructions de code pour la mise en œuvre des procédés décrits ci-après.

Revenant à l'exemple précédent, les organisations Orgl, Org2, Org3 souhaitent pouvoir solliciter les serveurs de calcul 13, 13' afin de disposer de leur puissance de calcul pour effectuer des traitements sur les données géophysiques et/ou environnementales auxquelles l'un quelconque des dispositifs 11, 11', 12, 12', 12''. Pour ce faire, on souhaite attribuer un accès (typiquement uniquement en lecture) à l'un des fichiers chiffrés fl et/ou f2 pour l'un des serveurs de calcul 13 et/ou 13', de manière sélective et préférentiellement temporaire.

En référence à la figure 2, on considère ci-après un dispositif propriétaire P d'un fichier (par exemple le serveur 12" de l'organisation Org3) et un dispositif receveur R (par exemple le serveur de calcul 13 de l'organisation Org3) qui souhaite disposer d'un accès au fichier. Le fichier, chiffré par le dispositif propriétaire P, est stocké sur un serveur de stockage S. Le dispositif propriétaire P et le dispositif receveur R mettent en œuvre une transaction équitable au sens d'un protocole de type fairswap par l'intermédiaire d'un serveur de confiance T.

En référence à la figure 2, le fichier a préalablement été chiffré par le dispositif propriétaire (étape n°l désignée par ENC) et transmis sous sa forme chiffrée Z (étape n°2) au serveur de stockage S. Le chiffrement du fichier F est plus particulièrement réalisé comme suit, en référence aux figures 3 et 4. Le dispositif propriétaire P vient tout d'abord découper le fichier en une pluralité de n blocs Bl, B2, B3, B4, Bn formant un premier ensemble de blocs. Le dispositif propriétaire P vient ensuite construire un premier arbre de Merkle MT1 à partir du premier ensemble de blocs. Ce premier arbre de Merkle MT1 comprend une pluralité de nœuds Hl, H2, ..., Hm qui forme un deuxième ensemble de blocs. Les blocs Bl, B2, B3, B4, ..., Bn du premier ensemble et les blocs Hl, H2, ..., Hm sont réunis dans un vecteur Y. Le dispositif propriétaire vient ensuite générer un encodage Z du fichier en chiffrant, lors d'une opération ENC, chacun des blocs du premier et du deuxième ensemble, par une valeur d'identification propre au dispositif propriétaire et spécifique du fichier et du bloc (valeur notée ID-P-FBi pour le bloc Bi dans ce qui suit). L'encodage Z comprend ainsi un premier ensemble de blocs chiffrés ZB1, ZB2, ZB3, ZB4, ..., ZBn résultant du chiffrement des blocs Bl, B2, B3, B4, ..., Bn issus du découpage du fichier Z et un deuxième ensemble de blocs chiffrés ZH1, ZH2, ZH3, ..., ZBm résultant du chiffrement des blocs Hl, H2, H3, ..., Hm correspondant aux nœuds du premier arbre de Merkle MT1. Cet encodage Z est transmis au serveur de stockage S, le cas échéant avec la valeur racine Hm de l'arbre de Merkle MT1 du fichier F.

La valeur d'identification propre au dispositif propriétaire P et spécifique du fichier F et du bloc Bi, I D-P-FBi, dépend de la clé privée Up du dispositif propriétaire. Cette valeur d'identification est construite de telle sorte qu'un tiers ne peut pas obtenir cette valeur en connaissant simplement une identité du bloc Bi, sans connaître la clé privée Up. La valeur d'identification dépend ici également de l'identité du fichier F et de l'identité du bloc Bi. Autrement dit, les valeurs d'identification du dispositif propriétaire diffèrent pour chaque fichier, et pour chaque bloc au sein d'un même fichier.

De préférence, les différentes valeurs d'identification semblent aléatoires du point de vue d'un tiers qui ne connaîtrait pas la clé privée utilisée, mais ces valeurs sont déterministes pour l'utilisateur ayant connaissance de la clé privée utilisée. Ces valeurs peuvent correspondre aux résultats d'une fonction d'identification ID telle que I D-P-FBi = I D(Up, F, Bi). Dans un exemple de réalisation, la valeur I D-P-FBi est obtenue comme suit : I D-P-FBi = I D(U p, F, Bi) = Up+ sha256(concatenation(Up, F, Bi)), où Up est la clé privée du dispositif propriétaire, F est le nom du fichier, Bi est le i-ème bloc du vecteur Y, « concatenation » correspond à la fonction concaténation et « sha256 » correspond à une fonction de hachage cryptographique connue opérant sur une taille de mots de 32 bits. On comprend qu'il est possible d'employer une autre fonction de hachage ici.

Toujours en référence à la figure 2, le dispositif receveur R vient ensuite (étape n°3) télécharger l'encodage Z du fichier depuis le serveur de stockage S, le cas échéant avec certaines métadonnées associées au fichier comme par exemple son nom et la valeur racine Hm du premier arbre de Merkle.

Puis, pour chaque bloc de la pluralité de blocs chiffrés ZB1, ..., ZBn, ZH1, ..., ZHm de l'encodage du fichier, le dispositif receveur R vient déterminer une valeur d'identification du dispositif receveur associée au fichier et au bloc chiffré (notée V-R-FBi pour le bloc n°i).

Dans un premier mode de réalisation, la valeur V-R-FBi est calculée au moyen de la fonction d'identification ID présentée ci-dessus. Ainsi, V-R-FBi = ID(Ur, F, Bi) = Ur+ sha256(concatenation(Ur, F, Bi)) où Ur est la clé privée du dispositif receveur, F est le nom du fichier, Bi est le i-ème bloc chiffré de l'encodage Z. Cette valeur est ensuite transmise (étape n°4) au tiers de confiance T, par exemple après chiffrement au moyen d'une clé publique du dispositif propriétaire. Le dispositif receveur R peut par ailleurs calculer, pour chaque bloc chiffré de l'encodage Z, une valeur de hachage de V-R-FBi et transmettre cette valeur de hachage au serveur de confiance T.

Un deuxième mode de réalisation permet d'éviter le chiffrement à clé publique pour transmettre les valeurs V-R-FBi et de devoir poster au serveur de confiance l'ensemble des valeurs de hachages de ces valeurs V-R-FBi. Dans ce deuxième mode de réalisation, la valeur V-R-FBi est exploitée pour déterminer une première valeur de Diffie-Hellman, i.e. un nombre transmis par l'un des agents d'un protocole de Diffie-Hellman à l'autre des agents afin que ces agents puissent élaborer une clé partagée de Diffie-Hellman. Toute variante du protocole de Diffie-Hellman peut ici être utilisée, comme par exemple celle basée sur les courbes elliptiques (de l'anglais « Elliptic curve Diffie-Hellman », abrégé ECDH). Dans ce deuxième mode de réalisation, le dispositif receveur procède au tirage aléatoire de deux nombres g et p, détermine la première valeur de Diffie-Hellman selon g ^{V R FBi} [p] et transmet au tiers de confiance T cette la première valeur de Diffie-Hellman g ^{V R FBi} [p] ainsi que les nombres g et p.

Dans une première variante, la valeur V-R-FBi est calculée au moyen de la fonction d'identification ID présentée ci-dessus. Ainsi, V-R-FBi= I D(U r, F, Bi) et la première valeur de Diffie-Hellman associée au i-ème bloc chiffré s'écrit g ^ID ( ^Ur ’ ^F ' ^Bi )[p]. Dans une seconde variante, le dispositif receveur R procède, pour chacun des blocs chiffrés de l'encodage Z, au tirage aléatoire d'une valeur xi. La première valeur de Diffie-Hellman associée au i-ème bloc chiffrée s'écrit alors g ^(xi) mod p.

Lors d'une étape optionnelle, le dispositif receveur R peut par ailleurs transmettre au serveur de confiance T la valeur du nœud-racine de l'arbre de Merkle du fichier attendu (dont il a par exemple connaissance au moyen des métadonnées) et/ou la valeur du nœud- racine d'un arbre de Merkle construit sur l'ensemble des blocs chiffrés ZB1, ..., Zbn et ZH1, ..., ZHm.

Lors d'une étape n°5, le dispositif propriétaire P vient récupérer depuis le serveur de confiance T l'ensemble des informations postées par le dispositif receveur R sur le serveur de confiance T.

Lorsque l'étape optionnelle mentionnée ci-dessus est mise en œuvre, le dispositif propriétaire P vient vérifier que la ou les valeurs des nœud-racines transmis par le dispositif receveur R au serveur de confiance sont correctes. Dans la négative, l'échange est arrêté.

Dans le cadre du premier mode de réalisation, le dispositif propriétaire P vient récupérer du serveur de confiance T les valeurs V-R-FBi (éventuellement chiffrées au moyen de la clé publique du dispositif propriétaire) et le cas échéant les valeurs de hachage associées. Le dispositif propriétaire P procède si besoin au déchiffrement des V-R-FBi au moyen de sa clé privée Up. Le cas échéant, le dispositif propriétaire peut, pour chaque bloc de la pluralité de blocs, calculer une valeur de hachage de V-R-FBi (éventuellement après déchiffrage) et comparer la valeur calculée à la valeur de hachage correspondante reçue du serveur de confiance. Puis, pour chaque bloc de la pluralité de blocs, le dispositif propriétaire P vient générer une entrée d'accès propre au dispositif receveur et spécifique du fichier et du bloc, ACL-R-FBi, à partir de I D-P-FBi et de V-R-FBi. Cette entrée d'accès ACL-R-FBi est ensuite transmise au serveur de confiance T (étape n°6 sur la figure 1). Dans un exemple de réalisation, cette entrée d'accès correspond à la différence des deux valeurs d'identification ACL-R-FBi = ID-P-FBi - V-R-FBi.

Dans le cadre du deuxième mode de réalisation, le dispositif propriétaire P vient récupérer du serveur de confiance les nombres g et p, et pour chaque bloc de la pluralité de blocs, la première valeur de Diffie-Hellman correspondante g ^{V R FBi} [p]. Le dispositif propriétaire P génère une valeur aléatoire T et détermine une deuxième valeur de Diffie- Hellman g ^T [p]. Le dispositif propriétaire P vient par ailleurs déterminer la clé partagée de Diffie-Hellman selon (g ^{V R FBi} [p])T [p] = gV-R-FBi*T [p], générer une entrée d'accès propre au dispositif receveur et spécifique du fichier et du bloc, ACL-R-FBi, à partir de I D-P-FBi et de la clé partagée de Diffie-Hellman. Cette entrée d'accès ACL-R-FBi est ensuite transmise au serveur de confiance T avec la deuxième valeur de Diffie-Hellman g ^T [p]. Dans un exemple de réalisation, l'entrée d'accès correspond à la différence entre la valeur d'identification propre au dispositif propriétaire et spécifique du fichier et du bloc et la clé partagée de Diffie-Hellman : ACL-R-FBi = I D-P-FBi - g ^{V R FBi} * ^T [p].

Ensuite, au cours d'une étape n°7, le dispositif receveur R reçoit, depuis le serveur de confiance T, pour chaque bloc de la pluralité de blocs, l'entrée d'accès propre au dispositif receveur et spécifique du fichier et du bloc, ACL-R-FBi. Le dispositif receveur R calcule alors, pour chaque bloc de la pluralité de blocs, la valeur d'identification propre au dispositif propriétaire et spécifique du fichier et du bloc I D-P-FBi à partir de ACL-R-FBi.

Dans le premier mode de réalisation, ce calcul peut ainsi consister en I D-P-FBi = ACL- R-FBi + V-R-FBi. Dans le second mode de réalisation, le dispositif receveur récupère également la deuxième valeur de Diffie-Hellman g ^T [p], calcule la clé partagée de Diffie- Hellman selon (g ^T [p]) ^{V R FBi} [p])= g ^T * ^{V R FBi} [p] et la valeur ID-P-FBi selon par exemple ID-P- FBi = ACL-R-FBi + g ^T * ^{V R FBi} [p].

Une fois la valeur ID-P-FBi déterminée pour chacun des blocs, le dispositif receveur procède au moyen de cette valeur (étape n°8 désignée par DEC sur la figure 1) au déchiffrement du bloc correspondant. La figure 5 illustre cette opération, les blocs déchiffrés se répartissant en un premier ensemble de blocs déchiffrés (correspondant aux blocs du fichier) et un deuxième ensemble de blocs déchiffrés (correspondant aux blocs construits avec les nœuds du premier arbre de Merkle MT1).

Puis, le dispositif receveur construit un deuxième arbre de Merkle MT2 à partir des blocs déchiffrés Bl, ..., Bn du premier ensemble de blocs de la pluralité de blocs et vérifie la concordance du deuxième arbre de Merkle MT2 avec les blocs déchiffrés Hl, ..., Hm du deuxième ensemble de blocs de la pluralité de blocs. En particulier, la vérification de cette concordance peut consister à vérifier que le nœud-racine H'm du deuxième arbre de Merkle MT2 concorde avec le bloc déchiffré Hm du deuxième ensemble de blocs de la pluralité de blocs correspondant au nœud-racine du premier arbre de Merkle MT1.

En cas de concordance, les blocs déchiffrés correspondent bien au fichier attendu. Le fichier peut alors être reconstruit en réunissant les blocs déchiffrés Bl, ..., Bn du premier ensemble de blocs de la pluralité de blocs.

En l'absence de concordance, le dispositif receveur R procède à la création d'une contestation comprenant un ensemble de blocs non déchiffrés de la pluralité de blocs (des blocs du vecteur Z avant son déchiffrement DEC), ledit ensemble étant constitué au moins d'un bloc contesté et d'un bloc d'une vérification de Merkle du bloc contesté. A titre d'exemple et en référence à la figure 5, l'absence de concordance peut être liée au fait que le nœud H'2 du deuxième arbre de Merkle diffère du bloc déchiffré H2 représentant le nœud correspondant du premier arbre de Merkle. La contestation comprend alors le bloc contesté non déchiffré ZH2 et des blocs permettant de réaliser une vérification de Merkle du bloc contesté, en l'occurrence ZB3 et ZB4. Cette contestation peut en outre comprendre un certain nombre de nœuds d'un arbre de Merkle construit sur l'ensemble des blocs chiffrés de l'encodage Z. Ces nœuds constituent une preuve de Merkle qui permet au serveur de confiance de vérifier que les blocs de la contestation (ZH2 ; ZB3 et ZB4) n'ont pas été modifiés par le receveur.

Cette contestation est ensuite transmise (étape n°9 désignée par CONST sur la figure

1) par le dispositif receveur R au serveur de confiance T avec, pour chacun des blocs de la contestation, la valeur d'identification propre au dispositif receveur et spécifique du fichier et du bloc, V-R-FBi.

Le serveur de confiance exploite les nœuds de la preuve de Merkle et les blocs de la contestation pour recalculer la valeur du nœud racine de l'arbre de Merkle construit sur l'ensemble des blocs chiffrés de l'encodage Z. Le serveur de confiance compare alors cette valeur recalculée à la valeur qu'il connaît. Le serveur de confiance T procède ensuite (étape n°10 désignée par JUG) au traitement de la contestation. Ce traitement comprend tout d'abord la vérification d'une validité des V-R-FBi des blocs de la contestation.

Dans le cadre du premier mode de réalisation, cette vérification peut comprendre, pour chacun des blocs de contestation, le calcul d'une valeur de hachage à partir de V-R- FBi transmis par le dispositif receveur au serveur de confiance avec la contestation et la comparaison de la valeur calculée avec la valeur de hachage de V-R-FBi préalablement transmise (à l'étape n°4) au serveur de confiance par le dispositif receveur.

Dans le cadre du deuxième mode de réalisation, cette vérification peut comprendre, pour chacun des blocs de la contestation, le calcul d'une troisième valeur de Diffie-Hellman basée sur V-R-FBi transmis par le dispositif receveur R au serveur de confiance T avec la contestation et la comparaison de la troisième valeur de Diffie-Hellman avec la première valeur de Diffie-Hellman préalablement transmise (à l'étape n°4) au serveur de confiance T par le dispositif receveur R. La troisième valeur de Diffie-Hellman s'écrit par exemple g ^{v- R FBi} [p].

En cas de validité non vérifiée, c'est que le dispositif receveur a menti sur une valeur V-R-FBi transmise avec la contestation (ou avait transmis une mauvaise valeur lors de l'étape n°4). Le serveur de confiance procède alors au rejet de la contestation.

En cas de validité vérifiée, le serveur de confiance procède comme illustré par la figure 6, pour chacun des blocs de la contestation (ici ZB3, ZB4 et ZH2), à la détermination de la valeur I D-P-FBi à partir de la valeur V-R-FBi transmise par le dispositif receveur avec la contestation et de l'entrée ACL-R-FBi préalablement transmise par le dispositif propriétaire (étape n°6).

Dans le premier mode de réalisation, cette détermination peut ainsi consister en ID- P-FBi = ACL-R-FBi + V-R-FBi. Dans le second mode de réalisation, le serveur de confiance T calcule la clé partagée de Diffie-Hellman selon (g ^T [p]) ^{V R FBi} [p])= g ^T * ^{V R FBi} [p] et la valeur ID- P-FBi selon par exemple I D-P-FBi = ACL-R-FBi + g ^T * ^{V R FBi} [p].

Une fois déterminées les valeurs I D-P-FBi des blocs de la contestation, le serveur de confiance déchiffre les blocs de la contestation puis procède à une vérification de Merkle de chacun des blocs contestés déchiffrés. Comme illustré sur la figure 6, cette vérification consiste par exemple à vérifier que le bloc contesté déchiffré H2 concorde avec une valeur de hachage H''2 déterminée à partir des autres blocs déchiffrés de la contestation B3, B4.

Plus particulièrement, si un bloc contesté correspond à un nœud-feuille du premier arbre de Merkle, la vérification de Merkle de ce bloc peut comprendre le calcul d'une valeur de hachage d'un bloc de la vérification de Merkle déchiffré (en l'occurrence un bloc du premier ensemble) et la comparaison de la valeur calculée avec le bloc contesté déchiffré. Par ailleurs, si un bloc contesté correspond à un nœud du premier arbre de Merkle qui n'est pas un nœud-feuille, la vérification de Merkle de ce bloc peut comprendre le calcul d'une valeur de hachage à partir de blocs de la vérification de Merkle déchiffrés (en l'occurrence deux blocs du deuxième ensemble, enfants du bloc contesté) et la comparaison de la valeur de hachage calculée avec le bloc contesté déchiffré.

Si la vérification de Merkle de chacun des blocs contestés est positive, la contestation est acceptée. La contestation est rejetée dans le cas contraire.

On notera que conformément à l'invention, le serveur de confiance n'a connaissance des valeurs I D-P-FBi permettant le déchiffrement qu'en cas de contestation. Par ailleurs, chaque bloc étant chiffré avec une valeur ID-P-FBi différente, en cas de contestation le serveur de confiance ne peut déchiffrer que les blocs qui lui sont transmis avec la contestation. Il ne peut donc pas télécharger le fichier depuis le serveur de stockage et le déchiffrer entièrement.

Dans une mise en œuvre possible de l'invention, les transactions peuvent être chaînées en ce sens qu'une transaction peut être reliée à une autre transaction (qui elle- même peut être reliée à une autre transaction) et ne peut valablement s'opérer que si la ou les autres transactions en amont dans la chaîne ont été validées.

On prend dans ce qui suit l'exemple de deux transactions : une première transaction entre un premier propriétaire PI d'un fichier Fl et un premier receveur RI et une deuxième transaction entre un deuxième propriétaire P2 d'un fichier F2 et un deuxième receveur R2. Dans cette mise en œuvre de l'invention, les valeurs ACL de la deuxième transaction dépendent des valeur ACL de la première transaction. Plus précisément, l'entrée d'accès du deuxième dispositif receveur R2 à un bloc Bj du deuxième fichier F2 (notée ACL-R2-F2Bj) ne dépend pas uniquement de la clé de chiffrement du bloc Bj (i.e., la valeur d'identification du deuxième propriétaire P2 pour ce bloc Bj notée ID-P2-F2Bj) et du secret partagé (échangé par chiffrement à clé publique ou par Diffie-Hellman) mais également de la valeur d'une entrée d'accès de la première transaction (en l'occurrence l'entrée d'accès du premier dispositif receveur RI à un bloc Bi du premier fichier Fl, notée ACL-Rl-FIBi). Prenant l'exemple d'un secret partagé par Diffie-Hellman, on a alors ACL-R2-F2Bj = ID-P2- F2Bj - g'V-R2-F2Bj*T- [ _p . ACL-Rl-FIBi où ACL-Rl-FIBi = I D-Pl-FIBi - g ^v ’ ^R1 ’ ^F1Bi * ^T [p], On notera que les fichiers Fl et F2 peuvent avoir le même nombre de blocs ou pas. Dans le cas général en effet, une fonction peut être exploitée qui prend en entrée un numéro de bloc de la deuxième transaction et qui retourne en sortie un numéro de bloc de la première transaction. La fonction la plus évidente est : bloc n°X de la deuxième transaction -> X modulo le nombre de blocs de la première transaction.

On a vu que la valeur ACL de la deuxième transaction dépend de la valeur ACL de la première transaction. Le deuxième receveur doit donc récupérer du serveur de confiance la valeur ACL de la première transaction pour calculer la clé de déchiffrement des blocs échangés lors de la deuxième transaction. L'intérêt d'une telle approche est que si une transaction est révoquée, le serveur de confiance peut refuser de nouveaux accès à la valeur d'ACL ce qui invalide automatiquement toute la chaîne qui démarre de cette dernière. Autrement dit, l'échange entre le deuxième propriétaire P2 et le deuxième receveur R2 ne peut se faire que si l'échange entre le premier propriétaire PI et le premier receveur RI se passe correctement.

Un cas d'utilisation possible est celui d'un calcul de données où le premier receveur RI est également le deuxième propriétaire P2. Dans ce cas d'utilisation, lors d'une première transaction un utilisateur (premier propriétaire) envoie des données sources à nœud de calcul (premier receveur). Le nœud de calcul effectue un traitement des données source et, lors d'une deuxième transaction, renvoie le résultat (en tant que deuxième propriétaire) à un autre utilisateur (deuxième receveur). Dans cette situation, l'envoi du résultat ne peut être valide que si la réception des données sources a réussi.

L'invention n'est pas limitée au procédé tel que précédemment décrit et s'étend également à un dispositif informatique, comprenant une unité de traitement configurée pour mettre en œuvre les étapes du procédé précédemment décrit qui sont mises en œuvre par le dispositif propriétaire, par le dispositif receveur ou par le serveur de confiance. L'invention vise également un produit programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé précédemment décrit qui sont mises en œuvre par le dispositif propriétaire, par le dispositif receveur ou par le serveur de confiance. Et l'invention concerne également un système de partage de données numériques, comprenant un dispositif propriétaire, un dispositif receveur et un serveur de confiance tels que précédemment décrits.