DOMAINE DE L'INVENTION

La présente invention s’inscrit dans le domaine des systèmes informatiques distribués pour la transmission et le partage de données numériques.

L’invention se rapporte plus particulièrement à un procédé d’échange de données entre un dispositif informatique dit « délégant » et un dispositif informatique dit « délégué », dont les rôles respectifs dans le partage de données ressortiront de la description ci-après, ainsi qu’à un procédé d’échange de données entre un dispositif délégué et une base de gestion d’accès. L’invention concerne également un dispositif informatique comprenant une unité de traitement permettant de mettre en oeuvre l’échange de données, un système de partage d’ensembles de données chiffrés comprenant un tel dispositif, un produit programme d’ordinateur pour la mise en oeuvre de l’échange de données, et des moyens de stockage lisibles par ordinateur pour la mise en oeuvre de l’échange de données.

ETAT DE LA TECHNIQUE

Il est bien connu de l’état de la technique de contrôler l’accès à un fichier informatique contenant des données sensibles, par exemple à l’aide de techniques cryptographiques. On connaît notamment des chiffrements symétriques ou asymétriques où l’accès au fichier nécessite la connaissance d’une clé de déchiffrement.

Dans une solution très simple de régulation de l’accès à un fichier informatique pour des utilisateurs présents sur un réseau (par exemple sur Internet), le fichier informatique est chiffré et accessible publiquement. Grâce au chiffrement, bien que le fichier soit accessible sans contrôle, l’accès aux informations contenues dans le fichier est régulé. Le propriétaire du fichier informatique génère une clé de déchiffrement et doit échanger directement sur le réseau avec chaque utilisateur autorisé à accéder au fichier pour lui transmettre la clé. La publication Design of PriServ, a Privacy Service for DHTs, Jawad, Serrano-Alvarado, Valduriez (2008), Proceedings of the 2008 International Workshop on Privacy and Anonymity in the Information Society, PAIS ’08, Association for Computing Machinery, pp.21 -25 décrit par exemple une solution de gestion des droits d’accès reposant sur des échanges de clés.

Un premier inconvénient de cette approche est qu’une interception des échanges par un attaquant tiers, ou une usurpation de l’identité de l’utilisateur autorisé par un attaquant tiers, remettraient toutes deux en cause la sécurité du chiffrement du fichier. Un deuxième inconvénient important est la nécessité d’une connexion simultanée du propriétaire du fichier et de l’utilisateur devant recevoir les droits d’accès, à chaque nouveau partage.

Pour pallier ces inconvénients, certaines bases de données distribuées de l’état de l’art prennent en charge le problème de gestion des droits d’accès à l’aide de solutions de type « blockchain », c’est-à-dire avec un registre distribué où l’octroi de droits d’accès dépend d’un consensus entre les entités possédant les droits, sans autorité centrale unique de contrôle. Dans une telle solution, chaque maillon de la blockchain contient les informations nécessaires pour garantir que les fichiers échangés soient intègres.

A cet égard, on peut citer par exemple la publication Blockchain- Based, Decentralized Access Control for IPFS, Steichen et al. (2018), 2018 IEEE International Conférence on Internet of Things (iThings), pp.1499-1596. Dans cette publication, les utilisateurs de la blockchain accèdent à une liste de contrôle d’accès dite ACL partagée entre eux via la blockchain, avant d’autoriser éventuellement un nouvel utilisateur à accéder au fichier. Il est proposé de partager directement le fichier au nouvel utilisateur autorisé, dès lors que le consensus est atteint entre les utilisateurs de la blockchain. Le fichier n’est pas chiffré.

Cette solution permet une distribution asynchrone des droits d’accès, sans que les utilisateurs ne soient connectés en même temps. Toutefois, un inconvénient est que la sécurité du contrôle d’accès repose entièrement sur la confiance accordée aux utilisateurs de la blockchain, l’accès au contenu ne nécessitant pas la connaissance d’une clé.

La publication FileTribe : Blockchain- Based Secure File Sharing on IPFS, Sari, Sipos (2019), European Wireless 2019 ; 25 ^th European Wireless Conférence, pp.1 -6, propose de conserver les avantages d’un chiffrement cryptographique des fichiers tout en utilisant un consensus entre les utilisateurs d’une blockchain.

Dans cette solution, les fichiers partagés sont chiffrés à l’aide d’une clé de déchiffrement symétrique. La clé de déchiffrement symétrique est elle- même chiffrée, et peut être déchiffrée par les utilisateurs de la blockchain. Pour fournir des droits d’accès à un nouvel utilisateur, un nouveau chiffrement de la clé de déchiffrement symétrique est réalisé de façon collective. Un avantage est qu’un utilisateur tiers obtenant le fichier sans passer par la blockchain ne peut pas accéder au contenu ; toutefois, une telle solution est très lourde en temps de calcul et en espace de stockage nécessaire, puisque la clé doit être chiffrée à nouveau lors de chaque partage à un nouvel utilisateur autorisé. Compte-tenu de ces difficultés, il est peu pratique de déployer la solution susmentionnée à grande échelle.

De plus, dans la solution susmentionnée, la liste de contrôle d’accès ACL est publique et accessible « en clair » sans contrôle, si bien que n’importe quel utilisateur tiers peut connaître l’identité des utilisateurs autorisés à accéder au fichier par une simple consultation de la liste de contrôle d’accès ACL.

Un autre enjeu non résolu de manière satisfaisante est l’éventuelle révocation de droits d’accès ; les solutions qui s’appuient sur une blockchain ne permettent pas de supprimer des droits d’accès de manière simple. En général, pour empêcher que des utilisateurs précédemment autorisés puissent continuer d’accéder au contenu du fichier, il est nécessaire de générer un nouveau fichier ou une nouvelle clé de déchiffrement du fichier.

D’autres solutions de gestion de droits d’accès à des fichiers ont été proposées, telles qu’une solution de chiffrement de fichier par attributs ou encore une solution de « proxy re-encryption », mais ces solutions sont très complexes au niveau calculatoire. La puissance de calcul et la consommation d’énergie de ces solutions de gestion de droits d’accès les rendent peu pratiques pour un déploiement à grande échelle.

Il ressort de ce qui précède la gestion distribuée de droits d’accès à l’aide d’une blockchain via les solutions connues de l’état de l’art présente des avantages, mais est peu utilisable en pratique.

Un autre inconvénient de l’ensemble des solutions mentionnées ci-avant est de ne pas permettre, pour un utilisateur préalablement autorisé à accéder au fichier, que ledit utilisateur délègue temporairement ses droits d’accès à une autre entité présente sur le réseau - sans que cette dernière entité ne puisse elle-même déléguer les droits d’accès.

Une telle répartition des droits serait par exemple pertinente lorsque des utilisateurs connectés sur un réseau de télécommunications et autorisés à accéder à un fichier donné souhaitent solliciter un serveur de calcul disposant d’une puissance de calcul très importante, ce serveur de calcul étant partagé sur ledit réseau. Il conviendrait alors de permettre au serveur de calcul d’accéder de manière temporaire au fichier, en assurant que cet accès ne permette pas au serveur de calcul de fournir des droits d’accès permanents à d’autres entités.

DESCRIPTION GENERALE DE L'INVENTION

Au regard de ce qui précède, un objectif de l’invention est de fournir une solution de partage d’ensembles de données chiffrés entre plusieurs dispositifs informatiques distants dans laquelle il est aisé de fournir des droits d’accès temporaires à un nouveau dispositif informatique pour un ensemble de données protégé donné - par exemple à un serveur de calcul sollicité de manière ponctuelle. La solution recherchée doit par exemple permettre le partage ciblé de clés de chiffrement symétrique ou asymétrique associées à des ensembles de données protégés.

Un autre enjeu important est de limiter l’espace de stockage nécessaire sur les mémoires respectives des dispositifs informatiques entrant en jeu dans le procédé de partage des ensembles de données chiffrés, notamment vis-à-vis des solutions de l’état de la technique de type « blockchain » qui permettent uniquement d’ajouter des entrées de registre et dans lesquelles l’espace de stockage nécessaire croît au fil du temps. On cherche également à limiter les calculs nécessaires pour alléger et sécuriser les protocoles de partage.

On recherche également une solution de partage de données qui ne nécessite pas que tous les dispositifs informatiques disposant des droits d’accès soient connectés et disponibles en simultané pour générer les nouveaux droits d’accès temporaires.

Enfin, un objectif secondaire de l’invention est de prendre en charge la révocation éventuelle de droits d’accès ; le propriétaire des données est alors en mesure de révoquer des droits d’accès précédemment accordés pour les données, en rendant ces accès obsolètes.

Pour répondre aux besoins mentionnés ci-avant, un premier aspect de l’invention concerne un procédé d’échange de données entre un dispositif délégant et un dispositif délégué pour un accès à un ensemble de données chiffré stocké en mémoire, une entrée d’accès propre au dispositif délégant et associée audit ensemble de données étant stockée dans une liste d’accès publique d’une base de gestion d’accès, une clé de déchiffrement dudit ensemble de données étant calculable par le dispositif délégant à l’aide de l’entrée d’accès, le procédé comprenant les étapes suivantes mises en oeuvre par une unité de traitement du dispositif délégant :

- réception d’une valeur d’identification propre au dispositif délégué et associée audit ensemble de données,

- génération d’une valeur de délégation en fonction de la valeur d’identification propre au dispositif délégué, de sorte que le dispositif délégué peut ultérieurement recevoir la valeur de délégation, obtenir l’entrée d’accès propre au dispositif délégant à l’aide de la valeur de délégation et calculer la clé de déchiffrement dudit ensemble de données.

De façon optionnelle et non limitative, le procédé d’échange de données selon ce premier aspect de l’invention peut présenter en outre les caractéristiques techniques suivantes, prises seules ou dans l’une quelconque des combinaisons possibles :

- la valeur d’identification propre au dispositif délégué dépend d’une clé privée du délégué, ladite valeur d’identification étant construite de sorte qu’un tiers ne peut pas obtenir ladite valeur d’identification du délégué sans connaître la clé privée du délégué.

- la valeur d’identification propre au dispositif délégué, notée ID(U3, f1 ), est obtenue comme suit : ID(U3, f1) = U3 + sha256(concatenation (U3, f1)) où f1 est ledit ensemble de données chiffré, et où U3 est une clé privée du dispositif délégué.

- la valeur de délégation est calculée par l’unité de traitement en fonction de ladite valeur d’identification propre au dispositif délégué, et en fonction d’une valeur d’identification propre au dispositif délégant et associée audit ensemble de données.

- la valeur d’identification propre au dispositif délégant dépend d’une clé privée du délégant, ladite valeur d’identification propre au délégant étant construite de sorte qu’un tiers ne peut pas obtenir ladite valeur d’identification propre au délégant sans connaître la clé privée du délégant.

- la valeur de délégation est égale à une différence entre la valeur d’identification propre au dispositif délégant associée audit ensemble de données et la valeur d’identification propre au dispositif délégué associée audit ensemble de données. - la valeur de délégation est égale à une paire.

- un premier élément de ladite paire dépend d’une différence entre la valeur d’identification propre au dispositif délégant associée audit ensemble de données et la valeur d’identification propre au dispositif délégué associée audit ensemble de données.

- un deuxième élément de ladite paire est égal à une valeur d’identification anonyme pour le délégué propre au dispositif délégant et associée audit ensemble de données.

- le premier élément de ladite paire dépend d’un nombre aléatoire obtenu par le dispositif délégué.

- il comprend la transmission au dispositif délégué d’un message signé contenant la valeur de délégation, par exemple un message signé par signature DSA.

- la clé de déchiffrement dudit ensemble de données comprend une clé de déchiffrement symétrique, par exemple une clé de déchiffrement obtenue par un algorithme AES ou par un algorithme 3DES.

- une valeur de la clé de déchiffrement dudit ensemble de données chiffré dépend d’une fonction Aut vérifiant l’égalité suivante : Aut(ID(U2, f1 ), ACL(U2, f1 ), 0) = Aut(ID(U3, f1 ), ACL(U2, f1 ), Del) où f1 est ledit ensemble de données chiffré, où U2 est une clé privée dudit dispositif délégant, où U3 est une clé privée dudit dispositif délégué, où Del est ladite valeur de délégation, où ID(U2, f1 ) est ladite valeur d’identification propre au dispositif délégant, où ID(U3, f1 ) est ladite valeur d’identification propre au dispositif délégué, et où ACL(U2, fl ) est ladite entrée d’accès propre au dispositif délégant.

- l’entrée d’accès propre au dispositif délégant et associée audit ensemble de données a été préalablement obtenue par un serveur propriétaire en fonction de la clé de déchiffrement dudit ensemble de données, et a été stockée dans la base de gestion d’accès.

- l’obtention de l’entrée d’accès propre au dispositif délégant et associée audit ensemble de données comprend des sous-étapes, mises en oeuvre par le serveur propriétaire, de : obtention d’une valeur d’identification propre au dispositif délégant et associée audit ensemble de données, réception, depuis la base de gestion d’accès, d’une entrée d’accès propre au serveur propriétaire et associée audit ensemble de données, calcul de la clé de déchiffrement, calcul de l’entrée d’accès propre au dispositif délégant associée audit ensemble de données, en fonction de ladite entrée d’accès propre au serveur propriétaire et en fonction de ladite clé de déchiffrement.

- la liste d’accès publique est distribuée sur une infrastructure en nuage.

- la liste d’accès publique est implémentée via une blockchain.

- la liste d’accès publique est distribuée sur un réseau pair à pair intégrant le dispositif délégant et le dispositif délégué.

Selon un deuxième aspect, l’invention concerne un procédé d’échange de données entre un dispositif délégué et une base de gestion d’accès pour un accès à un ensemble de données chiffré stocké en mémoire, une entrée d’accès propre à un dispositif délégant et associée audit ensemble de données étant stockée dans la base de gestion d’accès, ladite entrée d’accès permettant au dispositif délégant d’obtenir une clé de déchiffrement dudit ensemble de données, le dispositif délégué ayant préalablement reçu une valeur de délégation depuis le dispositif délégant, à l’issue d’un procédé d’échange de données entre le délégué et un délégant tel que défini ci-avant, le procédé comprenant les étapes suivantes mises en oeuvre par une unité de traitement du dispositif délégué :

- obtention de l’entrée d’accès propre au dispositif délégant et associée audit ensemble de données,

- calcul de la clé de déchiffrement dudit ensemble de données, en fonction des trois données suivantes : une valeur d’identification propre au dispositif délégué et associée audit ensemble de données, l’entrée d’accès propre au dispositif délégant préalablement obtenue, et la valeur de délégation préalablement reçue depuis le dispositif délégant.

De façon optionnelle et non limitative, le procédé d’échange de données selon ce deuxième aspect de l’invention peut présenter en outre les caractéristiques techniques suivantes, prises seules ou dans l’une quelconque des combinaisons possibles :

- l’obtention de l’entrée d’accès propre au dispositif délégant et associée audit ensemble de données comprend : une transmission d’une donnée associée au dispositif délégant à la base de gestion d’accès, une réception, depuis la base de gestion d’accès, de ladite entrée d’accès propre au dispositif délégant.

- la donnée transmise à la base de gestion d’accès pour obtenir l’entrée d’accès comprend un identifiant du dispositif délégant.

- la donnée transmise à la base de gestion d’accès pour obtenir l’entrée d’accès comprend une valeur d’identification anonymisée, propre au délégant et associée audit ensemble de données.

- le procédé comprend des étapes ultérieures, mises en oeuvre par l’unité de traitement du dispositif délégué, de : obtention de l’ensemble de données chiffré auprès d’une mémoire, et déchiffrement de l’ensemble de données chiffré, à l’aide de la clé préalablement calculée, de préférence par déchiffrement symétrique.

L’invention se rapporte en outre, selon un troisième aspect de l’invention, à un dispositif informatique délégant comprenant une unité de traitement configurée pour mettre en oeuvre un procédé d’échange de données tel que défini ci-avant avec un dispositif délégué.

L’invention concerne également un système de partage d’ensembles de données chiffrés comprenant un tel dispositif informatique et comprenant en outre : un serveur d’accès comprenant une base de gestion d’accès dans laquelle est enregistrée une liste d’accès publique comportant au moins une entrée d’accès, et au moins un dispositif délégué comprenant une unité de traitement configurée pour mettre en oeuvre un procédé d’échange de données tel que défini ci-avant entre le dispositif délégué et une base de gestion d’accès.

Le système de partage d’ensemble de données chiffrés peut présenter, de façon optionnelle et non limitative, les caractéristiques techniques suivantes, prises seules ou dans l’une quelconque des combinaisons possibles :

- le dispositif délégant comprend un serveur utilisateur.

- le dispositif délégué comprend un serveur de calcul. - le système de partage d’ensemble de données chiffrés comprend en outre un serveur propriétaire de donnée configuré pour calculer des entrées d’accès propres à des dispositifs délégants associées à au moins un ensemble de données chiffré, et configuré pour partager lesdites entrées d’accès avec le serveur d’accès.

Un quatrième aspect de l’invention se rapporte à un produit programme d’ordinateur comprenant des instructions de code qui, lorsque lesdites instructions de code sont exécutées par une unité de traitement, conduisent ladite unité de traitement à mettre en oeuvre un procédé d’échange de données tel que défini ci-avant.

Un cinquième aspect de l’invention se rapporte à des moyens de stockage lisibles par ordinateur sur lesquels sont enregistrées des instructions de code qui, lorsque lesdites instructions de code sont exécutées par une unité de traitement, conduisent ladite unité de traitement à mettre en oeuvre un procédé d’échange de données tel que défini ci-avant.

DESCRIPTION GENERALE DES FIGURES

D’autres caractéristiques, buts et avantages de l’invention ressortiront de la description qui suit, qui est donnée à titre illustratif et non limitatif, et qui doit être lue en regard des figures annexées parmi lesquelles :

La Figure 1 est un schéma représentatif d’un ensemble de partage de données selon un exemple de réalisation, comportant notamment une pluralité de dispositifs délégants, une pluralité de dispositifs délégués et une base de gestion d’accès.

La Figure 2 représente les étapes d’un exemple de procédé de délégation de droits d’accès à un fichier chiffré, d’un dispositif délégant vers un dispositif délégué.

La Figure 3 représente les étapes d’un exemple de procédé d’accès à un fichier chiffré par un dispositif délégué ayant préalablement reçu une délégation, de préférence une délégation temporaire.

La Figure 4 représente les étapes d’un exemple de procédé de chiffrement et d’enregistrement d’un fichier par un dispositif propriétaire, permettant une éventuelle délégation ultérieure de droits d’accès au fichier chiffré enregistré.

La Figure 5 représente les étapes d’un exemple de procédé de génération de droits d’accès, de préférence permanents, d’un dispositif propriétaire vers un dispositif délégant. La Figure 6 représente les étapes d’un exemple de procédé d’accès à un fichier chiffré par un dispositif délégant pour lequel des droits d’accès, de préférence permanents, ont été préalablement générés par un dispositif propriétaire.

DESCRIPTION DETAILLEE DE MODES DE REALISATION PARTICULIERS DE L'INVENTION

Dans toute la description ci-après, les différentes valeurs cryptographiques utilisées pour la gestion des accès (clé de déchiffrement, valeur d’identification, valeur de délégation, etc.) sont propres à un unique ensemble de données. On comprendra toutefois que lesdites valeurs utilisées pour gérer les droits d’accès pourraient également être communes à plusieurs ensembles de données déterminés par le ou les propriétaires respectifs desdits ensembles de données. Notamment, la clé de déchiffrement d’un ensemble de donnée pourrait également être valide pour d’autres ensembles de données déterminés.

Sur l’ensemble des figures annexées et tout au long de la description ci-après, les éléments similaires portent des références alphanumériques identiques.

Dans ce qui suit, l’exemple est pris d’ensembles de données chiffrés stockés en mémoire sous la forme de fichiers. L’invention n’est toutefois pas limitée à ce cas de figure mais s’étend également à des ensembles de données stockés en mode bloc (chaque ensemble constitue ainsi un bloc de données, résultant par exemple mais non nécessairement du découpage d’un fichier en plusieurs blocs) ou en mode objet.

La description ci-après concerne la gestion de droits d’accès à des fichiers chiffrés par des entités d’un réseau. On considère que les entités ont préalablement partagé ensemble un protocole de gestion des droits.

La Figure 1 représente schématiquement un système 1 de partage de fichiers entre des dispositifs informatiques de plusieurs organisations Org1 , 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 Org1 , 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 Org1 , Org2, Org3 sont par exemples distantes les unes des autres, et peuvent appartenir à des territoires différents.

Chacune des organisations Org1 , 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 Org1 , 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 Org1 possède un serveur de calcul I3 et l’organisation Org2 possède un serveur de calcul I3’. 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 ’, I2, I2’, I2”, .... On souhaite pouvoir mettre sélectivement l’un et/ou l’autre de ces serveurs I3 et I3’ à disposition des autres organisations du réseau afin d’exécuter des traitements sur des données géophysiques et/ou environnementales.

Cependant, l’ensemble de la description ci-après, et notamment les descriptions des différents procédés illustrés par les Figures 2 à 6, ne sont pas limitées au cas de données géophysiques et/ou environnementales. Ces procédés peuvent avantageusement être utilisés quel que soit le type de contenu des fichiers ou le type d’organisations Org1 , 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 retour à la Figure 1 , le système 1 comprend au moins un serveur S d’accès, stockant une base DB de gestion d’accès. Le serveur d’accès S peut être contenu dans un unique dispositif informatique, ou peut être réparti sur plusieurs dispositifs (éventuellement localisés à distance les uns des autres et présents sur des sites différents), par exemple en utilisant des tables de hachage et/ou une blockchain.

Le serveur S comprend une unité de traitement (non représentée). Dans cet exemple, le serveur S stocke les différentes listes d’accès ACL. Une mémoire de la base DB de gestion d’accès (ou, en alternative, une mémoire distante avec laquelle la base DB peut communiquer) comprend au moins une liste d’accès ACL(f1 ) avec au moins une entrée d’accès pour un fichier f1 chiffré. Dans le présent exemple, la base DB de gestion d’accès comprend également une liste d’accès ACL(f2) avec au moins une entrée d’accès pour un fichier f2 chiffré. On comprendra que des entrées d’accès aux fichiers f1 et f2 peuvent être octroyées à des utilisateurs différents.

De manière avantageuse, tous les noeuds du système 1 (c’est-à-dire ici notamment les dispositifs 11 , 11 ’, I2, I2’, I2”, ...) peuvent accéder à chacun des fichiers chiffrés f1 , f2, ... sans contrôle, par exemple en passant par un système de stockage distribué gérant les mémoires M, M’, M”. Les fichiers chiffrés fl , f2, ... sont alors disponibles publiquement. 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é.

Une liste d’accès, par exemple la liste ACL(f1 ), comprend typiquement des paires de correspondance. Chaque paire associe un identifiant d’un dispositif (par exemple d(l2)) et une valeur numérique (par exemple ACL (U2, f1 )) prévue pour permettre audit dispositif d’accéder au contenu du fichier f1 .

Par exemple, l’entrée d’accès ACL (U2, f1 ) permet au dispositif I2 d’utiliser sa clé privée U2 pour calculer la valeur d’une clé de déchiffrement du fichier f1 .

Le contenu du fichier f1 comprend par exemple des données collectées issues du capteur Sa et/ou de l’un quelconque des autres capteurs.

La liste d’accès ACL est une liste publique. On entend par « publique » que la liste d’accès ACL est facilement accessible par l’un quelconque des dispositifs des organisations Org1 , Org2, Org3, ... ainsi que par des dispositifs appartenant à des utilisateurs tiers. De préférence, aucune mesure spécifique de contrôle d’accès (reposant par exemple sur des clés cryptographiques et/ou sur un consensus par blockchain, etc.) n’est implémentée pour protéger le contenu de la liste d’accès ACL vis-à-vis d’utilisateurs tiers. La liste d’accès ACL est facilement consultable, au moins en lecture, par chacun des utilisateurs susmentionnés.

Les clés privées U1 , U2, U1 ’, U2’, ..., appartenant respectivement aux dispositifs 11 , I2, 11 ’, I2’, ..., 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 ne 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 Org1 , un serveur propriétaire 11 et un serveur utilisateur I2. 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 I2 et/ou à d’autres dispositifs présents sur le réseau N pour ces fichiers ; l’organisation Org1 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 I2’. 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 I2’ 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 I2”. 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. La mémoire M peut stocker les listes d’accès ACL. Ici, la mémoire M appartient à l’organisation Org1.

En alternative, la mémoire M pourrait être intégrée au serveur d’accès S et/ou intégrée à l’un quelconque des dispositifs de l’une des organisations Org1 , 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. Ainsi, quand un utilisateur accède à une entrée de la liste d’accès ACL, il n’est pas nécessaire que l’utilisateur sache à l’avance dans quelle mémoire du système 1 ladite entrée de la liste d’accès est localisée.

De manière préférée, chaque dispositif 11 , 11 ’, I2, I2’, ... sollicite la mémoire qui est disponible dans son serveur local ; ainsi, dans l’exemple illustré sur la Figure 1 , le dispositif 11 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 du serveur S ou sur une mémoire distante. Dans le présent exemple, le fichier f1 est stocké sur la mémoire M de l’organisation Org1 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 ’, I2, I2’, I2”, I3, I3’ 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 oeuvre 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 oeuvre des procédés décrits ci-après.

Les organisations Org1 , Org2, Org3 souhaitent pouvoir solliciter les serveurs de calcul I3, I3’ 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 ’, I2, I2’, I2” a accès selon les listes d’accès ACL. Pour ce faire, on souhaite attribuer un accès (typiquement uniquement en lecture) à l’un des fichiers chiffrés f1 et/ou f2 pour l’un des serveurs de calcul I3 et/ou I3’, de manière sélective et préférentiellement temporaire.

De préférence, les données écrites par un utilisateur donné dans un fichier ne peuvent plus être modifiées, y compris de préférence par le propriétaire dudit fichier. Une telle interdiction de modifier des données de fichier après leur création est par exemple fournie, sous forme de service, par le système de stockage distribué utilisé pour les mémoires M, M’, M”.

Les procédés ci-après permettent de réaliser deux niveaux d’accès aux fichiers, comme il sera détaillé ci-après. On considère les serveurs I2, I2’ et I2” comme délégants ; ils peuvent avoir des entrées d’accès à leur nom dans les listes d’accès ACL. Les serveurs I3 et I3’ sont quant à eux délégués ; ils peuvent recevoir une délégation venant d’un délégant.

On a représenté sur la Figure 2 des étapes successives d’un procédé d’échange de données entre un dispositif délégant (par exemple I2 ou l2’ou I2”) et un dispositif délégué (par exemple I3 ou I3’) selon un exemple. Un objectif de ce procédé est de fournir une valeur de délégation Del au dispositif délégué I3, pour permettre audit délégué I3 d’accéder (préférentiellement de manière temporaire) à un fichier f1 chiffré pour lequel le dispositif délégant I2 détient des droits d’accès. Ce procédé peut être mis en oeuvre par une unité de traitement du dispositif délégant I2, conjointement avec le délégué I3.

Le fichier f1 chiffré est typiquement un fichier en lecture seule. En alternative, le contenu du fichier f1 peut être modifiable en écriture une fois que l’accès au fichier f1 a été permis.

Typiquement, le dispositif délégué I3 est un serveur de calcul partagé sur le réseau N, sollicité de manière temporaire pour prêter sa puissance de calcul.

Pour que le délégant I2 génère et transmette une délégation au délégué I3, il convient que le délégant I2 obtienne une valeur de fonction d’identification propre au délégué I3 pour le fichier fl . En effet, le calcul de la délégation Del ultérieurement attribuée au délégué 13 dépend de ladite valeur d’identification. De manière préférentielle, la fonction d’identification ID a été partagée entre les différentes organisations du réseau avant de débuter les échanges de données. Par exemple, la fonction d’identification ID a été préalablement spécifiée dans le code du programme permettant la mise en oeuvre des différents procédés d’échanges de données, et distribuée avec ledit programme.

Au cours de l’étape 1100, le délégué I3 reçoit de manière optionnelle une requête d’identification Req ID de la part du délégant I2. La requête d’identification Req ID prend de préférence la forme d’un message adressé par le délégant I2 au délégué I3. Ensuite, le délégué I3 obtient ou recalcule une valeur ID(U3, f1 ) qui lui est propre pour la fonction d’identification ID, à partir d’une identité du fichier f1 et à partir de sa clé privée U3.

La valeur d’identification ID(U3, f1 ) dépend de la clé privée U3 du délégué I3. Cette valeur d’identification est construite de telle sorte qu’un tiers ne peut pas obtenir cette valeur en connaissant simplement une identité du fichier fl , sans connaître la clé privée U3. La valeur d’identification ID(U3, f1 ) dépend ici également de l’identité du fichier f1 ; autrement dit, les valeurs d’identification du délégué I3 diffèrent pour chaque fichier.

De préférence, les résultats produits par la fonction d’identification ID semblent aléatoires du point de vue d’un tiers qui ne connaîtrait pas la clé privée utilisée, mais ces résultats sont déterministes pour l’utilisateur ayant connaissance de la clé privée utilisée.

La fonction d’identification ID présente de préférence les trois propriétés suivantes :

• Le résultat ID(U3, f1 ) ne peut être calculé que par le délégué I3 détenant sa clé U3 ;

• A partir de la seule connaissance du résultat ID(U3, f1 ), il est extrêmement difficile pour un tiers de remonter à la valeur de la clé privée U3 ;

• Le résultat ID(U3, f1 ) n’est pas rejouable par un tiers à partir d’un autre fichier chiffré, par exemple à partir du fichier f2 pour lequel le tiers connaîtrait accidentellement la valeur ID(U3, f2).

Ainsi, la fonction d’identification ID permet aux utilisateurs du système 1 d’échanger des données en vue de l’attribution et/ou de l’utilisation de droits d’accès à des fichiers, sans que des utilisateurs tiers éventuellement malveillants ne puissent deviner les clés privées des utilisateurs, ou encore accéder de façon illicite au contenu de fichiers chiffrés. La solution de gestion de droits d’accès proposée ici présente donc un très haut niveau de sécurité, bien que la liste ACL de la base de gestion d’accès DB soit publique et qu’aucun contrôle d’accès ne soit mis en oeuvre au niveau de cette liste ACL.

Dans le présent exemple (Exemple 1 ), la valeur ID(U3, f1) de la fonction d’identification ID est obtenue comme suit :

ID(U3, f1) = U3 + sha256(concatenation(U3, f1)), où f1 est ledit fichier chiffré et où U3 est la clé privée du délégué I3. « concaténation » 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 comprendra qu’il serait possible d’employer une autre fonction de hachage ici.

A l’étape 1100, le délégué I3 transmet la valeur ID (U3, f1 ) au délégant I2. De manière préférentielle, la valeur ID (U3, f1 ) est transmise sur un canal hautement sécurisé, par exemple à l’aide de fonctions cryptographiques. On assure alors que la valeur ID(U3, f1 ) demeure accessible uniquement au délégant I2 et au délégué I3, qui sont jugés de confiance.

A une étape 1200, à l’aide de la valeur d’identification ID(U3, f1 ) propre au délégué I3, le délégant I2 génère une valeur de délégation Del pour le délégué I3 et le fichier f1.

De préférence, la valeur de délégation Del est calculée par le délégant I2 en fonction de la valeur d’identification ID(U3, f1 ) propre au dispositif délégué I3, et également en fonction d’une valeur d’identification ID(U2, f1 ) propre au délégant I2 et associée à ce fichier f1. Ainsi, la valeur d’identification ID(U2, f1 ) demeurant secrète, seul un dispositif délégant disposant de droits d’accès valides au fichier fl peut produire des délégations.

Dans le présent exemple (Exemple 1 ), la valeur de délégation Del est égale à la différence des deux valeurs d’identification : Del = ID(U2, f 1 ) - ID(U3, f1).

Comme il sera décrit ci-après, par construction de la clé de déchiffrement sk, le délégué I3 sera ultérieurement en mesure de déchiffrer le fichier à partir de la valeur de délégation Del et à partir d’une information sur une entrée d’accès du délégant I2.

Enfin, à une étape 1300, le délégant I2 transmet au délégué I2 la valeur de délégation Del. Il est préférable que la transmission de la valeur de délégation Del soit réalisée de façon sécurisée, car cette valeur de délégation donne une information concernant les valeurs d’identification pour le délégant 12 et le délégué 13.

Ainsi, la transmission 1300 au dispositif délégué I3 prend préférentiellement la forme d’un message signé contenant la valeur de délégation Del. Le message peut être signé par tout algorithme de signature cryptographique, par exemple par signature DSA (pour « Digital Signature Algorithm »).

La signature de message permet de vérifier la propriété de non-répudiabilité. En outre, grâce à la signature de message, le délégué I3 peut vérifier l’intégrité de la transmission de la valeur de délégation, et le fait que la délégation provienne bien du délégant I2. Cela est notamment important dans le cas où le délégué I3 aurait besoin de l’identité du délégant I2 pour déchiffrer le fichier.

Un premier avantage du procédé de la Figure 2 est sa simplicité et sa rapidité de calcul. Un deuxième avantage est que le délégant I2 et le délégué I3 n’ont pas besoin d’être connectés au réseau simultanément à d’autres utilisateurs (par exemple un propriétaire 11 du fichier f1 ) et n’ont pas besoin de charger des fichiers dans la base DB pendant le procédé.

A l’issue du procédé de la Figure 2, le délégué I2 peut accéder (préférentiellement temporairement) au contenu du fichier f1 chiffré, grâce à sa délégation. Toutefois, le délégué I2 ne dispose pas d’une entrée à son propre nom dans la liste d’accès ACL. De préférence, le délégué I2 ne peut pas lui-même accorder une quelconque délégation à d’autres utilisateurs pour accès au fichier f1 dont il n’est pas propriétaire. On rappelle que, de préférence, seul le propriétaire du fichier f1 peut ajouter un enregistrement dudit fichier.

Ces dernières propriétés peuvent être réalisées notamment par une liste d’accès ACL stockée sous forme de blockchain, où les ajouts à la blockchain seraient gérés sous forme de « smart contract ».

On comprendra que le procédé de la Figure 2 peut être répété par le délégant I2 pour autant d’itérations que de délégués différents requérant des délégations pour le fichier f 1 , et éventuellement pour d’autres fichiers disponibles en mémoire. * Accès à un fichier chiffré à l’aide de droits d’accès temporaires (Exemple 1)

La Figure 3 illustre des étapes d’un procédé d’échange de données entre un dispositif délégué (par exemple I3 ou I3’), une base de gestion d’accès DB contenant une liste d’accès ACL publique, et une mémoire de stockage M de fichiers, selon un exemple. Le procédé peut être mis en oeuvre par une unité de traitement du dispositif délégué I3, conjointement avec la base DB. Le dispositif délégué utilise une valeur de délégation Del pour le fichier f1 préalablement été reçue depuis un délégant I2, lui permettant d’accéder au contenu du fichier f1 (préférentiellement de manière temporaire).

La valeur de délégation Del est par exemple issue d’un procédé d’échange de données tel que décrit ci-avant, et tel qu’illustré sur la Figure 2.

Pour pouvoir accéder au contenu du fichier f1 chiffré, le délégué I3 doit obtenir la valeur de la clé de déchiffrement qui verrouille le contenu. Il s’agit ici de la clé de déchiffrement symétrique sk. Pour obtenir ladite clé, le délégué I3 utilise la valeur de délégation Del.

Dans un premier temps, le délégué I3 obtient auprès de la base DB une information dépendant d’une entrée d’accès ACL (U2, f1 ) propre au délégant I2 pour le fichier f1 , en déclinant un identifiant d(l2) du délégant I2 auprès de la base DB. Par exemple, le délégué I3 obtient directement la valeur de l’entrée d’accès ACL (U2, f1 ). On rappelle que les entrées d’accès sont publiques et que leur consultation ne fait pas l’objet d’un contrôle d’accès.

Ici, à une étape 2100, le délégué I3 envoie un identifiant d(l2) du délégant I2 à la base DB de gestion d’accès.

Puis à une étape 2200, le délégué I3 lit directement la valeur de l’entrée d’accès ACL (U2, f1 ) dans la liste d’accès ACL publique de la base DB.

Le délégué I3 est ensuite en mesure de calculer la clé de déchiffrement sk pour le fichier f1 , en fonction des trois données suivantes :

• la valeur d’identification ID(U3, f 1 ) propre au dispositif délégué I3 et associée au fichier fl, que le délégué 13 peut calculer le cas échéant s’il ne la possède pas en mémoire ;

• l’entrée d’accès ACL(U2, f 1 ) lue dans la base DB de gestion d’accès ;

• la valeur de délégation Del préalablement générée par le délégant I3 et reçue par le délégué I3 (directement depuis le délégant ou indirectement par l’intermédiaire d’un dispositif tiers comme un tiers de confiance) , qui peut avoir été enregistrée en mémoire au préalable.

On rappelle que le délégué 13 ne possède pas d’entrée d’accès à son propre nom dans la liste ACL publique, pour le fichier f1 .

La clé de déchiffrement sk est de préférence une clé de déchiffrement symétrique. Le chiffrement mis en oeuvre correspond par exemple à un algorithme AES (pour « Advanced Encryption Standard ») ou encore 3DES (pour « Triple Data Encryption Standard ») mais tout algorithme peut être utilisé. La clé de déchiffrement sk est ici construite comme suit : sk = Aut(ID(U3, f1 ), ACL(U2, f1 ), Del) [= Aut(ID(U2, f1), ACL(U2, f1), O)] où f1 est le fichier chiffré, où U2 est la clé privée du dispositif délégant I2, où U3 est la clé privée du dispositif délégué I3, où Del est la valeur de délégation préalablement reçue par le délégué I3, où ID(U2, f1 ) est la valeur d’identification propre au dispositif délégant I2, où ID(U3, f1 ) est la valeur d’identification propre au dispositif délégué I3, et où ACL(U2, fl ) est l’entrée d’accès propre au dispositif délégant I2.

La fonction d’autorisation Aut est choisie de sorte à vérifier l’égalité suivante :

Aut(ID(U3, f1 ), ACL(U2, fl ), Del) = Aut(ID(U2, fl ), ACL(U2, fl ), 0)

Dans un exemple simple, on utilise comme résultat de la fonction Aut une somme des trois variables prises en entrée. En effet, si l’égalité Del = ID(U2, f1 ) - ID(U3, f1 ) est vérifiée comme dans l’exemple ci-avant (Exemple 1 ), alors l’égalité suivante est également vérifiée :

I D(U 3 , fl ) + ACL (U2, fl ) + Del = ID (U2, fl ) + ACL (U2, fl )

Il ressort clairement que le délégué I3 doit nécessairement connaître la valeur de délégation Del pour déchiffrer le fichier, faute de quoi la connaissance de la valeur de l’entrée d’accès ACL(U2, fl ) ne lui est pas utile. On propose donc deux niveaux différents d’accès au fichier fl chiffré ; un premier niveau d’utilisateurs n’ont pas besoin de délégation (délégant I2) et un deuxième niveau plus faible d’utilisateurs ont besoin d’une délégation, car ils n’ont pas d’entrée d’accès en leur nom propre (délégué I3). De préférence, la fonction d’autorisation Aut a été partagée entre les différentes organisations du réseau avant de débuter les échanges de données. Elle a par exemple été distribuée aux différents serveurs avec le code du programme permettant la mise en oeuvre des procédés d’échanges de données.

A l’issue de l’étape 2300, le délégué 13 dispose de la clé de déchiffrement sk.

A une étape 2400, pouvant être mise en oeuvre immédiatement après l’étape 2300 ou plus tardivement, le délégué 13 obtient le fichier f1 auprès d’une mémoire dans laquelle ce fichier est stocké. Le fichier f1 est par exemple obtenu depuis la mémoire M. A cet effet, le délégué I3 transmet par exemple une requête de fichier Req f1 à la mémoire M.

Enfin, à une étape 2500, le délégué I3 décline la valeur de la clé de déchiffrement sk pour accéder au contenu du fichier, de préférence par déchiffrement symétrique. Le fichier f1 n’est bien entendu pas communiqué sous forme déchiffrée via le réseau N.

Dans le cas où le délégué I3 est un serveur de calcul, on comprendra que le délégué I3 peut mettre en oeuvre la ou les séquences de calcul nécessaires, puis le résultat des calculs peut être sauvegardé sur la mémoire M en réseau, éventuellement directement dans le contenu du fichier f1 . Alternativement, les données de résultat des calculs sont communiquées à différentes organisations présentes sur le réseau (typiquement au délégant I2 et/ou au propriétaire 11 ). Enregistrement d’un nouveau fichier chiffré (Exemple 1)

La Figure 4 illustre des étapes successives d’un procédé de création d’un nouveau fichier f1 protégé destiné à être partagé via un système de partage tel que le système 1 , et de génération de droits d’accès pour ce fichier f1 . Le procédé est mis en oeuvre par un dispositif propriétaire du fichier f1 (par exemple un propriétaire 11 ou 11 ’), une base de gestion d’accès DB et une mémoire de stockage M.

A une étape 3100, le propriétaire 11 génère un nouveau fichier f ⁰ non chiffré ou obtient ce fichier depuis sa mémoire interne. Comme indiqué ci-avant, les données du fichier f _l ⁰ sont par exemple des données scientifiques sensibles que le propriétaire 11 souhaite partager avec d’autres utilisateurs de manière sécurisée, tout en préservant la confidentialité des données du fichier f ⁰ . A une étape 3200, en vue de générer une entrée d’accès pour le futur fichier f1 chiffré, le propriétaire 11 tire un nombre aléatoire r, par exemple un entier.

Le propriétaire transmet ensuite le nombre aléatoire r à la base DB de gestion d’accès, à une étape 3300.

Ensuite, à une étape 3350, la base DB de gestion d’accès enregistre une entrée d’accès pour le propriétaire 11 et pour le futur fichier f1 chiffré, dans la liste ACL publique. Par exemple, l’entrée d’accès ACL (U1 , f1 ) est prise égale à r. U1 est une clé privée du propriétaire 11 .

Le propriétaire 11 , quant à lui, calcule à une étape 3400 sa valeur d’identification ID (U1 , f1 ) pour le fichier fl . Dans le présent exemple (Exemple 1 ), cette valeur d’identification est calculée comme suit :

ID(U1, f 1 ) = U 1 + sha256(concatenation(U1, f1 )),

A partir de sa propre valeur d’identification ID (U1 , f1 ), combinée à la valeur de la nouvelle entrée d’accès ACL (U1 , f1 ), le propriétaire 11 est en mesure d’obtenir une valeur de clé de déchiffrement sk pour le fichier fl . La valeur de la clé de déchiffrement sk est construite de sorte que des délégants 12, 12’, 12”... puissent ultérieurement mettre en oeuvre des délégations comme vu ci-avant, sans solliciter le propriétaire 11 .

Ainsi, à une étape 3500, le propriétaire 11 calcule une valeur de la clé de déchiffrement sk à l’aide de la fonction d’autorisation Aut, par exemple selon la formule suivante : sk = Aut(ID(U1, fl ), ACL(U1, fl ), 0))

On rappelle que, dans un exemple simple, un résultat de la fonction d’autorisation Aut est une somme des trois variables prises en entrée par la fonction d’autorisation.

A une étape 3600, le contenu du fichier est chiffré à l’aide de la clé sk, afin d’obtenir le fichier f1 chiffré.

Enfin, à une étape 3700, ce fichier f1 est enregistré sur la mémoire M de stockage.

On comprendra que l’étape 3350 peut être intervertie avec les étapes 3400, 3500, 3600 et 3700 ou encore mise en oeuvre en parallèle de ces dernières étapes.

En alternative, le fichier fl chiffré pourrait être obtenu par chiffrement asymétrique à partir du fichier f° non chiffré. Le chiffrement repose alors sur une clé privée de déchiffrement associée à une clé publique de déchiffrement. Dans ce dernier cas, la fonction d’autorisation Aut partagée entre le propriétaire 11 et les différents autres utilisateurs permet auxdits utilisateurs de reconstruire la clé privée de déchiffrement du fichier f1.

*Génération de droits d’accès permanents à un fichier chiffré pour un délégant (Exemple 1)

La Figure 5 illustre des étapes d’un procédé d’échange de données entre un dispositif propriétaire (par exemple 11 ou 11 ’), un dispositif délégant (par exemple I2 ou l2’ou I2”) et une base de gestion d’accès DB, selon un exemple. Un objectif de ce procédé est de fournir au dispositif délégant I2 des droits d’accès (préférentiellement permanents) à un fichier f1 protégé. Le procédé peut être mis en oeuvre par une unité de traitement du propriétaire 11 , en association avec le délégant I2 et la base DB.

Le fichier f1 est par exemple issu d’un procédé d’enregistrement de fichier tel que décrit ci-avant, illustré sur la Figure 4. De même, l’entrée d’accès ACL (U1 , f1 ) du propriétaire 11 est, de préférence, obtenue comme décrit ci-avant en relation à la Figure 4.

Au cours du procédé de la Figure 5, le propriétaire 11 génère une nouvelle entrée d’accès ACL (U2, f1 ) publique associée au délégant I2.

Ainsi, une fois l’entrée d’accès ACL (U2, f1 ) générée et enregistrée dans la base DB, le délégant I2 pourra ultérieurement accéder au contenu du fichier fl sans avoir besoin d’une quelconque délégation, et sans avoir besoin que le propriétaire 11 soit connecté.

A une étape 4100, le délégant I2 transmet au propriétaire 11 sa valeur d’identification ID (U2, f1 ) pour le fichier fl. On rappelle que la fonction d’identification ID a, de préférence, été partagée entre toutes les organisations du réseau avant de commencer les échanges.

Dans le présent Exemple 1 , la fonction d’identification ID présente les mêmes propriétés déjà mentionnées ci-avant en relation à la Figure 2 et la transmission est réalisée de la même manière. En particulier :

- La valeur d’identification ID(U2, f 1 ) dépend de préférence de la clé privée U2 du délégant et est de préférence construite de sorte qu’un tiers ne peut pas obtenir ladite valeur d’identification sans connaître la clé privée U2. Ainsi, des utilisateurs tiers éventuellement malveillants ne peuvent pas deviner les clés privées des utilisateurs, ou encore accéder de façon illicite au contenu du fichier fl , en interceptant les échanges ;

- La valeur ID (U2, f1 ) est transmise à l’étape 4100 sur un canal hautement sécurisé, par exemple à l’aide de fonctions cryptographiques, pour assurer que seuls le propriétaire 11 et le délégant I2 connaissent ladite valeur.

A une étape 4200, le propriétaire 11 obtient la valeur de sa propre entrée d’accès ACL (U1 , f1 ) pour le fichier fl , auprès de la base DB. Par exemple, le propriétaire 11 transmet une requête d’accès Req ACL et récupère en retour l’entrée d’accès ACL (U1 , f1 ). Cette valeur ACL (U1 , f 1 ) peut sinon avoir été préalablement enregistrée par le propriétaire 11 .

Ensuite, à une étape 4300, le propriétaire 11 obtient ou recalcule sa propre valeur d’identification ID (U1 , f1 ), puis recalcule la clé de déchiffrement sk pour le fichier fl . Dans le cas où la fonction d’autorisation Aut est une simple somme, la clé de déchiffrement sk peut être obtenue de manière simple : sk = ID (U1, f1 ) + ACL (U1, f1 )

A une étape 4400, le propriétaire 11 calcule la valeur appropriée de la nouvelle entrée d’accès ACL (U2, f1 ) à générer pour le délégant I2, ici selon la formule suivante :

ACL (U2, f1 ) = sk - ID (U2, f1 )

A une étape 4500, cette entrée d’accès ACL (U2, f1 ) est intégrée au sein de la liste d’accès ACL publique de la base DB de gestion d’accès. La liste d’accès ACL est publique ; il n’est pas nécessaire de chiffrer l’entrée d’accès ACL (U2, f1 ), puisque cette entrée prise isolément ne suffirait pas à un attaquant tiers pour calculer la clé de déchiffrement sk.

Une fois l’entrée d’accès ACL (U2, f1 ) intégrée à la liste d’accès ACL publique, le délégant I2 dispose de droits d’accès de niveau élevé pour le fichier fl . Celui-ci n’a pas besoin de communiquer avec le propriétaire 11 pour déchiffrer ultérieurement le fichier f1 .

Enfin, à une étape 4600 optionnelle, le propriétaire 11 peut confirmer au délégant I2 que des droits d’accès valides ont été intégrés à la liste ACL publique pour le délégant I2. A titre d’exemple, un message « OK » peut être transmis au délégant I2. En alternative, le délégant I2 peut effectuer lui-même une vérification de la liste ACL. On notera que le dispositif délégant 12 pourrait obtenir des droits d’accès au fichier f1 auprès d’un autre délégant I2’, I2”... connaissant la valeur de la clé de déchiffrement sk, plutôt qu’auprès du propriétaire 11. En effet, ces délégants I2’, I2”... connaissent la valeur de la clé de déchiffrement sk, et seraient donc en mesure de générer une entrée d’accès ACL (U2, f1 ) valide après avoir reçu la valeur ID (U2, d1 ) depuis le délégant I2.

Si des révocations de droits doivent être mises en oeuvre, un moyen simple pour le propriétaire 11 de révoquer les droits d’accès accordés aux différents utilisateurs délégants ou délégués consisterait à générer une nouvelle clé de déchiffrement, et à rendre obsolète la précédente clé de déchiffrement. Les droits (entrées d’accès, délégations) obtenus à partir de la précédente clé de déchiffrement sont alors rendus également obsolètes. En effet, dès lors que la clé de déchiffrement est modifiée, les informations de la liste d’accès ACL avant modification de la clé deviennent inutiles pour les dispositifs du système.

* Accès à un fichier chiffré à l’aide de droits d’accès permanents (Exemple 1)

La Figure 6 illustre des étapes d’un procédé d’échange de données entre un dispositif délégant (par exemple I2 ou l2’ou I2”), une base de gestion d’accès DB et une mémoire de stockage M de fichiers, selon un exemple. Le procédé peut être mis en oeuvre par une unité de traitement du dispositif délégant I2. Le délégant I2 utilise des droits d’accès (préférentiellement permanents) qui lui ont été précédemment octroyés pour le fichier f1 chiffré, par exemple à l’issue du procédé décrit ci-avant et illustré sur la Figure 5.

L’accès au contenu du fichier par le délégant I2 repose sur les mêmes principes généraux que le procédé d’accès au fichier par le délégué I3 décrit ci-avant, en relation à la Figure 3. Pour pouvoir accéder au contenu du fichier f1 chiffré, le délégué I3 doit obtenir la valeur de la clé de déchiffrement sk qui verrouille le contenu du fichier f1.

Toutefois, une distinction majeure est que le délégant I2 n’a pas besoin de recevoir une délégation de la part d’une quelconque organisation du réseau, avant d’accéder au contenu du fichier f1 chiffré. En effet, un accès lui a déjà été octroyé par le propriétaire 11. D’abord, à une étape 5100, le délégant I2 récupère son entrée d’accès ACL (U2, f1 ) dans la liste d’accès ACL publique. Le délégant I2 décline par exemple son identité à l’aide de l’identifiant d(l2), et envoie une requête d’accès Req ACL. Le délégant I2 récupère en retour l’entrée d’accès ACL (U2, f1 ).

Puis à une étape 5200, le délégant I2 obtient sa propre valeur d’identification ID(U2, f1 ) associée au fichier f1 Le délégant I2 peut calculer cette valeur d’identification le cas échéant, s’il ne la possède pas en mémoire.

A une étape 5300, le délégant I2 calcule ensuite la clé de déchiffrement sk pour le fichier f1 , en fonction des deux données suivantes :

• la valeur d’identification ID(U2, f1 ) obtenue à l’issue de l’étape 5200 ;

• l’entrée d’accès ACL(U2, f1 ) lue à l’étape 5100 dans la base DB de gestion d’accès.

On rappelle que la clé de déchiffrement sk est ici construite comme suit : sk = Aut(ID(U2, f1 ), ACL(U2, f1 ), 0)

Dans l’exemple simple d’une fonction autorisation Aut égale à la fonction somme, le délégant I2 obtient de manière très simple la clé de déchiffrement sk comme une somme des deux données susnommées. La clé de déchiffrement sk peut optionnellement être conservée en mémoire (de manière hautement sécurisée) à une étape 5400 pour un déchiffrement ultérieur du fichier.

La confidentialité de la clé de déchiffrement sk est préservée, puisque seul le délégant I2 connaît sa clé privée U2 lui permettant de calculer sa propre valeur d’identification ID(U2, f1 ) associée au fichier f1 .

A une étape 5500, le délégant I2 obtient le fichier f1 chiffré auprès d’une mémoire dans laquelle ce fichier est stocké, ici auprès de la mémoire M de stockage. A cet effet, le délégué I3 peut transmettre une requête de fichier Req f1 .

Enfin, à une étape 5600, le délégant I2 décline la valeur de la clé de déchiffrement sk pour accéder au contenu du fichier, de préférence par déchiffrement symétrique.

Dans le cas où un ou plusieurs serveurs de calcul (délégués I3, I3’...) ont travaillé sur le contenu du fichier f1 , le délégant I2 peut alors accéder au contenu modifié.

L’ensemble des étapes décrites ci-avant, pour un accès au fichier f1 par un délégant I2, se transposent à l’identique pour un accès par le propriétaire 11 du fichier. Le propriétaire 11 dispose ici des mêmes niveaux de droits d’accès que le délégant I2, et détient notamment sa propre entrée d’accès ACL (U1 , f1 ) pour le fichier f1.

*Exemple 2 - Gestion de droits d’accès avec un anonymat renforcé des entrées d’accès

Selon un protocole alternatif (Exemple 2) de gestion de droits d’accès à des fichiers chiffrés, une première fonction d’identification ID1 est utilisée pour la génération des valeurs d’identification et des valeurs de délégation, et une deuxième fonction d’identification ID2 distincte est utilisée pour la génération des entrées d’accès intégrées aux listes d’accès ACL. On décrit ci-après des procédés de traitement correspondant à un tel protocole.

Ce protocole alternatif reprend les principes décrits ci-avant en relation à un procédé de délégation de droits d’accès à un fichier f1 chiffré par un délégant I2 (Figure 2), en relation à un procédé d’accès à un fichier f1 chiffré par un délégué I3 à l’aide de la valeur de délégation (Figure 3), en relation à un procédé de chiffrement et d’enregistrement d’un nouveau fichier f1 par un propriétaire 11 (Figure A), en relation à un procédé de génération de droits d’accès par un propriétaire 11 (Figure 5) et en relation à un procédé d’accès à un fichier f1 chiffré par un délégant I2 à l’aide des droits d’accès (Figure 6). On conserve ci-après les mêmes références numériques pour désigner les étapes de ces divers procédés.

Les différents procédés selon ce protocole alternatif peuvent être mis en oeuvre par le système 1 de partage de fichiers tel que décrit ci-avant, en relation à la Figure 1.

Une distinction majeure du protocole de l’Exemple 2, vis-à-vis du protocole de l’Exemple 1 , est l’utilisation de deux fonctions d’identification ID1 et ID2 distinctes. Les principales différences sont détaillées ci-après.

Au cours d’une délégation de droits d’accès (similaire à la Figure 2), à l’étape 1100, la valeur retournée par le délégué I3 au délégant I2 dépend de la valeur ID1 (U3, f1 ) obtenue avec la première fonction d’identification ID1 pour le fichier f1 et le délégué I3.

Par exemple, la première fonction d’identification ID1 se calcule comme suit :

ID1 (U3, f1 ) = sha256(concatenation (U3, f1,’ID1’)) De façon optionnelle et avantageuse, la valeur retournée par le délégué 13 au délégant 12 est randomisée à l’aide d’un nombre aléatoire k obtenu par le délégué 13. On note que la valeur du nombre aléatoire k n’est pas connue du délégant 12.

Par exemple, la valeur retournée par le délégué 13 au délégant 12 est égale à :

ID1 (U3, f1 ) + k

Le dispositif délégant I2 n’a alors pas accès à la valeur ID1 (U3, f1 ) isolée, puisque seul le dispositif délégué I3 connaît la valeur du nombre aléatoire k.

A l’étape 1200, le calcul de la valeur de délégation Del’ par le délégant I2 est modifié. La valeur de délégation Del’ est ici égale à une paire. Le premier élément de la paire Del’ est égal à la différence entre la valeur d’identification pour le délégant I2 et la valeur précédemment retournée par le délégué I3 : ID1 (U2, f1 ) - [ID1 (U3, f1 ) + k].

Le deuxième élément de la paire Del’ est égal à une valeur obtenue avec la deuxième fonction d’identification ID2 pour le fichier f1 et le délégant I2 : ID2 (U2, f1). Ainsi, dans cet Exemple 2, le délégant I2 transmet une valeur qui permet ultérieurement au délégué I3 de savoir quelle entrée d’accès doit être requise dans la liste ACL(f1 ) auprès de la base DB.

Par exemple, la deuxième fonction d’identification ID2 se calcule comme suit :

ID2 (U2, f1 ) = sha256(concatenation(U2, f1,’ID2’))

Les valeurs ‘ID1 ’ et ‘ I D2’ sont des chaînes de caractères distinctes. De cette manière, les valeurs fournies par les deux fonctions d’identification ID1 et ID2 sont décorrélées et distinctes.

De préférence, la transmission 1300 au dispositif délégué I3 de la délégation Del’ prend la forme d’un envoi de message signé sur un canal hautement sécurisé, de même que dans l’Exemple 1 .

Au cours d’un accès à un fichier f1 chiffré par un délégué I3 à l’aide de la délégation (similaire à la Figure 3), à l’étape 2100, le délégué I3 envoie une requête d’accès Req ACL à la base DB de gestion d’accès. Le délégué I3 associe à sa requête d’accès Req ACL le deuxième élément ID2(U2, f1 ) de la paire Del’ précédemment reçue.

A l’étape 2200, le délégué I3 obtient en retour une valeur numérique ACL(ID2(U2, f1 )) de l’entrée d’accès propre au délégant I2 pour le fichier f1 . Dans cet Exemple 2, l’entrée d’accès prend la forme ACL(ID2(U2, f1 )). Pour obtenir une entrée d’accès auprès de la base DB, il faut soumettre une valeur numérique obtenue à l’aide de la deuxième fonction d’identification ID2. La liste d’accès ACL demeure publique.

Pour le calcul de la clé de déchiffrement sk à l’étape 2400, le délégué 13 obtient ou recalcule la valeur d’identification ID1 (U3, f1 ) qui lui est propre pour le fichier d1. A partir de cette valeur et du nombre aléatoire k, le délégué I3 obtient la valeur ID1 (U2, f1 ).

On rappelle que le nombre aléatoire k est connu du délégué I3. Ce nombre a par exemple été conservé de manière sécurisée dans une mémoire du dispositif délégué I3. La clé de déchiffrement sk est obtenue comme suit par le délégué I3 à l’étape 2400, sur la base des valeurs précédemment reçues : sk = Aut(ID1 (U2, fl ), ACL(ID2(U2, fl )), 0)

Dans un cas simple, la fonction d’autorisation Aut utilisée pour calculer la clé retourne une somme des variables prises en entrée : sk = ID1 (U2, f1 ) + ACL(ID2(U2, f1 )).

Le déchiffrement et l’accès au fichier fl se déroulent comme dans l’Exemple 1 .

Au cours de la création et du chiffrement d’un nouveau fichier (similaire à la Figure A), le propriétaire 11 utilise la première fonction d’identification ID1 pour le calcul de la nouvelle clé de déchiffrement sk associée au fichier fl , et utilise la deuxième fonction d’identification ID2 pour le calcul de la nouvelle entrée d’accès qui lui est propre.

Ainsi, à l’étape 3200, le propriétaire 11 calcule non seulement un entier aléatoire correspondant à la valeur de sa future entrée d’accès, mais calcule également la valeur ID2 (U1 , f1 ). La valeur insérée dans la base DB à l’étape 3350 est égale à ACL(ID2(U1 , f1 )). Enfin, à l’étape 3500, la clé de déchiffrement sk est calculée de la même manière que ci-avant : sk = Aut (I D 1 (U 1 , fl ), ACL(ID2(U1, fl )), 0)

Il n’est pas souhaitable que le propriétaire 11 ajoute un entier aléatoire secret pour obtenir la valeur de la clé. Au cours de la génération de nouveaux droits d’accès par un propriétaire 11 pour un délégant I2 (similaire à la Figure 5), il est préférable que la valeur d’identification communiquée par le délégant I2 soit randomisée à l’aide d’un nombre aléatoire k’. La valeur du nombre aléatoire k’ n’est pas connue du propriétaire 11.

Ainsi, à l’étape 4100, le délégant I2 communique au propriétaire 11 la valeur suivante : [ID1 (U2, f1 ) + k’].

Ici, le propriétaire 11 n’a donc pas accès en clair à la valeur ID1 (U2, f1 ), contrairement à l’Exemple 1 où le propriétaire 11 reçoit la valeur ID(U2, f1 ) à l’étape 4100.

A l’étape 4400, une différence avec l’Exemple 1 est que le propriétaire 11 ne calcule pas de manière autonome la nouvelle entrée d’accès ACL(ID2(U2, f1 )) qui doit être ajoutée à la liste d’accès ACL pour le délégant I2 et le fichier f1. Le calcul de ladite entrée d’accès est réalisé de manière distribuée entre le propriétaire 11 et le délégant I2.

Dans cet Exemple 2, à une première sous-étape de l’étape 4400, le propriétaire 11 transmet au délégant I2 la valeur suivante : sk - [ID1 (U2, f 1 ) + k’]

Sur cette base, à une deuxième sous-étape de l’étape 4400, le délégant I2 (qui est le seul à connaître le nombre aléatoire k’) peut recalculer la valeur [sk - ID1 (U2, fl )].

C’est donc le délégant 12 qui, à l’étape 4500, communique à la base DB la valeur de l’entrée d’accès ACL(ID2(U2, f1 )) qui lui sera associée dans la liste ACL pour le fichier f1 :

ACL(ID2(U2, f 1 )) = sk - ID1 (U2, f 1 )

Enfin, les étapes d’un accès au fichier f1 chiffré par le délégant I2 à l’aide de droits d’accès issus de la base DB (similaire à la Figure 6) sont similaires à l’Exemple 1. Le délégant I2 doit soumettre sa valeur d’identification I D1 (U2,f 1 ) à la base DB de sorte à obtenir l’entrée d’accès ACL(ID2(U2, f1 )). Par construction de la valeur de l’entrée d’accès à l’étape 4500 précédente, le délégant I2 est en mesure de calculer la clé de déchiffrement sk sans être connecté au réseau simultanément au propriétaire 11.

Vis-à-vis de l’Exemple 1 , un premier avantage du protocole selon l’Exemple 2 est que les entrées d’accès sont anonymisées. A partir de la valeur numérique d’une entrée d’accès publique, par exemple ACL(ID2(U2,f1 )), présente dans la liste d’accès ACL(f1 ), un tiers ne peut pas remonter à l’identité du dispositif I2. La valeur de l’entrée d’accès est obtenue auprès de la base DB non pas en fournissant un identifiant du dispositif I2, mais en fournissant la valeur numérique ID2(U2,f1 ) obtenue avec la deuxième fonction d’identification ID2.

Un deuxième avantage du protocole selon l’Exemple 2 est de masquer les valeurs de la première fonction d’identification ID1 associées aux différents dispositifs, avec une randomisation des valeurs de la première fonction d’identification ID1 lors des échanges. Ainsi, un attaquant tiers qui intercepterait les communications de données ne pourrait pas avoir accès en clair aux valeurs de la première fonction d’identification ID1 pour le délégant I2 ou pour le délégué I3. La sécurité des échanges de données est ainsi renforcée.