FR3121243A1 - Gestion de droits d’accès à des fichiers numériques avec possible délégation des droits - Google Patents

Gestion de droits d’accès à des fichiers numériques avec possible délégation des droits Download PDF

Info

Publication number
FR3121243A1
FR3121243A1 FR2103009A FR2103009A FR3121243A1 FR 3121243 A1 FR3121243 A1 FR 3121243A1 FR 2103009 A FR2103009 A FR 2103009A FR 2103009 A FR2103009 A FR 2103009A FR 3121243 A1 FR3121243 A1 FR 3121243A1
Authority
FR
France
Prior art keywords
file
access
specific
acl
delegating
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR2103009A
Other languages
English (en)
Other versions
FR3121243B1 (fr
Inventor
Bastien CONFAIS
Gustavo ROSTIROLLA
François Marques
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inatysco
Original Assignee
Inatysco
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inatysco filed Critical Inatysco
Priority to FR2103009A priority Critical patent/FR3121243B1/fr
Priority to EP22715137.0A priority patent/EP4315741A1/fr
Priority to PCT/FR2022/050520 priority patent/WO2022200726A1/fr
Publication of FR3121243A1 publication Critical patent/FR3121243A1/fr
Application granted granted Critical
Publication of FR3121243B1 publication Critical patent/FR3121243B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3257—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using blind signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time

Abstract

La présente invention concerne un procédé d’échange de données entre un dispositif délégant (I2) et un dispositif délégué (I3) pour un accès à un fichier chiffré, une entrée d’accès propre au dispositif délégant et associée audit fichier étant stockée dans une liste d’accès publique d’une base de gestion d’accès, une clé de déchiffrement dudit fichier é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 œuvre par une unité de traitement du dispositif délégant (I2) :- réception (1100) d’une valeur d’identification propre au dispositif délégué (ID(U3, f1)) et associée audit fichier,- génération (1200) d’une valeur de délégation (Del) en fonction de ladite valeur d’identification,- transmission sécurisée (1300) au dispositif délégué de la valeur de délégation (Del), de sorte que le dispositif délégué peut ultérieurement obtenir l’entrée d’accès propre au dispositif délégant et calculer la clé de déchiffrement dudit fichier à l’aide de la valeur de délégation. Figure pour l’abrégé : Figure 2

Description

Gestion de droits d’accès à des fichiers numériques avec possible délégation des droits
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 œuvre l’échange de données, un ensemble de partage de fichiers chiffrés comprenant un tel dispositif, un produit programme d’ordinateur pour la mise en œuvre de l’échange de données, et des moyens de stockage lisibles par ordinateur pour la mise en œuvre 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 publicationDesign 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 publicationBlockchain-Based, Decentralized Access Control for IPFS, Steichen et al. (2018), 2018 IEEE International Conference 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 publicationFileTribe : Blockchain-Based Secure File Sharing on IPFS, Sari, Sipos (2019), European Wireless 2019 ; 25thEuropean Wireless Conference, 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 de fichiers 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 fichier 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 fichiers 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 fichiers 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 fichiers 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 du fichier est alors en mesure de révoquer des droits d’accès précédemment accordés pour le fichier, 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 fichier chiffré stocké en mémoire,
une entrée d’accès propre au dispositif délégant et associée audit fichier étant stockée dans une liste d’accès publique d’une base de gestion d’accès, une clé de déchiffrement dudit fichier é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 œuvre 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 fichier,
- génération d’une valeur de délégation en fonction de la valeur d’identification propre au dispositif délégué,
- transmission sécurisée au dispositif délégué de la valeur de délégation,
de sorte que le dispositif délégué peut ultérieurement obtenir l’entrée d’accès propre au dispositif délégant et calculer la clé de déchiffrement dudit fichier à l’aide de la valeur de délégation.
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 fichier 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 fichier.
- 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 fichier et la valeur d’identification propre au dispositif délégué associée audit fichier.
- 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 au fichier et la valeur d’identification propre au dispositif délégué associée au fichier.
- 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 fichier.
- le premier élément de ladite paire dépend d’un nombre aléatoire obtenu par le dispositif délégué.
- la transmission sécurisée au dispositif délégué de la valeur de délégation comprend la transmission 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 fichier 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 fichier 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 fichier 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, f1) 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 au fichier a été préalablement obtenue par un serveur propriétaire en fonction de la clé de déchiffrement du fichier, 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 au fichier comprend des sous-étapes, mises en œuvre par le serveur propriétaire, de :
obtention d’une valeur d’identification propre au dispositif délégant et associée audit fichier,
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 fichier,
calcul de la clé de déchiffrement,
calcul de l’entrée d’accès propre au dispositif délégant associée au fichier, 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 fichier chiffré stocké en mémoire,
une entrée d’accès propre à un dispositif délégant et associée audit fichier é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 fichier,
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 œuvre 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 fichier,
- calcul de la clé de déchiffrement dudit fichier, en fonction des trois données suivantes : une valeur d’identification propre au dispositif délégué et associée audit fichier, 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 fichier 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 fichier.
- le procédé comprend des étapes ultérieures, mises en œuvre par l’unité de traitement du dispositif délégué, de :
obtention du fichier chiffré auprès d’une mémoire,
et déchiffrement du fichier 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 œuvre 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 ensemble de partage de fichiers 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 œuvre 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.
L’ensemble de partage de fichiers 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.
- l’ensemble de partage de fichiers 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 fichier 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 œuvre 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 œuvre 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 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 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 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 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 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 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 fichier. On comprendra toutefois que lesdites valeurs utilisées pour gérer les droits d’accès pourraient également être communes à un ensemble de fichiers déterminés par le ou les propriétaires respectifs desdits fichiers. Notamment, la clé de déchiffrement d’un fichier pourrait également être valide pour d’autres fichiers 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.
*Système de partage de fichiers chiffrés
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 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 I1, I1’, 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 , 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 nœuds du système 1 (c’est-à-dire ici notamment les dispositifs I1, I1’, 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 f1, 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(I2)) 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 I1, I2, I1’, 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 I1 et un serveur utilisateur I2. Le serveur propriétaire I1 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 I1.
• pour l’organisation Org2, un serveur propriétaire I1’ et un serveur utilisateur I2’. Le serveur propriétaire I1’ 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 I1’.
• 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 I1, I1’, I2, I2’, … sollicite la mémoire qui est disponible dans son serveur local ; ainsi, dans l’exemple illustré sur la , le dispositif I1 peut interroger la mémoire M et le dispositif I1’ 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 I1, I1’, I2, I2’, I2’’, I3, I3’ comprend des moyens de traitement comme par exemple une unité de traitement, non représentée sur la .
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.
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 I1, I1’, 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.
*Délégation de droits d’accès temporaires à un fichier chiffré pour un délégué (Exemple 1)
On a représenté sur la des étapes successives d’un procédé d’échange de données entre un dispositif délégant (par exemple I2 ou I2’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 œuvre 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 f1. En effet, le calcul de la délégation Del ultérieurement attribuée au délégué I3 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 œuvre 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 f1, 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 œuvre 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. « 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 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 f1 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, f1) - 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 I2 et le délégué I3.
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 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 I1 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 , 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 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 f1, 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 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 œuvre 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 .
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(I2) 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(I2) 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, f1) propre au dispositif délégué I3 et associée au fichier f1, que le délégué I3 peut calculer le cas échéant s’il ne la possède pas en mémoire ;
• l’entrée d’accès ACL(U2, f1) lue dans la base DB de gestion d’accès ;
• la valeur de délégation Del préalablement reçue depuis le délégant I3, qui peut avoir été enregistrée en mémoire au préalable.
On rappelle que le délégué I3 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 œuvre 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), 0)]
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, f1) 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, f1), Del) = Aut(ID(U2, f1), ACL(U2, f1), 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 :
ID(U3, f1) + ACL (U2, f1) + Del = ID (U2, f1) + ACL (U2, f1)
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, f1) ne lui est pas utile. On propose donc deux niveaux différents d’accès au fichier f1 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 œuvre des procédés d’échanges de données.
A l’issue de l’étape 2300, le délégué I3 dispose de la clé de déchiffrement sk.
A une étape 2400, pouvant être mise en œuvre immédiatement après l’étape 2300 ou plus tardivement, le délégué I3 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 œuvre 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 I1).
*Enregistrement d’un nouveau fichier chiffré (Exemple 1)
La 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 œuvre par un dispositif propriétaire du fichier f1 (par exemple un propriétaire I1 ou I1’), une base de gestion d’accès DB et une mémoire de stockage M.
A une étape 3100, le propriétaire I1 génère un nouveau fichier f1 0non chiffré ou obtient ce fichier depuis sa mémoire interne. Comme indiqué ci-avant, les données du fichier f1 0sont par exemple des données scientifiques sensibles que le propriétaire I1 souhaite partager avec d’autres utilisateurs de manière sécurisée, tout en préservant la confidentialité des données du fichier f1 0.
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 I1 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 I1 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 I1.
Le propriétaire I1, quant à lui, calcule à une étape 3400 sa valeur d’identification ID (U1, f1) pour le fichier f1. Dans le présent exemple (Exemple 1), cette valeur d’identification est calculée comme suit :
ID(U1, f1) = U1 + 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 I1 est en mesure d’obtenir une valeur de clé de déchiffrement sk pour le fichier f1. La valeur de la clé de déchiffrement sk est construite de sorte que des délégants I2, I2’, I2’’… puissent ultérieurement mettre en œuvre des délégations comme vu ci-avant, sans solliciter le propriétaire I1.
Ainsi, à une étape 3500, le propriétaire I1 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, f1), ACL(U1, f1), 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 œuvre en parallèle de ces dernières étapes.
En alternative, le fichier f1 chiffré pourrait être obtenu par chiffrement asymétrique à partir du fichier f1 0non 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 I1 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 illustre des étapes d’un procédé d’échange de données entre un dispositif propriétaire (par exemple I1 ou I1’), un dispositif délégant (par exemple I2 ou I2’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 œuvre par une unité de traitement du propriétaire I1, 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 . De même, l’entrée d’accès ACL (U1, f1) du propriétaire I1 est, de préférence, obtenue comme décrit ci-avant en relation à la .
Au cours du procédé de la , le propriétaire I1 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 f1 sans avoir besoin d’une quelconque délégation, et sans avoir besoin que le propriétaire I1 soit connecté.
A une étape 4100, le délégant I2 transmet au propriétaire I1 sa valeur d’identification ID (U2, f1) pour le fichier f1. 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 et la transmission est réalisée de la même manière. En particulier :
- La valeur d’identification ID(U2, f1) 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 f1, 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 I1 et le délégant I2 connaissent ladite valeur.
A une étape 4200, le propriétaire I1 obtient la valeur de sa propre entrée d’accès ACL (U1, f1) pour le fichier f1, auprès de la base DB. Par exemple, le propriétaire I1 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, f1) peut sinon avoir été préalablement enregistrée par le propriétaire I1.
Ensuite, à une étape 4300, le propriétaire I1 obtient ou recalcule sa propre valeur d’identification ID (U1, f1), puis recalcule la clé de déchiffrement sk pour le fichier f1. 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 I1 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 f1. Celui-ci n’a pas besoin de communiquer avec le propriétaire I1 pour déchiffrer ultérieurement le fichier f1.
Enfin, à une étape 4600 optionnelle, le propriétaire I1 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 I2 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 I1. 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 œuvre, un moyen simple pour le propriétaire I1 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 illustre des étapes d’un procédé d’échange de données entre un dispositif délégant (par exemple I2 ou I2’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 œuvre 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 .
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 . 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 I1.
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(I2), 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 I1 du fichier. Le propriétaire I1 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 ( ), 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 ( ), en relation à un procédé de chiffrement et d’enregistrement d’un nouveau fichier f1 par un propriétaire I1 ( ), en relation à un procédé de génération de droits d’accès par un propriétaire I1 ( ) 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 ( ). 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 œuvre par le système 1 de partage de fichiers tel que décrit ci-avant, en relation à la .
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 ), à 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é I3 au délégant I2 est randomisée à l’aide d’un nombre aléatoire k obtenu par le délégué I3. On note que la valeur du nombre aléatoire k n’est pas connue du délégant I2.
Par exemple, la valeur retournée par le délégué I3 au délégant I2 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 ‘ID2’ 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 ), à 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é I3 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, f1), ACL(ID2(U2, f1)), 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 f1 se déroulent comme dans l’Exemple 1.
Au cours de la création et du chiffrement d’un nouveau fichier (similaire à la ), le propriétaire I1 utilise la première fonction d’identification ID1 pour le calcul de la nouvelle clé de déchiffrement sk associée au fichier f1, 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 I1 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(ID1(U1, f1), ACL(ID2(U1, f1)), 0)
Il n’est pas souhaitable que le propriétaire I1 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 I1 pour un délégant I2 (similaire à la ), 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 I1.
Ainsi, à l’étape 4100, le délégant I2 communique au propriétaire I1 la valeur suivante : [ID1(U2, f1) + k’].
Ici, le propriétaire I1 n’a donc pas accès en clair à la valeur ID1(U2, f1), contrairement à l’Exemple 1 où le propriétaire I1 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 I1 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 I1 et le délégant I2.
Dans cet Exemple 2, à une première sous-étape de l’étape 4400, le propriétaire I1 transmet au délégant I2 la valeur suivante :sk – [ID1(U2, f1) + 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, f1)].
C’est donc le délégant I2 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, f1)) = sk – ID1(U2, f1)
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 ) sont similaires à l’Exemple 1. Le délégant I2 doit soumettre sa valeur d’identification ID1(U2,f1) à 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 I1.
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.

Claims (25)

  1. Procédé d’échange de données entre un dispositif délégant (I2) et un dispositif délégué (I3) pour un accès à un fichier (f1) chiffré stocké en mémoire,
    une entrée d’accès (ACL(U2, f1)) propre au dispositif délégant (I2) et associée audit fichier (f1) étant stockée dans une liste d’accès (ACL) publique d’une base de gestion d’accès (DB), une clé (sk) de déchiffrement dudit fichier (f1) étant calculable par le dispositif délégant (I2) à l’aide de l’entrée d’accès (ACL(U2, f1)),
    le procédé comprenant les étapes suivantes mises en œuvre par une unité de traitement du dispositif délégant (I2) :
    - réception (1100) d’une valeur d’identification (ID(U3, f1)) propre au dispositif délégué (I3) et associée audit fichier (f1),
    - génération (1200) d’une valeur de délégation (Del) en fonction de la valeur d’identification (ID(U3, f1)) propre au dispositif délégué (I3),
    - transmission sécurisée (1300) au dispositif délégué (I3) de la valeur de délégation (Del),
    de sorte que le dispositif délégué (I3) peut ultérieurement obtenir l’entrée d’accès (ACL(U2, f1)) propre au dispositif délégant (I2) et calculer la clé (sk) de déchiffrement dudit fichier (f1) à l’aide de la valeur de délégation (Del).
  2. Procédé d’échange de données selon la revendication 1, dans lequel la valeur d’identification (ID(U3, f1)) propre au dispositif délégué (I3) dépend d’une clé privée (U3) du délégué (I3), ladite valeur d’identification (ID(U3, f1)) étant construite de sorte qu’un tiers ne peut pas obtenir ladite valeur d’identification (ID(U3, f1)) du délégué sans connaître la clé privée (U3) du délégué (I3).
  3. Procédé d’échange de données selon l’une quelconque des revendications 1 ou 2, dans lequel la valeur d’identification propre au dispositif délégué (I3), notée ID(U3, f1), est obtenue comme suit :
    ID(U3, f1) = U3 + sha256(concatenation(U3, f1))
    où f1 est ledit fichier chiffré,
    et où U3 est une clé privée du dispositif délégué (I3).
  4. Procédé d’échange de données selon l’une quelconque des revendications 1 à 3, dans lequel la valeur de délégation (Del) est calculée par l’unité de traitement :
    - en fonction de ladite valeur d’identification (ID(U3, f1)) propre au dispositif délégué (I3),
    - et en fonction d’une valeur d’identification (ID(U2, f1)) propre au dispositif délégant (I2) et associée audit fichier (f1).
  5. Procédé d’échange de données selon la revendication 4, dans lequel la valeur d’identification (ID(U2, f1)) propre au dispositif délégant (I2) dépend d’une clé privée (U2) du délégant (I2), ladite valeur d’identification (ID(U2, f1)) propre au délégant étant construite de sorte qu’un tiers ne peut pas obtenir ladite valeur d’identification (ID(U2, f1)) propre au délégant sans connaître la clé privée (U2) du délégant.
  6. Procédé d’échange de données selon l’une quelconque des revendications 4 ou 5, dans lequel la valeur de délégation (Del) est égale à une différence entre la valeur d’identification (ID(U2, f1)) propre au dispositif délégant (I2) associée audit fichier (f1) et la valeur d’identification (ID(U3, f1)) propre au dispositif délégué (I3) associée audit fichier (f1).
  7. Procédé d’échange de données selon l’une quelconque des revendications 4 ou 5, dans lequel la valeur de délégation (Del) est égale à une paire,
    dans lequel un premier élément de ladite paire dépend d’une différence entre la valeur d’identification (ID1(U2, f1)) propre au dispositif délégant (I2) associée au fichier (f1) et la valeur d’identification (ID1(U3, f1)) propre au dispositif délégué (I3) associée au fichier (f1), et dans lequel un deuxième élément de ladite paire est égal à une valeur d’identification anonyme pour le délégué (ID2(U2, f1)) propre au dispositif délégant (I2) et associée audit fichier (f1).
  8. Procédé d’échange de données selon la revendication 7, dans lequel le premier élément de ladite paire dépend d’un nombre aléatoire (k) obtenu par le dispositif délégué (I3).
  9. Procédé d’échange de données selon l’une quelconque des revendications 1 à 8, dans lequel la transmission sécurisée (1300) au dispositif délégué (I3) de la valeur de délégation (Del) comprend la transmission d’un message signé contenant la valeur de délégation (Del), par exemple un message signé par signature DSA.
  10. Procédé d’échange de données selon l’une quelconque des revendications 1 à 9, dans lequel la clé (sk) de déchiffrement dudit fichier (f1) 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.
  11. Procédé d’échange de données selon l’une quelconque des revendications 1 à 9, dans lequel une valeur de la clé (sk) de déchiffrement dudit fichier (f1) 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 fichier chiffré,
    où U2 est une clé privée dudit dispositif délégant (I2),
    où U3 est une clé privée dudit dispositif délégué (I3),
    où Del est ladite valeur de délégation,
    où ID(U2, f1) est ladite valeur d’identification propre au dispositif délégant (I2),
    où ID(U3, f1) est ladite valeur d’identification propre au dispositif délégué (I3),
    et où ACL(U2, f1) est ladite entrée d’accès propre au dispositif délégant (I2).
  12. Procédé d’échange de données selon l’une quelconque des revendications 1 à 11, dans lequel l’entrée d’accès (ACL(U2, f1)) propre au dispositif délégant (I2) et associée au fichier (f1) a été préalablement obtenue par un serveur propriétaire (I1) en fonction de la clé (sk) de déchiffrement du fichier (f1) et ayant été stockée dans la base de gestion d’accès (DB).
  13. Procédé d’échange de données selon la revendication 12, dans lequel l’obtention de l’entrée d’accès (ACL(U2, f1)) propre au dispositif délégant (I2) et associée au fichier (f1) comprend des sous-étapes mises en œuvre par le serveur propriétaire (I1) de :
    - obtention (4100) d’une valeur d’identification (ID(U2, f1)) propre au dispositif délégant (I2) et associée audit fichier (f1),
    - réception (4200), depuis la base de gestion d’accès (DB), d’une entrée d’accès (ACL(U1, f1)) propre au serveur propriétaire (I1) et associée audit fichier (f1),
    - calcul (4300) de la clé (sk) de déchiffrement,
    - calcul (4400) de l’entrée d’accès (ACL(U2, f1)) propre au dispositif délégant (I2) associée au fichier (f1), en fonction de ladite entrée d’accès (ACL(U1, f1)) propre au serveur propriétaire (I1) et en fonction de ladite clé (sk) de déchiffrement.
  14. Procédé d’échange de données selon l’une quelconque des revendications 1 à 13, dans lequel la liste d’accès (ACL) publique est une liste distribuée sur une infrastructure en nuage, et/ou une liste implémentée via une blockchain, et/ou une liste distribuée sur un réseau pair à pair intégrant le dispositif délégant (I2) et le dispositif délégué (I3).
  15. Procédé d’échange de données entre un dispositif délégué (I3) et une base de gestion d’accès (DB) pour un accès à un fichier (f1) chiffré stocké en mémoire,
    une entrée d’accès (ACL(U2, f1)) propre à un dispositif délégant (I2) et associée audit fichier (f1) étant stockée dans la base de gestion d’accès (DB), ladite entrée d’accès (ACL(U2, f1)) permettant au dispositif délégant (I2) d’obtenir une clé (sk) de déchiffrement dudit fichier (f1),
    le dispositif délégué (I3) ayant préalablement reçu une valeur de délégation (Del) depuis le dispositif délégant (I3) à l’issue d’un procédé d’échange de données conforme à l’une quelconque des revendications 1 à 14,
    le procédé comprenant les étapes suivantes mises en œuvre par une unité de traitement du dispositif délégué (I3) :
    - obtention de l’entrée d’accès (ACL(U2, f1)) propre au dispositif délégant (I2) et associée audit fichier (f1),
    - calcul (2300) de la clé (sk) de déchiffrement dudit fichier (f1), en fonction des trois données suivantes :
    • une valeur d’identification (ID(U3, f1)) propre au dispositif délégué (I3) et associée audit fichier (f1) ;
    • l’entrée d’accès (ACL(U2, f1)) propre au dispositif délégant (I2) préalablement obtenue ;
    • la valeur de délégation (Del) préalablement reçue depuis le dispositif délégant (I3).
  16. Procédé d’échange de données selon la revendication 15, dans lequel l’obtention de l’entrée d’accès (ACL(U2, f1)) propre au dispositif délégant (I2) et associée audit fichier (f1) comprend :
    - une transmission (2100) à la base de gestion d’accès (DB) d’une donnée associée au dispositif délégant (I2),
    - une réception (2200), depuis la base de gestion d’accès (DB), de ladite entrée d’accès (ACL(U2, f1)) propre au dispositif délégant (I2).
  17. Procédé d’échange de données selon la revendication 16, dans lequel la donnée transmise (2100) à la base de gestion d’accès (DB) pour obtenir l’entrée d’accès (ACL(U2, f1)) comprend un identifiant du dispositif délégant (I2).
  18. Procédé d’échange de données selon la revendication 17, dans lequel la donnée transmise (2100) à la base de gestion d’accès (DB) pour obtenir l’entrée d’accès (ACL(ID2(U2, f1))) comprend une valeur d’identification anonymisée (ID2(U2, f1)) propre au dispositif délégant (I2) et associée audit fichier (f1).
  19. Procédé d’échange de données selon l’une quelconque des revendications 15 à 18, le procédé comprenant des étapes ultérieures, mises en œuvre par l’unité de traitement du dispositif délégué (I3), de :
    - obtention (2400) du fichier (f1) chiffré auprès d’une mémoire,
    - déchiffrement (2500) du fichier (f1) chiffré, à l’aide de la clé (sk) préalablement calculée, de préférence par déchiffrement symétrique.
  20. Dispositif informatique délégant (I2) comprenant une unité de traitement configurée pour mettre en œuvre un procédé d’échange de données selon l’une quelconque des revendications 1 à 14 avec un dispositif délégué (I3).
  21. Ensemble de partage de fichiers chiffrés, l’ensemble comprenant :
    - un serveur d’accès (S) comprenant une base de gestion d’accès (DB) dans laquelle est enregistrée une liste d’accès (ACL) publique comportant au moins une entrée d’accès (ACL(U2, f1)),
    - au moins un dispositif délégant (I2) conforme à la revendication 20,
    - au moins un dispositif délégué (I3) comprenant une unité de traitement configurée pour mettre en œuvre un procédé d’échange de données avec la base de gestion d’accès (DB) selon l’une quelconque des revendications 15 à 19.
  22. Ensemble de partage de fichiers chiffrés selon la revendication 21, dans lequel le dispositif délégant (I2) comprend un serveur utilisateur et/ou dans lequel le dispositif délégué (I3) comprend un serveur de calcul.
  23. Ensemble de partage de fichiers chiffrés selon l’une quelconque des revendications 21 ou 22, l’ensemble comprenant en outre un serveur propriétaire de donnée (I1) configuré pour calculer des entrées d’accès (ACL(U2, f1)) propres à des dispositifs délégants (I2) associées à au moins un fichier (f1) chiffré, et configuré pour partager lesdites entrées d’accès (ACL(U2, f1)) avec le serveur d’accès (S).
  24. 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 œuvre un procédé d’échange de données selon l’une quelconque des revendications 1 à 14.
  25. 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 œuvre un procédé d’échange de données selon l’une quelconque des revendications 1 à 14.
FR2103009A 2021-03-25 2021-03-25 Gestion de droits d’accès à des fichiers numériques avec possible délégation des droits Active FR3121243B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR2103009A FR3121243B1 (fr) 2021-03-25 2021-03-25 Gestion de droits d’accès à des fichiers numériques avec possible délégation des droits
EP22715137.0A EP4315741A1 (fr) 2021-03-25 2022-03-22 Gestion de droits d'accès à des fichiers numériques avec possible délégation des droits
PCT/FR2022/050520 WO2022200726A1 (fr) 2021-03-25 2022-03-22 Gestion de droits d'accès à des fichiers numériques avec possible délégation des droits

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2103009A FR3121243B1 (fr) 2021-03-25 2021-03-25 Gestion de droits d’accès à des fichiers numériques avec possible délégation des droits
FR2103009 2021-03-25

Publications (2)

Publication Number Publication Date
FR3121243A1 true FR3121243A1 (fr) 2022-09-30
FR3121243B1 FR3121243B1 (fr) 2023-12-29

Family

ID=75690577

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2103009A Active FR3121243B1 (fr) 2021-03-25 2021-03-25 Gestion de droits d’accès à des fichiers numériques avec possible délégation des droits

Country Status (3)

Country Link
EP (1) EP4315741A1 (fr)
FR (1) FR3121243B1 (fr)
WO (1) WO2022200726A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116861474B (zh) * 2023-05-26 2024-02-20 东莞市铁石文档科技有限公司 一种在线档案安全评估系统和方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100082989A1 (en) * 2008-09-26 2010-04-01 Microsoft Corporation Storing Composite Services on Untrusted Hosts
US20190065764A1 (en) * 2017-08-31 2019-02-28 Gavin Wood Secret Data Access Control Systems and Methods
CN110636043A (zh) * 2019-08-16 2019-12-31 中国人民银行数字货币研究所 一种基于区块链的文件授权访问方法、装置及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100082989A1 (en) * 2008-09-26 2010-04-01 Microsoft Corporation Storing Composite Services on Untrusted Hosts
US20190065764A1 (en) * 2017-08-31 2019-02-28 Gavin Wood Secret Data Access Control Systems and Methods
CN110636043A (zh) * 2019-08-16 2019-12-31 中国人民银行数字货币研究所 一种基于区块链的文件授权访问方法、装置及系统

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
JAWADSERRANO-ALVARADOVALDURIEZ: "Design of PriServ, a Privacy Service for DHTs", PROCEEDINGS OF THE 2008 INTERNATIONAL WORKSHOP ON PRIVACY AND ANONYMITY IN THE INFORMATION SOCIETY, PAIS '08, ASSOCIATION FOR COMPUTING MACHINERY, 2008, pages 21 - 25, XP058089060, DOI: 10.1145/1379287.1379293
SÁRI LÁSZLÓ ET AL: "FileTribe: Blockchain-based Secure File Sharing on IPFS", 2 May 2019 (2019-05-02), XP055860240, Retrieved from the Internet <URL:https://ieeexplore.ieee.org/ielx7/8835928/8835929/08835937.pdf?tp=&arnumber=8835937&isnumber=8835929&ref=aHR0cHM6Ly9pZWVleHBsb3JlLmllZWUub3JnL2Fic3RyYWN0L2RvY3VtZW50Lzg4MzU5Mzc=> [retrieved on 20211111] *
SARI, SIPOS: "FileTribe : Blockchain-Based Secure File Sharing on IPFS", EUROPEAN WIRELESS 2019 ; 25TH EUROPEAN WIRELESS CONFÉRENCE, 2019, pages 1 - 6
STEICHEN ET AL.: "Blockchain-Based, Decen-tralized Access Control for IPFS", 2018 IEEE INTERNATIONAL CONFÉRENCE ON INTERNET OF THINGS (ITHINGS, 2018, pages 1499 - 1596
TRUONG NGUYEN BINH ET AL: "GDPR-Compliant Personal Data Management: A Blockchain-Based Solution", IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, IEEE, USA, vol. 15, 17 October 2019 (2019-10-17), pages 1746 - 1761, XP011768206, ISSN: 1556-6013, [retrieved on 20200123], DOI: 10.1109/TIFS.2019.2948287 *

Also Published As

Publication number Publication date
EP4315741A1 (fr) 2024-02-07
FR3121243B1 (fr) 2023-12-29
WO2022200726A1 (fr) 2022-09-29

Similar Documents

Publication Publication Date Title
Zhao et al. Trusted data sharing over untrusted cloud storage providers
EP3506556B1 (fr) Méthode d&#39;échange de clés authentifié par chaine de blocs
EP2819052B1 (fr) Procédé et serveur de traitement d&#39;une requête d&#39;accès d&#39;un terminal à une ressource informatique
CN102318262B (zh) 受信云计算和服务框架
WO2009130089A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
CN102318263A (zh) 受信云计算和服务框架
Badsha et al. Blocynfo-share: Blockchain based cybersecurity information sharing with fine grained access control
CA2895189C (fr) Signature de groupe utilisant un pseudonyme
WO2009130088A1 (fr) Terminal d&#39;authentification forte d&#39;un utilisateur
CA3142763A1 (fr) Procede de chiffrement et de stockage de fichiers informatiques et dispositif de chiffrement et de stockage associe.
EP3840287A1 (fr) Plateforme securisee, decentralisee, automatisee et multi-acteurs de gestion d&#39;identites d objets au travers de l utilisation d&#39;une technologie de chaine de blocs
Wise et al. Cloud docs: secure scalable document sharing on public clouds
WO2022200726A1 (fr) Gestion de droits d&#39;accès à des fichiers numériques avec possible délégation des droits
FR2892876A1 (fr) Procede de depot securise de donnees numeriques, procede associe de recuperation de donnees numeriques, dispositifs associes pour la mise en oeuvre des procedes, et systeme comprenant les dits dispositifs
Chougule et al. Digital evidence management system for cybercrime investigation using proxy re-encryption and blockchain
WO2019228853A1 (fr) Methode d&#39;etablissement de cles pour le controle d&#39;acces a un service ou une ressource
EP4024239B1 (fr) Procede et systeme de stockage et de partage de donnees
EP4078893A1 (fr) Procédé et dispositif de contrôle d&#39;accès anonyme à une plateforme collaborative d&#39;anonymisation
Sivanantham et al. Reliable Data Storage and Sharing using Block chain Technology and Two Fish Encryption
Abouali et al. Patient full control over secured medical records transfer framework based on blockchain
Sathana et al. Three level security system for dynamic group in cloud
WO2017009067A1 (fr) Méthode de délégation sécurisée de calculs coûteux pour algorithmes de chiffrement à clé publique
Kumar et al. Securing cloud access with enhanced attribute-based cryptography
FR3134908A1 (fr) Procédé et système de gestion des droits d’accès dans une transaction équitable de données numériques
Catherine et al. An Efficient and Secure Data Sharing Scheme for Ciphertext-Policy Attribute-based Signcryption for Cloud Storage Services

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20220930

PLFP Fee payment

Year of fee payment: 3