WO2022200726A1 - 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
WO2022200726A1
WO2022200726A1 PCT/FR2022/050520 FR2022050520W WO2022200726A1 WO 2022200726 A1 WO2022200726 A1 WO 2022200726A1 FR 2022050520 W FR2022050520 W FR 2022050520W WO 2022200726 A1 WO2022200726 A1 WO 2022200726A1
Authority
WO
WIPO (PCT)
Prior art keywords
access
data
acl
specific
delegating
Prior art date
Application number
PCT/FR2022/050520
Other languages
English (en)
Inventor
Bastien CONFAIS
Gustavo ROSTIROLLA
François MARQUES
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 EP22715137.0A priority Critical patent/EP4315741A1/fr
Publication of WO2022200726A1 publication Critical patent/WO2022200726A1/fr

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

Definitions

  • the present invention falls within the field of distributed computer systems for the transmission and sharing of digital data.
  • the invention relates more particularly to a method for exchanging data between a so-called “delegating” computer device and a so-called “delegate” computer device, the respective roles of which in the sharing of data will emerge from the description below, as well as than a process for exchanging data between a delegated device and an access management database.
  • the invention also relates to a computer device comprising a processing unit making it possible to implement the exchange of data, a system for sharing sets of encrypted data comprising such a device, a computer program product for the implementation of the data exchange, and computer-readable storage means for carrying out the data exchange.
  • the computer file is encrypted and publicly accessible. Thanks to encryption, although the file is accessible without control, access to the information contained in the file is regulated.
  • the owner of the computer file generates a decryption key and must communicate directly on the network with each user authorized to access the file to transmit the key to him.
  • Design of PriServ, a Privacy Service for DHTs, Jawad, Serrano-Alvarado, Valduriez (2008), Proceedings of the 2008 International Workshop on Privacy and Anonymity in the Information Society, PAIS '08, Association for Computing Machinery, pp.21 -25 described for example an access rights management solution based on key exchanges.
  • a first drawback of this approach is that an interception of the exchanges by a third-party attacker, or a usurpation of the identity of the authorized user by a third-party attacker, would both call into question the security of the encryption of the file.
  • a second major drawback is the need for a simultaneous connection of the file owner and the user who must receive the access rights, for each new sharing.
  • the access control list ACL is public and accessible "in the clear" without control, so that any third party user can know the identity of the users authorized to access the file by an simple consultation of the access control list ACL.
  • file access rights management solutions have been proposed, such as a file encryption solution by attributes or even a "proxy re-encryption” solution, but these solutions are very complex at the computational level. .
  • the computing power and energy consumption of these access rights management solutions make them impractical for large-scale deployment.
  • Such a distribution of rights would, for example, be relevant when users connected to a telecommunications network and authorized to access a given file wish to request a calculation server with computing power very important, this calculation server being shared on said network. It would then be appropriate to allow the calculation server to temporarily access the file, ensuring that this access does not allow the calculation server to provide permanent access rights to other entities.
  • one objective of the invention is to provide a solution for sharing encrypted data sets between several remote computing devices in which it is easy to provide temporary access rights to a new computing device for a given protected data set - for example to a computing server requested from time to time.
  • the solution sought must, for example, allow the targeted sharing of symmetric or asymmetric encryption keys associated with protected data sets.
  • a secondary objective of the invention is to take charge of the possible revocation of access rights; the data owner is then able to revoke previously granted access rights to the data, rendering those accesses obsolete.
  • a first aspect of the invention relates to a method for exchanging data between a delegating device and a delegate device for access to an encrypted data set stored in memory, an access entry specific to the delegating device and associated with said set of data being stored in a public access list of an access management database, a decryption key of said set of data being calculable by the delegating device using the access input, the method comprising the following steps implemented by a processing unit of the delegating device:
  • the data exchange method according to this first aspect of the invention may also have the following technical characteristics, taken alone or in any of the possible combinations:
  • the identification value specific to the delegate device depends on a private key of the delegate, said identification value being constructed so that a third party cannot obtain said identification value of the delegate without knowing the private key of the delegate .
  • ID(U3, f1 ) U3 + sha256(concatenation (U3, f1)) where f1 is said encrypted data set , and where U3 is a private key of the delegated device.
  • the delegation value is calculated by the processing unit according to said identification value specific to the delegated device, and according to an identification value specific to the delegating device and associated with said data set.
  • the identification value specific to the delegating device depends on a private key of the delegator, said identification value specific to the delegator being constructed so that a third party cannot obtain said identification value specific to the delegator without knowing the private key of the delegator.
  • the delegation value is equal to a difference between the identification value specific to the delegating device associated with said set of data and the identification value specific to the delegated device associated with said set of data. - the delegation value is equal to a pair.
  • a first element of said pair depends on a difference between the identification value specific to the delegating device associated with said data set and the identification value specific to the delegated device associated with said data set.
  • a second element of said pair is equal to an anonymous identification value for the delegate specific to the delegating device and associated with said data set.
  • the first element of said pair depends on a random number obtained by the delegated device.
  • the decryption key of said data set comprises a symmetrical decryption key, for example a decryption key obtained by an AES algorithm or by a 3DES algorithm.
  • the access entry specific to the delegating device and associated with said data set was previously obtained by a proprietary server according to the decryption key of said data set, and was stored in the access management database.
  • - obtaining the access entry specific to the delegating device and associated with said set of data comprises sub-steps, implemented by the owner server, of: obtaining an identification value specific to the delegating device and associated with said set of data, reception, from the access management database, of an access entry specific to the owner server and associated with said set of data, calculation of the decryption key, calculation of the access entry specific to the delegating device associated with said data set, according to said access entry specific to the owner server and according to said decryption key.
  • the public access list is distributed over a cloud infrastructure.
  • the public access list is implemented via a blockchain.
  • the public access list is distributed on a peer-to-peer network integrating the delegating device and the delegated device.
  • the invention relates to a method for exchanging data between a delegated device and an access management base for access to a set of encrypted data stored in memory, an access entry specific to a device delegating party and associated with said data set being stored in the access management database, said access entry allowing the delegating device to obtain a decryption key of said data set, the delegate device having previously received a delegation value from the delegating device, at the end of a data exchange process between the delegate and a delegator as defined above, the process comprising the following steps implemented by a processing unit of the delegated device:
  • the data exchange method according to this second aspect of the invention may also have the following technical characteristics, taken alone or in any of the possible combinations:
  • - obtaining the access entry specific to the delegating device and associated with said data set includes: a transmission of data associated with the delegating device to the access management base, a reception, from the access management base, of said access entry specific to the delegating device.
  • the data transmitted to the access management database to obtain the access entry includes an identifier of the delegating device.
  • the data transmitted to the access management database to obtain the access entry includes an anonymized identification value, specific to the delegator and associated with said data set.
  • the method comprises subsequent steps, implemented by the processing unit of the delegated device, of: obtaining the encrypted data set from a memory, and decrypting the encrypted data set, at the using the previously calculated key, preferably by symmetric decryption.
  • the invention further relates, according to a third aspect of the invention, to a delegating computing device comprising a processing unit configured to implement a data exchange method as defined above with a delegated device.
  • the invention also relates to a system for sharing encrypted data sets comprising such a computer device and further comprising: an access server comprising an access management base in which is recorded a public access list comprising at at least one access entry, and at least one delegate device comprising a processing unit configured to implement a data exchange method as defined above between the delegate device and an access management base.
  • the encrypted data set sharing system may have, optionally and without limitation, the following technical characteristics, taken alone or in any of the possible combinations:
  • the delegating device comprises a user server.
  • the delegated device comprises a calculation server.
  • the encrypted data set sharing system further comprises a data owner server configured to calculate access entries specific to delegating devices associated with at least one encrypted data set, and configured to share said access with the access server.
  • a fourth aspect of the invention relates to a computer program product comprising code instructions which, when said code instructions are executed by a processing unit, lead said processing unit to implement an exchange method data as defined above.
  • a fifth aspect of the invention relates to computer-readable storage means on which are recorded code instructions which, when said code instructions are executed by a processing unit, cause said processing unit to implement a data exchange process as defined above.
  • Figure 1 is a diagram representing a set of data sharing according to an example embodiment, comprising in particular a plurality of delegating devices, a plurality of delegated devices and an access management base.
  • Figure 2 shows the steps of an example process for delegating access rights to an encrypted file, from a delegating device to a delegate device.
  • Figure 3 represents the steps of an example of a method for accessing an encrypted file by a delegated device having previously received a delegation, preferably a temporary delegation.
  • Figure 4 represents the steps of an example of a process for encrypting and saving a file by a proprietary device, allowing a possible subsequent delegation of access rights to the saved encrypted file.
  • FIG. 5 represents the steps of an example of a method for generating access rights, preferably permanent, from an owner device to a delegating device.
  • FIG. 6 represents the steps of an example of a method for accessing an encrypted file by a delegating device for which access rights, preferably permanent, have been previously generated by a proprietary device.
  • the different cryptographic values used for access management are specific to a single data set. It will however be understood that said values used to manage the access rights could also be common to several data sets determined by the respective owner(s) of said data sets. In particular, the decryption key of a data set could also be valid for other determined data sets.
  • the example is taken from encrypted data sets stored in memory as files.
  • the invention is however not limited to this scenario but also extends to sets of data stored in block mode (each set thus constitutes a block of data, resulting for example but not necessarily from the splitting of a file in several blocks) or in object mode.
  • the following description concerns the management of access rights to encrypted files by network entities. It is considered that the entities have previously shared together a rights management protocol.
  • Figure 1 schematically represents a file sharing system 1 between computer devices of several organizations Org1, Org2, Org3, ..., connected to the same network N, preferably a remote telecommunications network.
  • Network N is typically an Internet, Intranet, 3G, 4G, 5G, DECT, Bluetooth, etc. telephone network.
  • the organizations Org1 , Org2, Org3 are geophysical and/or environmental data management organizations.
  • Data means geophysical” data relating to the physical characteristics of the Earth, typically resulting from measurements. It may be geological and/or seismic and/or gravimetric and/or atmospheric and/or spatial data, etc.
  • Environmental data means data relating to the biological and human environment of an area, for example biological and/or sound and/or chemical and/or hydrological and/or energy data and/or data relating to the treatment of waste. This data is typically sensitive data made selectively available to organizations.
  • the organizations Org1, Org2, Org3 are for example distant from each other, and can belong to different territories.
  • Each of the organizations Org1, Org2, Org3 is for example a local authority and/or a private company involved in the collection or processing of data and/or an association involved in the collection or processing of data and/or an organization that owns storage and/or compute servers.
  • each of the organizations Org1, Org2, Org3 is independent.
  • calculation server is meant a server having a very high computing power, typically greater than each of the devices 11, 11', I2, I2', I2", .... It is desired to be able to selectively put one and/or the other of these servers I3 and I3' available to other organizations in the network in order to perform processing on geophysical and/or environmental data.
  • FIGS. 2 to 6 are not limited to the case of geophysical and/or environmental data. These methods can advantageously be used regardless of the type of content of the files or the type of organization Org1, Org2, Org3, etc. or also for two organizations.
  • An application to geophysical and/or environmental data is advantageous, since the computational processing of said data may require high computing power. Local authorities should be able to temporarily entrust certain processing operations to calculation servers, without question the integrity and confidentiality of the data contained in the files.
  • system 1 comprises at least one access server S, storing an access management database DB.
  • the access server S may be contained in a single computing device, or may be distributed over several devices (possibly located at a distance from each other and present on different sites), for example by using hash tables and/or a blockchain.
  • the server S includes a processing unit (not shown).
  • server S stores the various ACL access lists.
  • a memory of the access management database DB (or, alternatively, a remote memory with which the database DB can communicate) comprises at least one access list ACL(f1) with at least one access entry for a encrypted f1 file.
  • the access management DB also includes an access list ACL(f2) with at least one access entry for an encrypted file f2. It will be understood that access entries to the files f1 and f2 can be granted to different users.
  • all the nodes of the system 1 can access each of the encrypted files f1, f2, ... without control, for example via a distributed storage system managing the memories M, M', M”.
  • the encrypted files fl , f2, ... are then publicly available. Access to the information contained in the file is regulated by the presence of the encryption keys, but access to the file itself is preferably unregulated.
  • An access list typically includes match pairs. Each pair associates a device identifier (for example d(l2)) and a numerical value (for example ACL (U2, f1 )) intended to allow said device to access the content of the file f1 .
  • a device identifier for example d(l2)
  • a numerical value for example ACL (U2, f1 )
  • the ACL access entry (U2, f1 ) allows the device I2 to use its private key U2 to calculate the value of a decryption key for the file f1 .
  • the content of the file f1 includes, for example, data collected from the sensor Sa and/or from any of the other sensors.
  • the ACL access list is a public list.
  • public we mean that the ACL access list is easily accessible by any of the devices of the organizations Org1 , Org2, Org3, ... as well as by devices belonging to third-party users.
  • no specific access control measure e.g. based on cryptographic keys and/or blockchain consensus, etc.
  • the ACL access list is easily searchable, at least in read mode, by each of the aforementioned users.
  • the private keys U1 , U2, U1 ', U2', ..., belonging respectively to the devices 11 , I2, 11 ', I2', ..., are, in turn, stored very securely. These are, for example, numerical values specific to each device. It is assumed that none of the devices shares its private key, neither on network N nor with any of the other devices.
  • system 1 further includes:
  • the owner server 11 is configured to create encrypted files and to calculate access entries specific to itself and/or to the user server I2 and/or to other devices present on the network N for these files;
  • the organization Org1 also includes, in this example, a sensor Sa intended to collect geophysical and/or environmental data.
  • the sensor Sa can here exchange data with the server 11 .
  • an owner server 11' and a user server I2' are configured to create encrypted files and to calculate access entries specific to itself and/or to the user server I2' and/or to other devices present on the network N for these files;
  • the organization Org2 also includes, in this example, two sensors Sb and Sc intended to collect geophysical and/or environmental data.
  • the two sensors Sb and Sc can here exchange data with the server 11 '.
  • Org3 • for the organization Org3, a user server I2”.
  • the Org3 organization does not have significant computing power here suitable for performing heavy processing on geophysical and/or environmental data.
  • the system 1 further comprises a storage memory M.
  • Memory M can store ACL access lists.
  • the memory M belongs to the organization Org1.
  • the memory M could be integrated into the access server S and/or integrated into any of the devices of one of the organizations Org1, Org2, Org3, etc., or remote from each of these devices.
  • the organization Org2 here has a storage memory M′
  • the organization Org3 here has a storage memory M′′.
  • a common namespace is used.
  • the memories M, M’, M” belong to a distributed storage system, for example made using an overlay network.
  • a user accesses an ACL access-list entry, it is not necessary for the user to know in advance in which memory of system 1 said access-list entry is located.
  • each device 11, 11′, I2, I2′, etc. requests the memory which is available in its local server; thus, in the example illustrated in Figure 1, device 11 can interrogate memory M and device 11' can interrogate memory M'.
  • the memories M, M’, and M belong to the same distributed storage system, the files stored in the other memories are also accessible.
  • the recordings on a memory cannot be modified subsequently.
  • This last property is for example ensured as a service by the distributed storage solution used.
  • Each encrypted file is recorded either on any one of the memories M, M', M”, ..., or on a memory of the server S or on a remote memory.
  • file f1 is stored in memory M of organization Org1
  • file f2 is stored in memory M' of organization Org2.
  • Other files, preferably encrypted or possibly unencrypted, can be saved in memory.
  • Each of the devices 11, 11′, I2, I2′, I2′′, I3, I3′ comprises processing means such as for example a processing unit, not shown in Figure 1.
  • Each of these processing means can comprise in memory one or more computer program products comprising code instructions for the implementation of the methods described below, and/or can read one or more computer-readable storage means on which are recorded code instructions for the implementation of the methods described below.
  • the organizations Org1, Org2, Org3 wish to be able to request the calculation servers I3, I3' in order to have their computing power to perform processing on the geophysical and/or environmental data to which any of the devices 11, 11', I2, I2', I2” has access according to the ACL access lists. To do this, it is desired to allocate access (typically only in read mode) to one of the encrypted files f1 and/or f2 for one of the calculation servers I3 and/or I3′, selectively and preferably temporarily.
  • the data written by a given user in a file can no longer be modified, preferably including by the owner of said file.
  • Such a prohibition to modify file data after its creation is for example provided, in the form of a service, by the distributed storage system used for the memories M, M’, M”.
  • the methods below make it possible to carry out two levels of access to the files, as will be detailed below.
  • the servers I2, I2' and I2” are delegating; they may have access entries for them in ACL access lists.
  • the servers I3 and I3' are delegated; they can receive a delegation from a delegator.
  • FIG. 2 Successive steps of a data exchange process between a delegating device (for example I2 or I2′ or I2′′) and a delegated device (for example I3 or I3′) are represented in Figure 2 according to an example.
  • One objective of this method is to provide a delegation value Del to the delegate device I3, to allow said delegate I3 to access (preferably temporarily) an encrypted file f1 for which the delegating device I2 holds access rights.
  • This method can be implemented by a processing unit of the delegating device I2, together with the delegate I3.
  • the encrypted f1 file is typically a read-only file.
  • the contents of file f1 can be writable once access to file f1 has been granted.
  • the delegated device I3 is a computing server shared on the network N, called upon temporarily to lend its computing power.
  • delegator I2 In order for delegator I2 to generate and pass a delegation to delegate I3, delegator I2 needs to get an identifying function value specific to delegate I3 for file fl . Indeed, the calculation of the delegation Del subsequently assigned to the delegate 13 depends on said identification value.
  • the ID identification function has been shared between the different organizations of the network before starting the data exchanges. For example, the identification function ID has been previously specified in the code of the program allowing the implementation of the various data exchange methods, and distributed with said program.
  • the delegate I3 optionally receives an identification request Req ID from the delegator I2.
  • the identification request Req ID preferably takes the form of a message sent by the delegator I2 to the delegate I3.
  • the delegate I3 obtains or recalculates a value ID(U3, f1 ) which is specific to it for the identification function ID, from an identity of the file f1 and from its private key U3.
  • the identification value ID(U3, f1 ) depends on the private key U3 of the delegate I3. This identification value is constructed in such a way that a third party cannot obtain this value by simply knowing an identity of the file fl , without knowing the private key U3.
  • the identification value ID(U3, f1 ) depends here also on the identity of the file f1; that is, the I3 delegate identification values differ for each file.
  • the results produced by the identification function ID seem random from the point of view of a third party who does not know the private key used, but these results are deterministic for the user having knowledge of the private key used.
  • the identification function ID preferably has the following three properties:
  • the identification function ID allows users of system 1 to exchange data with a view to allocating and/or using access rights to files, without possibly malicious third-party users being able to guess the private keys of users, or gain illicit access to the content of encrypted files.
  • the access rights management solution proposed here therefore has a very high level of security, although the ACL list of the DB access management database is public and no access control is implemented at the level of this ACL.
  • ID(U3, f1) U3 + sha256(concatenation(U3, f1)), where f1 is said encrypted file and where U3 is the private key of delegate I3.
  • concatenation corresponds to the concatenation function
  • sha256 corresponds to a well-known cryptographic hash function operating on a 32-bit word size. It will be understood that it would be possible to use another hash function here.
  • the delegate I3 transmits the value ID (U3, f1) to the delegator I2.
  • the ID value (U3, f1) is transmitted over a highly secure channel, for example using cryptographic functions. It is then ensured that the value ID(U3, f1 ) remains accessible only to the delegator I2 and to the delegate I3, which are judged to be trusted.
  • the delegator I2 uses the identification value ID(U3, f1 ) specific to the delegate I3, the delegator I2 generates a delegation value Del for the delegate I3 and the file f1.
  • the delegation value Del is calculated by the delegator I2 according to the identification value ID(U3, f1) specific to the delegated device I3, and also according to an identification value ID(U2, f1 ) specific to delegator I2 and associated with this file f1.
  • ID(U2, f1 ) remaining secret, only a delegating device having valid access rights to the file fl can produce delegations.
  • the delegate I3 will later be able to decrypt the file from the delegation value Del and from information on an access entry of the delegating I2.
  • the delegator I2 transmits to the delegate I2 the delegation value Del. It is preferable that the transmission of the delegation value Del be carried out in a secure manner, because this delegation value gives information concerning the identification values for the delegator 12 and the delegate 13.
  • the transmission 1300 to the delegated device I3 preferably takes the form of a signed message containing the delegation value Del.
  • the message can be signed by any cryptographic signature algorithm, for example by DSA signature (for “Digital Signature Algorithm”).
  • the message signature makes it possible to verify the property of non-repudiability.
  • the delegate I3 can verify the integrity of the transmission of the delegation value, and the fact that the delegation does indeed come from the delegator I2. This is particularly important in the event that the I3 delegate needs the identity of the I2 delegator to decrypt the file.
  • a first advantage of the method of FIG. 2 is its simplicity and its speed of calculation.
  • a second advantage is that the delegator I2 and the delegate I3 do not need to be connected to the network at the same time as other users (for example an owner 11 of the file f1 ) and do not need to load files into DB database during the process.
  • the delegate I2 can access (preferably temporarily) the content of the encrypted file f1, thanks to his delegation.
  • the I2 delegate does not have an entry of its own name in the ACL access list.
  • the delegate I2 cannot himself grant any delegation to other users for access to the file f1 which he does not own. It is recalled that, preferably, only the owner of the file f1 can add a recording of said file.
  • Figure 3 illustrates steps in a process for exchanging data between a delegate device (for example I3 or I3'), an access management database DB containing a public access list ACL, and a storage memory M of files, according to an example.
  • the method can be implemented by a processing unit of the delegated device I3, jointly with the base DB.
  • the delegated device uses a delegation value Del for the file f1 previously received from a delegator I2, allowing it to access the content of the file f1 (preferably temporarily).
  • the delegation value Del comes for example from a data exchange process as described above, and as illustrated in Figure 2.
  • the I3 delegate In order to access the contents of the encrypted f1 file, the I3 delegate must obtain the value of the decryption key that locks the contents. This is the symmetric decryption key sk. To obtain said key, the delegate I3 uses the delegation value Del.
  • the delegate I3 obtains from the database DB information depending on an ACL access entry (U2, f1) specific to the delegator I2 for the file f1, by declining an identifier d(l2) of the delegator I2 from the DB database. For example, the I3 delegate directly gets the value of the ACL access entry (U2, f1 ). It is recalled that the access entries are public and that their consultation is not subject to access control.
  • the delegate I3 sends an identifier d(l2) of the delegator I2 to the access management database DB.
  • the delegate I3 directly reads the value of the ACL access entry (U2, f1 ) in the public ACL access list of the DB base.
  • the I3 delegate is then able to calculate the decryption key sk for the file f1 , based on the following three data:
  • delegate 13 does not have an access entry for his own name in the public ACL, for the file f1 .
  • the decryption key sk is preferably a symmetric decryption key.
  • the encryption implemented corresponds for example to an AES (for “Advanced Encryption Standard”) or even 3DES (for “Triple Data Encryption Standard”) algorithm, but any algorithm can be used.
  • the authorization function Aut is chosen so as to verify the following equality:
  • the delegate I3 must necessarily know the delegation value Del in order to decrypt the file, otherwise knowledge of the value of the access entry ACL(U2, fl ) is of no use to it.
  • Two different levels of access to the encrypted file fl are therefore proposed; a first level of users do not need delegation (delegator I2) and a second lower level of users need delegation, because they do not have an access entry in their own name ( delegate I3).
  • the Aut authorization function has been shared between the different organizations of the network before starting the data exchanges. It has for example been distributed to the various servers with the program code enabling the implementation of the data exchange methods.
  • the delegate 13 has the decryption key sk.
  • the delegate 13 obtains the file f1 from a memory in which this file is stored.
  • the file f1 is for example obtained from the memory M.
  • the delegate I3 transmits for example a file request Req f1 to the memory M.
  • the delegate I3 declines the value of the decryption key sk to access the content of the file, preferably by symmetrical decryption.
  • the file f1 is of course not communicated in decrypted form via the N network.
  • the delegate I3 is a calculation server
  • the delegate I3 can implement the necessary calculation sequence(s), then the result of the calculations can be saved on the memory M in the network, possibly directly in the contents of file f1 .
  • the result data of the calculations are communicated to different organizations present on the network (typically to the delegating party I2 and/or to the owner 11). Saving a new encrypted file (Example 1)
  • Figure 4 illustrates successive steps of a process for creating a new protected file f1 intended to be shared via a sharing system such as system 1 , and for generating access rights for this file f1 .
  • the method is implemented by a device that owns the file f1 (for example an owner 11 or 11 '), an access management base DB and a storage memory M.
  • the owner 11 At a step 3100, the owner 11 generates a new unencrypted file f 0 or obtains this file from its internal memory.
  • the data of the file f 1 0 are for example sensitive scientific data that the owner 11 wishes to share with other users in a secure manner, while preserving the confidentiality of the data of the file f 0 .
  • the owner 11 draws a random number r, for example an integer.
  • the owner then transmits the random number r to the access management base DB, at a step 3300.
  • the access management database DB records an access entry for the owner 11 and for the future encrypted file f1, in the public ACL list.
  • the ACL access entry (U1 , f1 ) is taken equal to r.
  • U1 is a private key of owner 11 .
  • the owner 11 calculates in a step 3400 its identification value ID (U1, f1) for the file fl.
  • this identification value is calculated as follows:
  • the owner 11 From its own identification value ID (U1, f1), combined with the value of the new ACL access entry (U1, f1), the owner 11 is able to obtain a decryption key value sk for the fl file.
  • the value of the decryption key sk is constructed so that delegators 12, 12', 12”... can subsequently implement delegations as seen above, without soliciting the owner 11 .
  • a result of the authorization function Aut is a sum of the three variables taken as input by the authorization function.
  • the content of the file is encrypted using the key sk, in order to obtain the encrypted file f1.
  • this file f1 is recorded on the storage memory M.
  • step 3350 can be inverted with steps 3400, 3500, 3600 and 3700 or even implemented in parallel with these latter steps.
  • the encrypted file fl could be obtained by asymmetric encryption from the unencrypted file f°. Encryption is then based on a private decryption key associated with a public decryption key. In the latter case, the Aut authorization function shared between the owner 11 and the various other users allows said users to reconstruct the private decryption key of the file f1.
  • Figure 5 illustrates the steps of a method for exchanging data between an owner device (for example 11 or 11'), a delegating device (for example I2 or 12' or I2”) and an access management base DB, according to an example.
  • One objective of this method is to provide the delegating device I2 with access rights (preferably permanent) to a protected file f1.
  • the method can be implemented by a processing unit of the owner 11, in association with the delegator I2 and the base DB.
  • the file f1 for example comes from a file recording process as described above, illustrated in Figure 4.
  • the access entry ACL (U1, f1) of the owner 11 is, from preferably, obtained as described above in relation to Figure 4.
  • the owner 11 During the process of Figure 5, the owner 11 generates a new public ACL access entry (U2, f1 ) associated with the delegator I2.
  • the delegator I2 can subsequently access the content of the file fl without needing any delegation, and without needing the owner 11 is connected.
  • the delegator I2 transmits to the owner 11 its identification value ID (U2, f1) for the file fl. It is recalled that the ID identification function has preferably been shared between all the organizations of the network before starting the exchanges.
  • the identification function ID has the same properties already mentioned above in relation to Figure 2 and the transmission is carried out in the same way. Especially :
  • the identification value ID(U2, f 1 ) preferably depends on the private key U2 of the delegator and is preferably constructed so that a third party cannot obtain said identification value without knowing the private key U2. Thus, possibly malicious third-party users cannot guess users' private keys, or even accessing the content of the file fl in an illicit manner, by intercepting the exchanges;
  • the ID value (U2, f1) is transmitted at step 4100 over a highly secure channel, for example using cryptographic functions, to ensure that only the owner 11 and the delegator I2 know said value.
  • the owner 11 obtains the value of his own ACL access entry (U1, f1) for the file fl, from the database DB. For example, owner 11 transmits a Req ACL access request and in return retrieves the ACL access entry (U1 , f1 ). This value ACL (U1, f 1 ) may otherwise have been previously recorded by the owner 11 .
  • the owner 11 obtains or recalculates its own identification value ID (U1 , f1 ), then recalculates the decryption key sk for the file fl .
  • ID U1 , f1
  • the owner 11 calculates the appropriate value of the new ACL access entry (U2, f1) to be generated for the delegator I2, here according to the following formula:
  • ACL(U2, f1 ) sk - ID(U2, f1 )
  • this ACL access entry (U2, f1) is integrated into the public ACL access list of the access management DB base.
  • the ACL access list is public; it is not necessary to encrypt the ACL access entry (U2, f1 ), since this entry taken in isolation would not be sufficient for a third-party attacker to calculate the decryption key sk.
  • the I2 delegator After the ACL access entry (U2, f1 ) is added to the public ACL access list, the I2 delegator has elevated permissions for the fl file. This one does not need to communicate with the owner 11 to later decrypt the file f1 .
  • the owner 11 can confirm to the delegator I2 that valid access rights have been integrated into the public ACL list for the delegator I2.
  • an “OK” message can be transmitted to the delegator I2.
  • the delegator I2 can perform an ACL check itself.
  • the delegating device 12 could obtain access rights to the file f1 from another delegating party I2', I2”... knowing the value of the decryption key sk, rather than from the owner 11. Indeed, these delegators I2', I2”... know the value of the decryption key sk, and would therefore be able to generate a valid ACL access entry (U2, f1 ) after having received the ID value (U2, d1 ) from the delegator I2.
  • Figure 6 illustrates steps of a data exchange process between a delegating device (for example I2 or I2′ or I2”), an access management database DB and a storage memory M of files, according to a example.
  • the method can be implemented by a processing unit of the delegating device I2.
  • the delegator I2 uses access rights (preferably permanent) which were previously granted to it for the encrypted file f1, for example at the end of the process described above and illustrated in Figure 5.
  • Access to the content of the file by the delegate I2 is based on the same general principles as the process for accessing the file by the delegate I3 described above, in relation to Figure 3.
  • the I3 delegate To be able to access the content of the encrypted file f1 , the I3 delegate must obtain the value of the decryption key sk which locks the contents of the file f1.
  • the delegator I2 does not need to receive a delegation from any network organization before accessing the content of the encrypted file f1. Indeed, access has already been granted to it by the owner 11.
  • the delegator I2 retrieves its ACL access entry (U2, f1 ) from the public ACL access list.
  • the delegator I2 declines for example its identity using the identifier d(12), and sends an access request Req ACL.
  • the delegator I2 retrieves in return the access entry ACL (U2, f1 ).
  • the delegator I2 obtains its own identification value ID(U2, f1) associated with the file f1 The delegator I2 can calculate this identification value if necessary, if it does not have it in memory.
  • the delegator I2 then calculates the decryption key sk for the file f1 , according to the following two data:
  • decryption key sk Aut(ID(U2, f1 ), ACL(U2, f1 ), 0)
  • the delegator I2 obtains in a very simple way the decryption key sk as a sum of the two above-named data.
  • the decryption key sk can optionally be stored in memory (in a highly secure manner) at a step 5400 for subsequent decryption of the file.
  • the confidentiality of the decryption key sk is preserved, since only the delegator I2 knows its private key U2 allowing it to calculate its own identification value ID(U2, f1 ) associated with the file f1 .
  • the delegator I2 obtains the encrypted file f1 from a memory in which this file is stored, here from the storage memory M.
  • the I3 delegate can transmit a file request Req f1 .
  • the delegator I2 declines the value of the decryption key sk to access the content of the file, preferably by symmetrical decryption.
  • the delegating agent I2 can then access the modified content.
  • a first identification function ID1 is used for the generation of identification values and delegation values
  • a second identification function Distinct ID2 is used for the generation of access entries built into ACL access lists. Treatment methods corresponding to such a protocol are described below.
  • This alternative protocol incorporates the principles described above in relation to a process for delegating access rights to a file f1 encrypted by a delegator I2 ( Figure 2), in relation to a process for accessing a file f1 encrypted by a delegate I3 using the delegation value ( Figure 3), in relation to a method of encryption and recording of a new file f1 by an owner 11 ( Figure A), in relation to a method of generation of access rights by an owner 11 (FIG. 5) and in relation to a process for accessing a file f1 encrypted by a delegator I2 using access rights (FIG. 6).
  • the same numerical references are kept below to designate the steps of these various processes.
  • Example 2 protocol vis-à-vis the Example 1 protocol
  • ID1 and ID2 The main differences are detailed below.
  • step 1100 the value returned by the delegate I3 to the delegator I2 depends on the value ID1 (U3, f1 ) obtained with the first function identification ID1 for file f1 and delegate I3.
  • the first identification function ID1 is calculated as follows:
  • ID1(U3, f1 ) sha256(concatenation(U3, f1,'ID1'))
  • the value returned by the delegate 13 to the delegator 12 is randomized using a random number k obtained by the delegate 13. It is noted that the value of the random number k is not known to the delegator 12.
  • the value returned by delegate 13 to delegator 12 is equal to:
  • the delegating device I2 then does not have access to the isolated value ID1 (U3, f1 ), since only the delegate device I3 knows the value of the random number k.
  • the delegation value Del’ is here equal to a pair.
  • the first element of the pair Del' is equal to the difference between the identification value for the delegator I2 and the value previously returned by the delegate I3: ID1 (U2, f1 ) - [ID1 (U3, f1 ) + k] .
  • the second element of the pair Del' is equal to a value obtained with the second identification function ID2 for the file f1 and the delegator I2: ID2 (U2, f1).
  • ID2 U2, f1
  • the delegator I2 passes a value that later allows the delegate I3 to know which access entry must be required in the ACL(f1) list with the database DB.
  • the second identification function ID2 is calculated as follows:
  • ID2 (U2, f1 ) sha256(concatenation(U2, f1,'ID2'))
  • the values 'ID1' and 'I D2' are separate character strings. In this way, the values provided by the two identification functions ID1 and ID2 are decorrelated and distinct.
  • transmission 1300 to delegate device I3 of delegation Del' takes the form of sending a signed message over a highly secure channel, as in Example 1.
  • the delegate I3 sends an access request Req ACL to the database Access management DB.
  • the delegate I3 associates with its access request Req ACL the second element ID2(U2, f1 ) of the pair Del' previously received.
  • the delegate I3 obtains in return a numerical value ACL(ID2(U2, f1)) of the access entry specific to the delegator I2 for the file f1.
  • the access entry takes the form ACL(ID2(U2, f1 )).
  • the ACL access list remains public.
  • the delegate 13 obtains or recalculates the identification value ID1 (U3, f1) which is specific to him for the file d1. From this value and the random number k, the delegate I3 obtains the value ID1 (U2, f1 ).
  • the random number k is known to the delegate I3. This number has for example been stored securely in a memory of the delegate device I3.
  • Decryption and access to the fl file proceeds as in Example 1 .
  • the owner 11 uses the first identification function ID1 for the calculation of the new decryption key sk associated with the file fl , and uses the second identification function ID2 for calculating the new access entry specific to it.
  • the owner 11 not only calculates a random integer corresponding to the value of its future access entry, but also calculates the value ID2 (U1, f1).
  • the value inserted into the database DB at step 3350 is equal to ACL(ID2(U1, f1)).
  • the delegator I2 communicates to the owner 11 the following value: [ID1 (U2, f1) + k′].
  • owner 11 therefore does not have clear access to the value ID1 (U2, f1 ), unlike in Example 1 where owner 11 receives the value ID(U2, f1 ) at step 4100.
  • a difference from Example 1 is that the owner 11 does not autonomously calculate the new access entry ACL(ID2(U2, f1 )) which must be added to the access list ACL for delegator I2 and file f1.
  • the calculation of said access entry is carried out in a distributed manner between the owner 11 and the delegator I2.
  • the owner 11 transmits to the delegator I2 the following value: sk - [ID1 (U2, f 1 ) + k']
  • the delegator I2 (which is the only one to know the random number k') can recalculate the value [sk - ID1 (U2, fl )].
  • the delegator 12 which, at step 4500, communicates to the base DB the value of the access entry ACL(ID2(U2, f1 )) which will be associated with it in the ACL list for the file f1 :
  • ACL(ID2(U2, f 1 )) sk - ID1 (U2, f 1 )
  • the steps for accessing the encrypted file f1 by the delegator I2 using access rights from the database DB are similar to Example 1.
  • the delegator I2 must submit its identification value I D1 (U2, f 1 ) to the base DB so as to obtain the access entry ACL(ID2(U2, f1 )).
  • the delegator I2 is able to calculate the decryption key sk without being connected to the network simultaneously with the owner 11.
  • a first advantage of the protocol according to Example 2 is that the access entries are anonymized. From the numerical value of a public access entry, for example ACL(ID2(U2,f1 )), present in the access list ACL(f1 ), a third party cannot trace the identity of the device I2. The value of the access entry is obtained from the database DB not by providing an identifier of the device I2, but by supplying the numerical value ID2(U2,f1) obtained with the second identification function ID2.
  • a second advantage of the protocol according to Example 2 is to mask the values of the first identification function ID1 associated with the different devices, with a randomization of the values of the first identification function ID1 during the exchanges.
  • a third-party attacker who would intercept data communications could not have clear access to the values of the first identification function ID1 for the delegator I2 or for the delegate I3. The security of data exchanges is thus reinforced.

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 ensemble de données chiffré, une entrée d'accès propre au dispositif délégant et associée audit ensemble de données étant stockée dans une liste d'accès publique d'une base de gestion d'accès, une clé de déchiffrement dudit ensemble de données étant calculable par le dispositif délégant à l'aide de l'entrée d'accès, le procédé comprenant les étapes suivantes mises en œ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, de sorte que le dispositif délégué peut ultérieurement recevoir la valeur de délégation, obtenir l'entrée d'accès propre au dispositif délégant à l'aide de la valeur de délégation et calculer la clé de déchiffrement dudit ensemble de données.

Description

Gestion de droits d’accès à des données 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 oeuvre l’échange de données, un système de partage d’ensembles de données chiffrés comprenant un tel dispositif, un produit programme d’ordinateur pour la mise en oeuvre de l’échange de données, et des moyens de stockage lisibles par ordinateur pour la mise en oeuvre de l’échange de données.
ETAT DE LA TECHNIQUE
Il est bien connu de l’état de la technique de contrôler l’accès à un fichier informatique contenant des données sensibles, par exemple à l’aide de techniques cryptographiques. On connaît notamment des chiffrements symétriques ou asymétriques où l’accès au fichier nécessite la connaissance d’une clé de déchiffrement.
Dans une solution très simple de régulation de l’accès à un fichier informatique pour des utilisateurs présents sur un réseau (par exemple sur Internet), le fichier informatique est chiffré et accessible publiquement. Grâce au chiffrement, bien que le fichier soit accessible sans contrôle, l’accès aux informations contenues dans le fichier est régulé. Le propriétaire du fichier informatique génère une clé de déchiffrement et doit échanger directement sur le réseau avec chaque utilisateur autorisé à accéder au fichier pour lui transmettre la clé. La publication Design of PriServ, a Privacy Service for DHTs, Jawad, Serrano-Alvarado, Valduriez (2008), Proceedings of the 2008 International Workshop on Privacy and Anonymity in the Information Society, PAIS ’08, Association for Computing Machinery, pp.21 -25 décrit par exemple une solution de gestion des droits d’accès reposant sur des échanges de clés.
Un premier inconvénient de cette approche est qu’une interception des échanges par un attaquant tiers, ou une usurpation de l’identité de l’utilisateur autorisé par un attaquant tiers, remettraient toutes deux en cause la sécurité du chiffrement du fichier. Un deuxième inconvénient important est la nécessité d’une connexion simultanée du propriétaire du fichier et de l’utilisateur devant recevoir les droits d’accès, à chaque nouveau partage.
Pour pallier ces inconvénients, certaines bases de données distribuées de l’état de l’art prennent en charge le problème de gestion des droits d’accès à l’aide de solutions de type « blockchain », c’est-à-dire avec un registre distribué où l’octroi de droits d’accès dépend d’un consensus entre les entités possédant les droits, sans autorité centrale unique de contrôle. Dans une telle solution, chaque maillon de la blockchain contient les informations nécessaires pour garantir que les fichiers échangés soient intègres.
A cet égard, on peut citer par exemple la publication Blockchain- Based, Decentralized Access Control for IPFS, Steichen et al. (2018), 2018 IEEE International Conférence on Internet of Things (iThings), pp.1499-1596. Dans cette publication, les utilisateurs de la blockchain accèdent à une liste de contrôle d’accès dite ACL partagée entre eux via la blockchain, avant d’autoriser éventuellement un nouvel utilisateur à accéder au fichier. Il est proposé de partager directement le fichier au nouvel utilisateur autorisé, dès lors que le consensus est atteint entre les utilisateurs de la blockchain. Le fichier n’est pas chiffré.
Cette solution permet une distribution asynchrone des droits d’accès, sans que les utilisateurs ne soient connectés en même temps. Toutefois, un inconvénient est que la sécurité du contrôle d’accès repose entièrement sur la confiance accordée aux utilisateurs de la blockchain, l’accès au contenu ne nécessitant pas la connaissance d’une clé.
La publication FileTribe : Blockchain- Based Secure File Sharing on IPFS, Sari, Sipos (2019), European Wireless 2019 ; 25th European Wireless Conférence, pp.1 -6, propose de conserver les avantages d’un chiffrement cryptographique des fichiers tout en utilisant un consensus entre les utilisateurs d’une blockchain.
Dans cette solution, les fichiers partagés sont chiffrés à l’aide d’une clé de déchiffrement symétrique. La clé de déchiffrement symétrique est elle- même chiffrée, et peut être déchiffrée par les utilisateurs de la blockchain. Pour fournir des droits d’accès à un nouvel utilisateur, un nouveau chiffrement de la clé de déchiffrement symétrique est réalisé de façon collective. Un avantage est qu’un utilisateur tiers obtenant le fichier sans passer par la blockchain ne peut pas accéder au contenu ; toutefois, une telle solution est très lourde en temps de calcul et en espace de stockage nécessaire, puisque la clé doit être chiffrée à nouveau lors de chaque partage à un nouvel utilisateur autorisé. Compte-tenu de ces difficultés, il est peu pratique de déployer la solution susmentionnée à grande échelle.
De plus, dans la solution susmentionnée, la liste de contrôle d’accès ACL est publique et accessible « en clair » sans contrôle, si bien que n’importe quel utilisateur tiers peut connaître l’identité des utilisateurs autorisés à accéder au fichier par une simple consultation de la liste de contrôle d’accès ACL.
Un autre enjeu non résolu de manière satisfaisante est l’éventuelle révocation de droits d’accès ; les solutions qui s’appuient sur une blockchain ne permettent pas de supprimer des droits d’accès de manière simple. En général, pour empêcher que des utilisateurs précédemment autorisés puissent continuer d’accéder au contenu du fichier, il est nécessaire de générer un nouveau fichier ou une nouvelle clé de déchiffrement du fichier.
D’autres solutions de gestion de droits d’accès à des fichiers ont été proposées, telles qu’une solution de chiffrement de fichier par attributs ou encore une solution de « proxy re-encryption », mais ces solutions sont très complexes au niveau calculatoire. La puissance de calcul et la consommation d’énergie de ces solutions de gestion de droits d’accès les rendent peu pratiques pour un déploiement à grande échelle.
Il ressort de ce qui précède la gestion distribuée de droits d’accès à l’aide d’une blockchain via les solutions connues de l’état de l’art présente des avantages, mais est peu utilisable en pratique.
Un autre inconvénient de l’ensemble des solutions mentionnées ci-avant est de ne pas permettre, pour un utilisateur préalablement autorisé à accéder au fichier, que ledit utilisateur délègue temporairement ses droits d’accès à une autre entité présente sur le réseau - sans que cette dernière entité ne puisse elle-même déléguer les droits d’accès.
Une telle répartition des droits serait par exemple pertinente lorsque des utilisateurs connectés sur un réseau de télécommunications et autorisés à accéder à un fichier donné souhaitent solliciter un serveur de calcul disposant d’une puissance de calcul très importante, ce serveur de calcul étant partagé sur ledit réseau. Il conviendrait alors de permettre au serveur de calcul d’accéder de manière temporaire au fichier, en assurant que cet accès ne permette pas au serveur de calcul de fournir des droits d’accès permanents à d’autres entités.
DESCRIPTION GENERALE DE L'INVENTION
Au regard de ce qui précède, un objectif de l’invention est de fournir une solution de partage d’ensembles de données chiffrés entre plusieurs dispositifs informatiques distants dans laquelle il est aisé de fournir des droits d’accès temporaires à un nouveau dispositif informatique pour un ensemble de données protégé donné - par exemple à un serveur de calcul sollicité de manière ponctuelle. La solution recherchée doit par exemple permettre le partage ciblé de clés de chiffrement symétrique ou asymétrique associées à des ensembles de données protégés.
Un autre enjeu important est de limiter l’espace de stockage nécessaire sur les mémoires respectives des dispositifs informatiques entrant en jeu dans le procédé de partage des ensembles de données chiffrés, notamment vis-à-vis des solutions de l’état de la technique de type « blockchain » qui permettent uniquement d’ajouter des entrées de registre et dans lesquelles l’espace de stockage nécessaire croît au fil du temps. On cherche également à limiter les calculs nécessaires pour alléger et sécuriser les protocoles de partage.
On recherche également une solution de partage de données qui ne nécessite pas que tous les dispositifs informatiques disposant des droits d’accès soient connectés et disponibles en simultané pour générer les nouveaux droits d’accès temporaires.
Enfin, un objectif secondaire de l’invention est de prendre en charge la révocation éventuelle de droits d’accès ; le propriétaire des données est alors en mesure de révoquer des droits d’accès précédemment accordés pour les données, en rendant ces accès obsolètes.
Pour répondre aux besoins mentionnés ci-avant, un premier aspect de l’invention concerne un procédé d’échange de données entre un dispositif délégant et un dispositif délégué pour un accès à un ensemble de données chiffré stocké en mémoire, une entrée d’accès propre au dispositif délégant et associée audit ensemble de données étant stockée dans une liste d’accès publique d’une base de gestion d’accès, une clé de déchiffrement dudit ensemble de données étant calculable par le dispositif délégant à l’aide de l’entrée d’accès, le procédé comprenant les étapes suivantes mises en oeuvre par une unité de traitement du dispositif délégant :
- réception d’une valeur d’identification propre au dispositif délégué et associée audit ensemble de données,
- génération d’une valeur de délégation en fonction de la valeur d’identification propre au dispositif délégué, de sorte que le dispositif délégué peut ultérieurement recevoir la valeur de délégation, obtenir l’entrée d’accès propre au dispositif délégant à l’aide de la valeur de délégation et calculer la clé de déchiffrement dudit ensemble de données.
De façon optionnelle et non limitative, le procédé d’échange de données selon ce premier aspect de l’invention peut présenter en outre les caractéristiques techniques suivantes, prises seules ou dans l’une quelconque des combinaisons possibles :
- la valeur d’identification propre au dispositif délégué dépend d’une clé privée du délégué, ladite valeur d’identification étant construite de sorte qu’un tiers ne peut pas obtenir ladite valeur d’identification du délégué sans connaître la clé privée du délégué.
- la valeur d’identification propre au dispositif délégué, notée ID(U3, f1 ), est obtenue comme suit : ID(U3, f1) = U3 + sha256(concatenation (U3, f1)) où f1 est ledit ensemble de données chiffré, et où U3 est une clé privée du dispositif délégué.
- la valeur de délégation est calculée par l’unité de traitement en fonction de ladite valeur d’identification propre au dispositif délégué, et en fonction d’une valeur d’identification propre au dispositif délégant et associée audit ensemble de données.
- la valeur d’identification propre au dispositif délégant dépend d’une clé privée du délégant, ladite valeur d’identification propre au délégant étant construite de sorte qu’un tiers ne peut pas obtenir ladite valeur d’identification propre au délégant sans connaître la clé privée du délégant.
- la valeur de délégation est égale à une différence entre la valeur d’identification propre au dispositif délégant associée audit ensemble de données et la valeur d’identification propre au dispositif délégué associée audit ensemble de données. - la valeur de délégation est égale à une paire.
- un premier élément de ladite paire dépend d’une différence entre la valeur d’identification propre au dispositif délégant associée audit ensemble de données et la valeur d’identification propre au dispositif délégué associée audit ensemble de données.
- un deuxième élément de ladite paire est égal à une valeur d’identification anonyme pour le délégué propre au dispositif délégant et associée audit ensemble de données.
- le premier élément de ladite paire dépend d’un nombre aléatoire obtenu par le dispositif délégué.
- il comprend la transmission au dispositif délégué d’un message signé contenant la valeur de délégation, par exemple un message signé par signature DSA.
- la clé de déchiffrement dudit ensemble de données comprend une clé de déchiffrement symétrique, par exemple une clé de déchiffrement obtenue par un algorithme AES ou par un algorithme 3DES.
- une valeur de la clé de déchiffrement dudit ensemble de données chiffré dépend d’une fonction Aut vérifiant l’égalité suivante : Aut(ID(U2, f1 ), ACL(U2, f1 ), 0) = Aut(ID(U3, f1 ), ACL(U2, f1 ), Del) où f1 est ledit ensemble de données chiffré, où U2 est une clé privée dudit dispositif délégant, où U3 est une clé privée dudit dispositif délégué, où Del est ladite valeur de délégation, où ID(U2, f1 ) est ladite valeur d’identification propre au dispositif délégant, où ID(U3, f1 ) est ladite valeur d’identification propre au dispositif délégué, et où ACL(U2, fl ) est ladite entrée d’accès propre au dispositif délégant.
- l’entrée d’accès propre au dispositif délégant et associée audit ensemble de données a été préalablement obtenue par un serveur propriétaire en fonction de la clé de déchiffrement dudit ensemble de données, et a été stockée dans la base de gestion d’accès.
- l’obtention de l’entrée d’accès propre au dispositif délégant et associée audit ensemble de données comprend des sous-étapes, mises en oeuvre par le serveur propriétaire, de : obtention d’une valeur d’identification propre au dispositif délégant et associée audit ensemble de données, réception, depuis la base de gestion d’accès, d’une entrée d’accès propre au serveur propriétaire et associée audit ensemble de données, calcul de la clé de déchiffrement, calcul de l’entrée d’accès propre au dispositif délégant associée audit ensemble de données, en fonction de ladite entrée d’accès propre au serveur propriétaire et en fonction de ladite clé de déchiffrement.
- la liste d’accès publique est distribuée sur une infrastructure en nuage.
- la liste d’accès publique est implémentée via une blockchain.
- la liste d’accès publique est distribuée sur un réseau pair à pair intégrant le dispositif délégant et le dispositif délégué.
Selon un deuxième aspect, l’invention concerne un procédé d’échange de données entre un dispositif délégué et une base de gestion d’accès pour un accès à un ensemble de données chiffré stocké en mémoire, une entrée d’accès propre à un dispositif délégant et associée audit ensemble de données étant stockée dans la base de gestion d’accès, ladite entrée d’accès permettant au dispositif délégant d’obtenir une clé de déchiffrement dudit ensemble de données, le dispositif délégué ayant préalablement reçu une valeur de délégation depuis le dispositif délégant, à l’issue d’un procédé d’échange de données entre le délégué et un délégant tel que défini ci-avant, le procédé comprenant les étapes suivantes mises en oeuvre par une unité de traitement du dispositif délégué :
- obtention de l’entrée d’accès propre au dispositif délégant et associée audit ensemble de données,
- calcul de la clé de déchiffrement dudit ensemble de données, en fonction des trois données suivantes : une valeur d’identification propre au dispositif délégué et associée audit ensemble de données, l’entrée d’accès propre au dispositif délégant préalablement obtenue, et la valeur de délégation préalablement reçue depuis le dispositif délégant.
De façon optionnelle et non limitative, le procédé d’échange de données selon ce deuxième aspect de l’invention peut présenter en outre les caractéristiques techniques suivantes, prises seules ou dans l’une quelconque des combinaisons possibles :
- l’obtention de l’entrée d’accès propre au dispositif délégant et associée audit ensemble de données comprend : une transmission d’une donnée associée au dispositif délégant à la base de gestion d’accès, une réception, depuis la base de gestion d’accès, de ladite entrée d’accès propre au dispositif délégant.
- la donnée transmise à la base de gestion d’accès pour obtenir l’entrée d’accès comprend un identifiant du dispositif délégant.
- la donnée transmise à la base de gestion d’accès pour obtenir l’entrée d’accès comprend une valeur d’identification anonymisée, propre au délégant et associée audit ensemble de données.
- le procédé comprend des étapes ultérieures, mises en oeuvre par l’unité de traitement du dispositif délégué, de : obtention de l’ensemble de données chiffré auprès d’une mémoire, et déchiffrement de l’ensemble de données chiffré, à l’aide de la clé préalablement calculée, de préférence par déchiffrement symétrique.
L’invention se rapporte en outre, selon un troisième aspect de l’invention, à un dispositif informatique délégant comprenant une unité de traitement configurée pour mettre en oeuvre un procédé d’échange de données tel que défini ci-avant avec un dispositif délégué.
L’invention concerne également un système de partage d’ensembles de données chiffrés comprenant un tel dispositif informatique et comprenant en outre : un serveur d’accès comprenant une base de gestion d’accès dans laquelle est enregistrée une liste d’accès publique comportant au moins une entrée d’accès, et au moins un dispositif délégué comprenant une unité de traitement configurée pour mettre en oeuvre un procédé d’échange de données tel que défini ci-avant entre le dispositif délégué et une base de gestion d’accès.
Le système de partage d’ensemble de données chiffrés peut présenter, de façon optionnelle et non limitative, les caractéristiques techniques suivantes, prises seules ou dans l’une quelconque des combinaisons possibles :
- le dispositif délégant comprend un serveur utilisateur.
- le dispositif délégué comprend un serveur de calcul. - le système de partage d’ensemble de données chiffrés comprend en outre un serveur propriétaire de donnée configuré pour calculer des entrées d’accès propres à des dispositifs délégants associées à au moins un ensemble de données chiffré, et configuré pour partager lesdites entrées d’accès avec le serveur d’accès.
Un quatrième aspect de l’invention se rapporte à un produit programme d’ordinateur comprenant des instructions de code qui, lorsque lesdites instructions de code sont exécutées par une unité de traitement, conduisent ladite unité de traitement à mettre en oeuvre un procédé d’échange de données tel que défini ci-avant.
Un cinquième aspect de l’invention se rapporte à des moyens de stockage lisibles par ordinateur sur lesquels sont enregistrées des instructions de code qui, lorsque lesdites instructions de code sont exécutées par une unité de traitement, conduisent ladite unité de traitement à mettre en oeuvre un procédé d’échange de données tel que défini ci-avant.
DESCRIPTION GENERALE DES FIGURES
D’autres caractéristiques, buts et avantages de l’invention ressortiront de la description qui suit, qui est donnée à titre illustratif et non limitatif, et qui doit être lue en regard des figures annexées parmi lesquelles :
La Figure 1 est un schéma représentatif d’un ensemble de partage de données selon un exemple de réalisation, comportant notamment une pluralité de dispositifs délégants, une pluralité de dispositifs délégués et une base de gestion d’accès.
La Figure 2 représente les étapes d’un exemple de procédé de délégation de droits d’accès à un fichier chiffré, d’un dispositif délégant vers un dispositif délégué.
La Figure 3 représente les étapes d’un exemple de procédé d’accès à un fichier chiffré par un dispositif délégué ayant préalablement reçu une délégation, de préférence une délégation temporaire.
La Figure 4 représente les étapes d’un exemple de procédé de chiffrement et d’enregistrement d’un fichier par un dispositif propriétaire, permettant une éventuelle délégation ultérieure de droits d’accès au fichier chiffré enregistré.
La Figure 5 représente les étapes d’un exemple de procédé de génération de droits d’accès, de préférence permanents, d’un dispositif propriétaire vers un dispositif délégant. La Figure 6 représente les étapes d’un exemple de procédé d’accès à un fichier chiffré par un dispositif délégant pour lequel des droits d’accès, de préférence permanents, ont été préalablement générés par un dispositif propriétaire.
DESCRIPTION DETAILLEE DE MODES DE REALISATION PARTICULIERS DE L'INVENTION
Dans toute la description ci-après, les différentes valeurs cryptographiques utilisées pour la gestion des accès (clé de déchiffrement, valeur d’identification, valeur de délégation, etc.) sont propres à un unique ensemble de données. On comprendra toutefois que lesdites valeurs utilisées pour gérer les droits d’accès pourraient également être communes à plusieurs ensembles de données déterminés par le ou les propriétaires respectifs desdits ensembles de données. Notamment, la clé de déchiffrement d’un ensemble de donnée pourrait également être valide pour d’autres ensembles de données déterminés.
Sur l’ensemble des figures annexées et tout au long de la description ci-après, les éléments similaires portent des références alphanumériques identiques.
Dans ce qui suit, l’exemple est pris d’ensembles de données chiffrés stockés en mémoire sous la forme de fichiers. L’invention n’est toutefois pas limitée à ce cas de figure mais s’étend également à des ensembles de données stockés en mode bloc (chaque ensemble constitue ainsi un bloc de données, résultant par exemple mais non nécessairement du découpage d’un fichier en plusieurs blocs) ou en mode objet.
Figure imgf000012_0001
La description ci-après concerne la gestion de droits d’accès à des fichiers chiffrés par des entités d’un réseau. On considère que les entités ont préalablement partagé ensemble un protocole de gestion des droits.
La Figure 1 représente schématiquement un système 1 de partage de fichiers entre des dispositifs informatiques de plusieurs organisations Org1 , Org2, Org3, ..., connectés sur un même réseau N, de préférence un réseau de télécommunications à distance. Le réseau N est typiquement un réseau Internet, Intranet, téléphonique 3G, 4G, 5G, DECT, Bluetooth, etc.
Dans le présent exemple, les organisations Org1 , Org2, Org3 sont des organisations de gestion de données géophysiques et/ou environnementales. On entend par « données géophysiques » des données relatives aux caractéristiques physiques de la Terre, typiquement issues de mesures. Il peut s’agir de données géologiques et/ou sismiques et/ou gravimétriques et/ou atmosphériques et/ou spatiales, etc. On entend par « données environnementales » des données ayant trait à l'environnement biologique et humain d’une zone, par exemple des données biologiques et/ou sonores et/ou chimiques et/ou hydrologiques et/ou énergétiques et/ou relatives au traitement de déchets. Ces données sont typiquement des données sensibles mises sélectivement à disposition des organisations.
Les organisations Org1 , Org2, Org3 sont par exemples distantes les unes des autres, et peuvent appartenir à des territoires différents.
Chacune des organisations Org1 , Org2, Org3 est par exemple une collectivité territoriale et/ou une société privée intervenant pour la collecte ou le traitement de données et/ou une association intervenant pour la collecte ou le traitement de données et/ou une organisation propriétaire de serveurs de stockage et/ou de calcul.
On considère ici que chacune des organisations Org1 , Org2, Org3 est indépendante. Les organisations souhaitent par exemple mettre en commun sélectivement une partie de leur matériel et de leurs données, afin que chacune d’entre elles puisse s’appuyer sur au moins une partie des ressources et des données des autres organisations.
En outre, ici, l’organisation Org1 possède un serveur de calcul I3 et l’organisation Org2 possède un serveur de calcul I3’. Par « serveur de calcul » on entend un serveur possédant une puissance de calcul très importante, typiquement plus importante que chacun des dispositifs 11 , 11 ’, I2, I2’, I2”, .... On souhaite pouvoir mettre sélectivement l’un et/ou l’autre de ces serveurs I3 et I3’ à disposition des autres organisations du réseau afin d’exécuter des traitements sur des données géophysiques et/ou environnementales.
Cependant, l’ensemble de la description ci-après, et notamment les descriptions des différents procédés illustrés par les Figures 2 à 6, ne sont pas limitées au cas de données géophysiques et/ou environnementales. Ces procédés peuvent avantageusement être utilisés quel que soit le type de contenu des fichiers ou le type d’organisations Org1 , Org2, Org3, ... ou également pour deux organisations. Une application à des données géophysiques et/ou environnementales est avantageuse, car les traitements calculatoires desdites données peuvent nécessiter une puissance de calcul élevée. Il convient que les collectivités territoriales puissent confier temporairement certains traitements à des serveurs de calcul, sans pour autant remettre en cause l’intégrité et la confidentialité des données contenues dans les fichiers.
De retour à la Figure 1 , le système 1 comprend au moins un serveur S d’accès, stockant une base DB de gestion d’accès. Le serveur d’accès S peut être contenu dans un unique dispositif informatique, ou peut être réparti sur plusieurs dispositifs (éventuellement localisés à distance les uns des autres et présents sur des sites différents), par exemple en utilisant des tables de hachage et/ou une blockchain.
Le serveur S comprend une unité de traitement (non représentée). Dans cet exemple, le serveur S stocke les différentes listes d’accès ACL. Une mémoire de la base DB de gestion d’accès (ou, en alternative, une mémoire distante avec laquelle la base DB peut communiquer) comprend au moins une liste d’accès ACL(f1 ) avec au moins une entrée d’accès pour un fichier f1 chiffré. Dans le présent exemple, la base DB de gestion d’accès comprend également une liste d’accès ACL(f2) avec au moins une entrée d’accès pour un fichier f2 chiffré. On comprendra que des entrées d’accès aux fichiers f1 et f2 peuvent être octroyées à des utilisateurs différents.
De manière avantageuse, tous les noeuds du système 1 (c’est-à-dire ici notamment les dispositifs 11 , 11 ’, I2, I2’, I2”, ...) peuvent accéder à chacun des fichiers chiffrés f1 , f2, ... sans contrôle, par exemple en passant par un système de stockage distribué gérant les mémoires M, M’, M”. Les fichiers chiffrés fl , f2, ... sont alors disponibles publiquement. L’accès aux informations contenues dans le fichier est régulé par la présence des clés de chiffrement, mais l’accès au fichier lui-même n’est de préférence pas régulé.
Une liste d’accès, par exemple la liste ACL(f1 ), comprend typiquement des paires de correspondance. Chaque paire associe un identifiant d’un dispositif (par exemple d(l2)) et une valeur numérique (par exemple ACL (U2, f1 )) prévue pour permettre audit dispositif d’accéder au contenu du fichier f1 .
Par exemple, l’entrée d’accès ACL (U2, f1 ) permet au dispositif I2 d’utiliser sa clé privée U2 pour calculer la valeur d’une clé de déchiffrement du fichier f1 .
Le contenu du fichier f1 comprend par exemple des données collectées issues du capteur Sa et/ou de l’un quelconque des autres capteurs.
La liste d’accès ACL est une liste publique. On entend par « publique » que la liste d’accès ACL est facilement accessible par l’un quelconque des dispositifs des organisations Org1 , Org2, Org3, ... ainsi que par des dispositifs appartenant à des utilisateurs tiers. De préférence, aucune mesure spécifique de contrôle d’accès (reposant par exemple sur des clés cryptographiques et/ou sur un consensus par blockchain, etc.) n’est implémentée pour protéger le contenu de la liste d’accès ACL vis-à-vis d’utilisateurs tiers. La liste d’accès ACL est facilement consultable, au moins en lecture, par chacun des utilisateurs susmentionnés.
Les clés privées U1 , U2, U1 ’, U2’, ..., appartenant respectivement aux dispositifs 11 , I2, 11 ’, I2’, ..., sont, quant à elles, stockées de façon très sécurisée. Il s’agit par exemple de valeurs numériques propres à chaque dispositif. On ne suppose qu’aucun des dispositifs ne partage sa clé privée, ni sur le réseau N, ni avec l’un quelconque des autres dispositifs.
Ici, le système 1 comprend en outre :
• pour l’organisation Org1 , un serveur propriétaire 11 et un serveur utilisateur I2. Le serveur propriétaire 11 est configuré pour créer des fichiers chiffrés et pour calculer des entrées d’accès propres à lui-même et/ou au serveur utilisateur I2 et/ou à d’autres dispositifs présents sur le réseau N pour ces fichiers ; l’organisation Org1 comprend en outre, dans le présent exemple, un capteur Sa prévu pour collecter des données géophysiques et/ou environnementales. Le capteur Sa peut ici échanger des données avec le serveur 11 .
• pour l’organisation Org2, un serveur propriétaire 11 ’ et un serveur utilisateur I2’. Le serveur propriétaire 11 ’ est configuré pour créer des fichiers chiffrés et pour calculer des entrées d’accès propres à lui-même et/ou au serveur utilisateur I2’ et/ou à d’autres dispositifs présents sur le réseau N pour ces fichiers ; l’organisation Org2 comprend en outre, dans le présent exemple, deux capteurs Sb et Sc prévu pour collecter des données géophysiques et/ou environnementales. Les deux capteurs Sb et Sc peuvent ici échanger des données avec le serveur 11 ’.
• pour l’organisation Org3, un serveur utilisateur I2”. L’organisation Org3 ne possède pas ici de puissance de calcul importante adaptée pour effectuer des traitements lourds sur des données géophysiques et/ou environnementales.
Le système 1 comprend en outre une mémoire M de stockage. La mémoire M peut stocker les listes d’accès ACL. Ici, la mémoire M appartient à l’organisation Org1.
En alternative, la mémoire M pourrait être intégrée au serveur d’accès S et/ou intégrée à l’un quelconque des dispositifs de l’une des organisations Org1 , Org2, Org3, ..., ou distante de chacun de ces dispositifs. Par ailleurs, l’organisation Org2 possède ici une mémoire M’ de stockage, et l’organisation Org3 possède ici une mémoire M” de stockage.
De préférence, lorsque plusieurs mémoires (ici M, M’, M”) sont présentes, un espace de nommage commun est utilisé. Les mémoires M, M’, M” appartiennent à un système de stockage distribué, par exemple réalisé à l’aide d’un réseau de recouvrement. Ainsi, quand un utilisateur accède à une entrée de la liste d’accès ACL, il n’est pas nécessaire que l’utilisateur sache à l’avance dans quelle mémoire du système 1 ladite entrée de la liste d’accès est localisée.
De manière préférée, chaque dispositif 11 , 11 ’, I2, I2’, ... sollicite la mémoire qui est disponible dans son serveur local ; ainsi, dans l’exemple illustré sur la Figure 1 , le dispositif 11 peut interroger la mémoire M et le dispositif 11 ’ peut interroger la mémoire M’. Dans la mesure où les mémoires M, M’, et M” appartiennent à un même système de stockage distribué, les fichiers stockés dans les autres mémoires sont également accessibles.
De manière préférée, les enregistrements sur une mémoire ne sont pas modifiables ultérieurement. Cette dernière propriété est par exemple assurée comme service par la solution de stockage distribué utilisée.
Chaque fichier chiffré est enregistré soit sur l’une quelconque des mémoires M, M’, M”, ..., soit sur une mémoire du serveur S ou sur une mémoire distante. Dans le présent exemple, le fichier f1 est stocké sur la mémoire M de l’organisation Org1 et le fichier f2 est stocké sur la mémoire M’ de l’organisation Org2. D’autres fichiers, de préférence chiffrés ou éventuellement non chiffrés, peuvent être enregistrés en mémoire.
Chacun des dispositifs 11 , 11 ’, I2, I2’, I2”, I3, I3’ comprend des moyens de traitement comme par exemple une unité de traitement, non représentée sur la Figure 1 .
Chacun de ces moyens de traitement peut comprendre en mémoire un ou plusieurs produits programmes d’ordinateur comprenant des instructions de code pour la mise en oeuvre des procédés décrits ci-après, et/ou peut lire un ou plusieurs moyens de stockage lisibles par ordinateur sur lesquels sont enregistrées des instructions de code pour la mise en oeuvre des procédés décrits ci-après.
Les organisations Org1 , Org2, Org3 souhaitent pouvoir solliciter les serveurs de calcul I3, I3’ afin de disposer de leur puissance de calcul pour effectuer des traitements sur les données géophysiques et/ou environnementales auxquelles l’un quelconque des dispositifs 11 , 11 ’, I2, I2’, I2” a accès selon les listes d’accès ACL. Pour ce faire, on souhaite attribuer un accès (typiquement uniquement en lecture) à l’un des fichiers chiffrés f1 et/ou f2 pour l’un des serveurs de calcul I3 et/ou I3’, de manière sélective et préférentiellement temporaire.
De préférence, les données écrites par un utilisateur donné dans un fichier ne peuvent plus être modifiées, y compris de préférence par le propriétaire dudit fichier. Une telle interdiction de modifier des données de fichier après leur création est par exemple fournie, sous forme de service, par le système de stockage distribué utilisé pour les mémoires M, M’, M”.
Les procédés ci-après permettent de réaliser deux niveaux d’accès aux fichiers, comme il sera détaillé ci-après. On considère les serveurs I2, I2’ et I2” comme délégants ; ils peuvent avoir des entrées d’accès à leur nom dans les listes d’accès ACL. Les serveurs I3 et I3’ sont quant à eux délégués ; ils peuvent recevoir une délégation venant d’un délégant.
Figure imgf000017_0001
On a représenté sur la Figure 2 des étapes successives d’un procédé d’échange de données entre un dispositif délégant (par exemple I2 ou l2’ou I2”) et un dispositif délégué (par exemple I3 ou I3’) selon un exemple. Un objectif de ce procédé est de fournir une valeur de délégation Del au dispositif délégué I3, pour permettre audit délégué I3 d’accéder (préférentiellement de manière temporaire) à un fichier f1 chiffré pour lequel le dispositif délégant I2 détient des droits d’accès. Ce procédé peut être mis en oeuvre par une unité de traitement du dispositif délégant I2, conjointement avec le délégué I3.
Le fichier f1 chiffré est typiquement un fichier en lecture seule. En alternative, le contenu du fichier f1 peut être modifiable en écriture une fois que l’accès au fichier f1 a été permis.
Typiquement, le dispositif délégué I3 est un serveur de calcul partagé sur le réseau N, sollicité de manière temporaire pour prêter sa puissance de calcul.
Pour que le délégant I2 génère et transmette une délégation au délégué I3, il convient que le délégant I2 obtienne une valeur de fonction d’identification propre au délégué I3 pour le fichier fl . En effet, le calcul de la délégation Del ultérieurement attribuée au délégué 13 dépend de ladite valeur d’identification. De manière préférentielle, la fonction d’identification ID a été partagée entre les différentes organisations du réseau avant de débuter les échanges de données. Par exemple, la fonction d’identification ID a été préalablement spécifiée dans le code du programme permettant la mise en oeuvre des différents procédés d’échanges de données, et distribuée avec ledit programme.
Au cours de l’étape 1100, le délégué I3 reçoit de manière optionnelle une requête d’identification Req ID de la part du délégant I2. La requête d’identification Req ID prend de préférence la forme d’un message adressé par le délégant I2 au délégué I3. Ensuite, le délégué I3 obtient ou recalcule une valeur ID(U3, f1 ) qui lui est propre pour la fonction d’identification ID, à partir d’une identité du fichier f1 et à partir de sa clé privée U3.
La valeur d’identification ID(U3, f1 ) dépend de la clé privée U3 du délégué I3. Cette valeur d’identification est construite de telle sorte qu’un tiers ne peut pas obtenir cette valeur en connaissant simplement une identité du fichier fl , sans connaître la clé privée U3. La valeur d’identification ID(U3, f1 ) dépend ici également de l’identité du fichier f1 ; autrement dit, les valeurs d’identification du délégué I3 diffèrent pour chaque fichier.
De préférence, les résultats produits par la fonction d’identification ID semblent aléatoires du point de vue d’un tiers qui ne connaîtrait pas la clé privée utilisée, mais ces résultats sont déterministes pour l’utilisateur ayant connaissance de la clé privée utilisée.
La fonction d’identification ID présente de préférence les trois propriétés suivantes :
• Le résultat ID(U3, f1 ) ne peut être calculé que par le délégué I3 détenant sa clé U3 ;
• A partir de la seule connaissance du résultat ID(U3, f1 ), il est extrêmement difficile pour un tiers de remonter à la valeur de la clé privée U3 ;
• Le résultat ID(U3, f1 ) n’est pas rejouable par un tiers à partir d’un autre fichier chiffré, par exemple à partir du fichier f2 pour lequel le tiers connaîtrait accidentellement la valeur ID(U3, f2).
Ainsi, la fonction d’identification ID permet aux utilisateurs du système 1 d’échanger des données en vue de l’attribution et/ou de l’utilisation de droits d’accès à des fichiers, sans que des utilisateurs tiers éventuellement malveillants ne puissent deviner les clés privées des utilisateurs, ou encore accéder de façon illicite au contenu de fichiers chiffrés. La solution de gestion de droits d’accès proposée ici présente donc un très haut niveau de sécurité, bien que la liste ACL de la base de gestion d’accès DB soit publique et qu’aucun contrôle d’accès ne soit mis en oeuvre au niveau de cette liste ACL.
Dans le présent exemple (Exemple 1 ), la valeur ID(U3, f1) de la fonction d’identification ID est obtenue comme suit :
ID(U3, f1) = U3 + sha256(concatenation(U3, f1)), où f1 est ledit fichier chiffré et où U3 est la clé privée du délégué I3. « concaténation » correspond à la fonction concaténation, et « sha256 » correspond à une fonction de hachage cryptographique connue opérant sur une taille de mots de 32 bits. On comprendra qu’il serait possible d’employer une autre fonction de hachage ici.
A l’étape 1100, le délégué I3 transmet la valeur ID (U3, f1 ) au délégant I2. De manière préférentielle, la valeur ID (U3, f1 ) est transmise sur un canal hautement sécurisé, par exemple à l’aide de fonctions cryptographiques. On assure alors que la valeur ID(U3, f1 ) demeure accessible uniquement au délégant I2 et au délégué I3, qui sont jugés de confiance.
A une étape 1200, à l’aide de la valeur d’identification ID(U3, f1 ) propre au délégué I3, le délégant I2 génère une valeur de délégation Del pour le délégué I3 et le fichier f1.
De préférence, la valeur de délégation Del est calculée par le délégant I2 en fonction de la valeur d’identification ID(U3, f1 ) propre au dispositif délégué I3, et également en fonction d’une valeur d’identification ID(U2, f1 ) propre au délégant I2 et associée à ce fichier f1. Ainsi, la valeur d’identification ID(U2, f1 ) demeurant secrète, seul un dispositif délégant disposant de droits d’accès valides au fichier fl peut produire des délégations.
Dans le présent exemple (Exemple 1 ), la valeur de délégation Del est égale à la différence des deux valeurs d’identification : Del = ID(U2, f 1 ) - ID(U3, f1).
Comme il sera décrit ci-après, par construction de la clé de déchiffrement sk, le délégué I3 sera ultérieurement en mesure de déchiffrer le fichier à partir de la valeur de délégation Del et à partir d’une information sur une entrée d’accès du délégant I2.
Enfin, à une étape 1300, le délégant I2 transmet au délégué I2 la valeur de délégation Del. Il est préférable que la transmission de la valeur de délégation Del soit réalisée de façon sécurisée, car cette valeur de délégation donne une information concernant les valeurs d’identification pour le délégant 12 et le délégué 13.
Ainsi, la transmission 1300 au dispositif délégué I3 prend préférentiellement la forme d’un message signé contenant la valeur de délégation Del. Le message peut être signé par tout algorithme de signature cryptographique, par exemple par signature DSA (pour « Digital Signature Algorithm »).
La signature de message permet de vérifier la propriété de non-répudiabilité. En outre, grâce à la signature de message, le délégué I3 peut vérifier l’intégrité de la transmission de la valeur de délégation, et le fait que la délégation provienne bien du délégant I2. Cela est notamment important dans le cas où le délégué I3 aurait besoin de l’identité du délégant I2 pour déchiffrer le fichier.
Un premier avantage du procédé de la Figure 2 est sa simplicité et sa rapidité de calcul. Un deuxième avantage est que le délégant I2 et le délégué I3 n’ont pas besoin d’être connectés au réseau simultanément à d’autres utilisateurs (par exemple un propriétaire 11 du fichier f1 ) et n’ont pas besoin de charger des fichiers dans la base DB pendant le procédé.
A l’issue du procédé de la Figure 2, le délégué I2 peut accéder (préférentiellement temporairement) au contenu du fichier f1 chiffré, grâce à sa délégation. Toutefois, le délégué I2 ne dispose pas d’une entrée à son propre nom dans la liste d’accès ACL. De préférence, le délégué I2 ne peut pas lui-même accorder une quelconque délégation à d’autres utilisateurs pour accès au fichier f1 dont il n’est pas propriétaire. On rappelle que, de préférence, seul le propriétaire du fichier f1 peut ajouter un enregistrement dudit fichier.
Ces dernières propriétés peuvent être réalisées notamment par une liste d’accès ACL stockée sous forme de blockchain, où les ajouts à la blockchain seraient gérés sous forme de « smart contract ».
On comprendra que le procédé de la Figure 2 peut être répété par le délégant I2 pour autant d’itérations que de délégués différents requérant des délégations pour le fichier f 1 , et éventuellement pour d’autres fichiers disponibles en mémoire. * Accès à un fichier chiffré à l’aide de droits d’accès temporaires (Exemple 1)
La Figure 3 illustre des étapes d’un procédé d’échange de données entre un dispositif délégué (par exemple I3 ou I3’), une base de gestion d’accès DB contenant une liste d’accès ACL publique, et une mémoire de stockage M de fichiers, selon un exemple. Le procédé peut être mis en oeuvre par une unité de traitement du dispositif délégué I3, conjointement avec la base DB. Le dispositif délégué utilise une valeur de délégation Del pour le fichier f1 préalablement été reçue depuis un délégant I2, lui permettant d’accéder au contenu du fichier f1 (préférentiellement de manière temporaire).
La valeur de délégation Del est par exemple issue d’un procédé d’échange de données tel que décrit ci-avant, et tel qu’illustré sur la Figure 2.
Pour pouvoir accéder au contenu du fichier f1 chiffré, le délégué I3 doit obtenir la valeur de la clé de déchiffrement qui verrouille le contenu. Il s’agit ici de la clé de déchiffrement symétrique sk. Pour obtenir ladite clé, le délégué I3 utilise la valeur de délégation Del.
Dans un premier temps, le délégué I3 obtient auprès de la base DB une information dépendant d’une entrée d’accès ACL (U2, f1 ) propre au délégant I2 pour le fichier f1 , en déclinant un identifiant d(l2) du délégant I2 auprès de la base DB. Par exemple, le délégué I3 obtient directement la valeur de l’entrée d’accès ACL (U2, f1 ). On rappelle que les entrées d’accès sont publiques et que leur consultation ne fait pas l’objet d’un contrôle d’accès.
Ici, à une étape 2100, le délégué I3 envoie un identifiant d(l2) du délégant I2 à la base DB de gestion d’accès.
Puis à une étape 2200, le délégué I3 lit directement la valeur de l’entrée d’accès ACL (U2, f1 ) dans la liste d’accès ACL publique de la base DB.
Le délégué I3 est ensuite en mesure de calculer la clé de déchiffrement sk pour le fichier f1 , en fonction des trois données suivantes :
• la valeur d’identification ID(U3, f 1 ) propre au dispositif délégué I3 et associée au fichier fl, que le délégué 13 peut calculer le cas échéant s’il ne la possède pas en mémoire ;
• l’entrée d’accès ACL(U2, f 1 ) lue dans la base DB de gestion d’accès ;
• la valeur de délégation Del préalablement générée par le délégant I3 et reçue par le délégué I3 (directement depuis le délégant ou indirectement par l’intermédiaire d’un dispositif tiers comme un tiers de confiance) , qui peut avoir été enregistrée en mémoire au préalable.
On rappelle que le délégué 13 ne possède pas d’entrée d’accès à son propre nom dans la liste ACL publique, pour le fichier f1 .
La clé de déchiffrement sk est de préférence une clé de déchiffrement symétrique. Le chiffrement mis en oeuvre correspond par exemple à un algorithme AES (pour « Advanced Encryption Standard ») ou encore 3DES (pour « Triple Data Encryption Standard ») mais tout algorithme peut être utilisé. La clé de déchiffrement sk est ici construite comme suit : sk = Aut(ID(U3, f1 ), ACL(U2, f1 ), Del) [= Aut(ID(U2, f1), ACL(U2, f1), O)] où f1 est le fichier chiffré, où U2 est la clé privée du dispositif délégant I2, où U3 est la clé privée du dispositif délégué I3, où Del est la valeur de délégation préalablement reçue par le délégué I3, où ID(U2, f1 ) est la valeur d’identification propre au dispositif délégant I2, où ID(U3, f1 ) est la valeur d’identification propre au dispositif délégué I3, et où ACL(U2, fl ) est l’entrée d’accès propre au dispositif délégant I2.
La fonction d’autorisation Aut est choisie de sorte à vérifier l’égalité suivante :
Aut(ID(U3, f1 ), ACL(U2, fl ), Del) = Aut(ID(U2, fl ), ACL(U2, fl ), 0)
Dans un exemple simple, on utilise comme résultat de la fonction Aut une somme des trois variables prises en entrée. En effet, si l’égalité Del = ID(U2, f1 ) - ID(U3, f1 ) est vérifiée comme dans l’exemple ci-avant (Exemple 1 ), alors l’égalité suivante est également vérifiée :
I D(U 3 , fl ) + ACL (U2, fl ) + Del = ID (U2, fl ) + ACL (U2, fl )
Il ressort clairement que le délégué I3 doit nécessairement connaître la valeur de délégation Del pour déchiffrer le fichier, faute de quoi la connaissance de la valeur de l’entrée d’accès ACL(U2, fl ) ne lui est pas utile. On propose donc deux niveaux différents d’accès au fichier fl chiffré ; un premier niveau d’utilisateurs n’ont pas besoin de délégation (délégant I2) et un deuxième niveau plus faible d’utilisateurs ont besoin d’une délégation, car ils n’ont pas d’entrée d’accès en leur nom propre (délégué I3). De préférence, la fonction d’autorisation Aut a été partagée entre les différentes organisations du réseau avant de débuter les échanges de données. Elle a par exemple été distribuée aux différents serveurs avec le code du programme permettant la mise en oeuvre des procédés d’échanges de données.
A l’issue de l’étape 2300, le délégué 13 dispose de la clé de déchiffrement sk.
A une étape 2400, pouvant être mise en oeuvre immédiatement après l’étape 2300 ou plus tardivement, le délégué 13 obtient le fichier f1 auprès d’une mémoire dans laquelle ce fichier est stocké. Le fichier f1 est par exemple obtenu depuis la mémoire M. A cet effet, le délégué I3 transmet par exemple une requête de fichier Req f1 à la mémoire M.
Enfin, à une étape 2500, le délégué I3 décline la valeur de la clé de déchiffrement sk pour accéder au contenu du fichier, de préférence par déchiffrement symétrique. Le fichier f1 n’est bien entendu pas communiqué sous forme déchiffrée via le réseau N.
Dans le cas où le délégué I3 est un serveur de calcul, on comprendra que le délégué I3 peut mettre en oeuvre la ou les séquences de calcul nécessaires, puis le résultat des calculs peut être sauvegardé sur la mémoire M en réseau, éventuellement directement dans le contenu du fichier f1 . Alternativement, les données de résultat des calculs sont communiquées à différentes organisations présentes sur le réseau (typiquement au délégant I2 et/ou au propriétaire 11 ). Enregistrement d’un nouveau fichier chiffré (Exemple 1)
La Figure 4 illustre des étapes successives d’un procédé de création d’un nouveau fichier f1 protégé destiné à être partagé via un système de partage tel que le système 1 , et de génération de droits d’accès pour ce fichier f1 . Le procédé est mis en oeuvre par un dispositif propriétaire du fichier f1 (par exemple un propriétaire 11 ou 11 ’), une base de gestion d’accès DB et une mémoire de stockage M.
A une étape 3100, le propriétaire 11 génère un nouveau fichier f0 non chiffré ou obtient ce fichier depuis sa mémoire interne. Comme indiqué ci-avant, les données du fichier fl 0 sont par exemple des données scientifiques sensibles que le propriétaire 11 souhaite partager avec d’autres utilisateurs de manière sécurisée, tout en préservant la confidentialité des données du fichier f0. A une étape 3200, en vue de générer une entrée d’accès pour le futur fichier f1 chiffré, le propriétaire 11 tire un nombre aléatoire r, par exemple un entier.
Le propriétaire transmet ensuite le nombre aléatoire r à la base DB de gestion d’accès, à une étape 3300.
Ensuite, à une étape 3350, la base DB de gestion d’accès enregistre une entrée d’accès pour le propriétaire 11 et pour le futur fichier f1 chiffré, dans la liste ACL publique. Par exemple, l’entrée d’accès ACL (U1 , f1 ) est prise égale à r. U1 est une clé privée du propriétaire 11 .
Le propriétaire 11 , quant à lui, calcule à une étape 3400 sa valeur d’identification ID (U1 , f1 ) pour le fichier fl . Dans le présent exemple (Exemple 1 ), cette valeur d’identification est calculée comme suit :
ID(U1, f 1 ) = U 1 + sha256(concatenation(U1, f1 )),
A partir de sa propre valeur d’identification ID (U1 , f1 ), combinée à la valeur de la nouvelle entrée d’accès ACL (U1 , f1 ), le propriétaire 11 est en mesure d’obtenir une valeur de clé de déchiffrement sk pour le fichier fl . La valeur de la clé de déchiffrement sk est construite de sorte que des délégants 12, 12’, 12”... puissent ultérieurement mettre en oeuvre des délégations comme vu ci-avant, sans solliciter le propriétaire 11 .
Ainsi, à une étape 3500, le propriétaire 11 calcule une valeur de la clé de déchiffrement sk à l’aide de la fonction d’autorisation Aut, par exemple selon la formule suivante : sk = Aut(ID(U1, fl ), ACL(U1, fl ), 0))
On rappelle que, dans un exemple simple, un résultat de la fonction d’autorisation Aut est une somme des trois variables prises en entrée par la fonction d’autorisation.
A une étape 3600, le contenu du fichier est chiffré à l’aide de la clé sk, afin d’obtenir le fichier f1 chiffré.
Enfin, à une étape 3700, ce fichier f1 est enregistré sur la mémoire M de stockage.
On comprendra que l’étape 3350 peut être intervertie avec les étapes 3400, 3500, 3600 et 3700 ou encore mise en oeuvre en parallèle de ces dernières étapes.
En alternative, le fichier fl chiffré pourrait être obtenu par chiffrement asymétrique à partir du fichier f° non chiffré. Le chiffrement repose alors sur une clé privée de déchiffrement associée à une clé publique de déchiffrement. Dans ce dernier cas, la fonction d’autorisation Aut partagée entre le propriétaire 11 et les différents autres utilisateurs permet auxdits utilisateurs de reconstruire la clé privée de déchiffrement du fichier f1.
*Génération de droits d’accès permanents à un fichier chiffré pour un délégant (Exemple 1)
La Figure 5 illustre des étapes d’un procédé d’échange de données entre un dispositif propriétaire (par exemple 11 ou 11 ’), un dispositif délégant (par exemple I2 ou l2’ou I2”) et une base de gestion d’accès DB, selon un exemple. Un objectif de ce procédé est de fournir au dispositif délégant I2 des droits d’accès (préférentiellement permanents) à un fichier f1 protégé. Le procédé peut être mis en oeuvre par une unité de traitement du propriétaire 11 , en association avec le délégant I2 et la base DB.
Le fichier f1 est par exemple issu d’un procédé d’enregistrement de fichier tel que décrit ci-avant, illustré sur la Figure 4. De même, l’entrée d’accès ACL (U1 , f1 ) du propriétaire 11 est, de préférence, obtenue comme décrit ci-avant en relation à la Figure 4.
Au cours du procédé de la Figure 5, le propriétaire 11 génère une nouvelle entrée d’accès ACL (U2, f1 ) publique associée au délégant I2.
Ainsi, une fois l’entrée d’accès ACL (U2, f1 ) générée et enregistrée dans la base DB, le délégant I2 pourra ultérieurement accéder au contenu du fichier fl sans avoir besoin d’une quelconque délégation, et sans avoir besoin que le propriétaire 11 soit connecté.
A une étape 4100, le délégant I2 transmet au propriétaire 11 sa valeur d’identification ID (U2, f1 ) pour le fichier fl. On rappelle que la fonction d’identification ID a, de préférence, été partagée entre toutes les organisations du réseau avant de commencer les échanges.
Dans le présent Exemple 1 , la fonction d’identification ID présente les mêmes propriétés déjà mentionnées ci-avant en relation à la Figure 2 et la transmission est réalisée de la même manière. En particulier :
- La valeur d’identification ID(U2, f 1 ) dépend de préférence de la clé privée U2 du délégant et est de préférence construite de sorte qu’un tiers ne peut pas obtenir ladite valeur d’identification sans connaître la clé privée U2. Ainsi, des utilisateurs tiers éventuellement malveillants ne peuvent pas deviner les clés privées des utilisateurs, ou encore accéder de façon illicite au contenu du fichier fl , en interceptant les échanges ;
- La valeur ID (U2, f1 ) est transmise à l’étape 4100 sur un canal hautement sécurisé, par exemple à l’aide de fonctions cryptographiques, pour assurer que seuls le propriétaire 11 et le délégant I2 connaissent ladite valeur.
A une étape 4200, le propriétaire 11 obtient la valeur de sa propre entrée d’accès ACL (U1 , f1 ) pour le fichier fl , auprès de la base DB. Par exemple, le propriétaire 11 transmet une requête d’accès Req ACL et récupère en retour l’entrée d’accès ACL (U1 , f1 ). Cette valeur ACL (U1 , f 1 ) peut sinon avoir été préalablement enregistrée par le propriétaire 11 .
Ensuite, à une étape 4300, le propriétaire 11 obtient ou recalcule sa propre valeur d’identification ID (U1 , f1 ), puis recalcule la clé de déchiffrement sk pour le fichier fl . Dans le cas où la fonction d’autorisation Aut est une simple somme, la clé de déchiffrement sk peut être obtenue de manière simple : sk = ID (U1, f1 ) + ACL (U1, f1 )
A une étape 4400, le propriétaire 11 calcule la valeur appropriée de la nouvelle entrée d’accès ACL (U2, f1 ) à générer pour le délégant I2, ici selon la formule suivante :
ACL (U2, f1 ) = sk - ID (U2, f1 )
A une étape 4500, cette entrée d’accès ACL (U2, f1 ) est intégrée au sein de la liste d’accès ACL publique de la base DB de gestion d’accès. La liste d’accès ACL est publique ; il n’est pas nécessaire de chiffrer l’entrée d’accès ACL (U2, f1 ), puisque cette entrée prise isolément ne suffirait pas à un attaquant tiers pour calculer la clé de déchiffrement sk.
Une fois l’entrée d’accès ACL (U2, f1 ) intégrée à la liste d’accès ACL publique, le délégant I2 dispose de droits d’accès de niveau élevé pour le fichier fl . Celui-ci n’a pas besoin de communiquer avec le propriétaire 11 pour déchiffrer ultérieurement le fichier f1 .
Enfin, à une étape 4600 optionnelle, le propriétaire 11 peut confirmer au délégant I2 que des droits d’accès valides ont été intégrés à la liste ACL publique pour le délégant I2. A titre d’exemple, un message « OK » peut être transmis au délégant I2. En alternative, le délégant I2 peut effectuer lui-même une vérification de la liste ACL. On notera que le dispositif délégant 12 pourrait obtenir des droits d’accès au fichier f1 auprès d’un autre délégant I2’, I2”... connaissant la valeur de la clé de déchiffrement sk, plutôt qu’auprès du propriétaire 11. En effet, ces délégants I2’, I2”... connaissent la valeur de la clé de déchiffrement sk, et seraient donc en mesure de générer une entrée d’accès ACL (U2, f1 ) valide après avoir reçu la valeur ID (U2, d1 ) depuis le délégant I2.
Si des révocations de droits doivent être mises en oeuvre, un moyen simple pour le propriétaire 11 de révoquer les droits d’accès accordés aux différents utilisateurs délégants ou délégués consisterait à générer une nouvelle clé de déchiffrement, et à rendre obsolète la précédente clé de déchiffrement. Les droits (entrées d’accès, délégations) obtenus à partir de la précédente clé de déchiffrement sont alors rendus également obsolètes. En effet, dès lors que la clé de déchiffrement est modifiée, les informations de la liste d’accès ACL avant modification de la clé deviennent inutiles pour les dispositifs du système.
* Accès à un fichier chiffré à l’aide de droits d’accès permanents (Exemple 1)
La Figure 6 illustre des étapes d’un procédé d’échange de données entre un dispositif délégant (par exemple I2 ou l2’ou I2”), une base de gestion d’accès DB et une mémoire de stockage M de fichiers, selon un exemple. Le procédé peut être mis en oeuvre par une unité de traitement du dispositif délégant I2. Le délégant I2 utilise des droits d’accès (préférentiellement permanents) qui lui ont été précédemment octroyés pour le fichier f1 chiffré, par exemple à l’issue du procédé décrit ci-avant et illustré sur la Figure 5.
L’accès au contenu du fichier par le délégant I2 repose sur les mêmes principes généraux que le procédé d’accès au fichier par le délégué I3 décrit ci-avant, en relation à la Figure 3. Pour pouvoir accéder au contenu du fichier f1 chiffré, le délégué I3 doit obtenir la valeur de la clé de déchiffrement sk qui verrouille le contenu du fichier f1.
Toutefois, une distinction majeure est que le délégant I2 n’a pas besoin de recevoir une délégation de la part d’une quelconque organisation du réseau, avant d’accéder au contenu du fichier f1 chiffré. En effet, un accès lui a déjà été octroyé par le propriétaire 11. D’abord, à une étape 5100, le délégant I2 récupère son entrée d’accès ACL (U2, f1 ) dans la liste d’accès ACL publique. Le délégant I2 décline par exemple son identité à l’aide de l’identifiant d(l2), et envoie une requête d’accès Req ACL. Le délégant I2 récupère en retour l’entrée d’accès ACL (U2, f1 ).
Puis à une étape 5200, le délégant I2 obtient sa propre valeur d’identification ID(U2, f1 ) associée au fichier f1 Le délégant I2 peut calculer cette valeur d’identification le cas échéant, s’il ne la possède pas en mémoire.
A une étape 5300, le délégant I2 calcule ensuite la clé de déchiffrement sk pour le fichier f1 , en fonction des deux données suivantes :
• la valeur d’identification ID(U2, f1 ) obtenue à l’issue de l’étape 5200 ;
• l’entrée d’accès ACL(U2, f1 ) lue à l’étape 5100 dans la base DB de gestion d’accès.
On rappelle que la clé de déchiffrement sk est ici construite comme suit : sk = Aut(ID(U2, f1 ), ACL(U2, f1 ), 0)
Dans l’exemple simple d’une fonction autorisation Aut égale à la fonction somme, le délégant I2 obtient de manière très simple la clé de déchiffrement sk comme une somme des deux données susnommées. La clé de déchiffrement sk peut optionnellement être conservée en mémoire (de manière hautement sécurisée) à une étape 5400 pour un déchiffrement ultérieur du fichier.
La confidentialité de la clé de déchiffrement sk est préservée, puisque seul le délégant I2 connaît sa clé privée U2 lui permettant de calculer sa propre valeur d’identification ID(U2, f1 ) associée au fichier f1 .
A une étape 5500, le délégant I2 obtient le fichier f1 chiffré auprès d’une mémoire dans laquelle ce fichier est stocké, ici auprès de la mémoire M de stockage. A cet effet, le délégué I3 peut transmettre une requête de fichier Req f1 .
Enfin, à une étape 5600, le délégant I2 décline la valeur de la clé de déchiffrement sk pour accéder au contenu du fichier, de préférence par déchiffrement symétrique.
Dans le cas où un ou plusieurs serveurs de calcul (délégués I3, I3’...) ont travaillé sur le contenu du fichier f1 , le délégant I2 peut alors accéder au contenu modifié.
L’ensemble des étapes décrites ci-avant, pour un accès au fichier f1 par un délégant I2, se transposent à l’identique pour un accès par le propriétaire 11 du fichier. Le propriétaire 11 dispose ici des mêmes niveaux de droits d’accès que le délégant I2, et détient notamment sa propre entrée d’accès ACL (U1 , f1 ) pour le fichier f1.
*Exemple 2 - Gestion de droits d’accès avec un anonymat renforcé des entrées d’accès
Selon un protocole alternatif (Exemple 2) de gestion de droits d’accès à des fichiers chiffrés, une première fonction d’identification ID1 est utilisée pour la génération des valeurs d’identification et des valeurs de délégation, et une deuxième fonction d’identification ID2 distincte est utilisée pour la génération des entrées d’accès intégrées aux listes d’accès ACL. On décrit ci-après des procédés de traitement correspondant à un tel protocole.
Ce protocole alternatif reprend les principes décrits ci-avant en relation à un procédé de délégation de droits d’accès à un fichier f1 chiffré par un délégant I2 (Figure 2), en relation à un procédé d’accès à un fichier f1 chiffré par un délégué I3 à l’aide de la valeur de délégation (Figure 3), en relation à un procédé de chiffrement et d’enregistrement d’un nouveau fichier f1 par un propriétaire 11 (Figure A), en relation à un procédé de génération de droits d’accès par un propriétaire 11 (Figure 5) et en relation à un procédé d’accès à un fichier f1 chiffré par un délégant I2 à l’aide des droits d’accès (Figure 6). On conserve ci-après les mêmes références numériques pour désigner les étapes de ces divers procédés.
Les différents procédés selon ce protocole alternatif peuvent être mis en oeuvre par le système 1 de partage de fichiers tel que décrit ci-avant, en relation à la Figure 1.
Une distinction majeure du protocole de l’Exemple 2, vis-à-vis du protocole de l’Exemple 1 , est l’utilisation de deux fonctions d’identification ID1 et ID2 distinctes. Les principales différences sont détaillées ci-après.
Au cours d’une délégation de droits d’accès (similaire à la Figure 2), à l’étape 1100, la valeur retournée par le délégué I3 au délégant I2 dépend de la valeur ID1 (U3, f1 ) obtenue avec la première fonction d’identification ID1 pour le fichier f1 et le délégué I3.
Par exemple, la première fonction d’identification ID1 se calcule comme suit :
ID1 (U3, f1 ) = sha256(concatenation (U3, f1,’ID1’)) De façon optionnelle et avantageuse, la valeur retournée par le délégué 13 au délégant 12 est randomisée à l’aide d’un nombre aléatoire k obtenu par le délégué 13. On note que la valeur du nombre aléatoire k n’est pas connue du délégant 12.
Par exemple, la valeur retournée par le délégué 13 au délégant 12 est égale à :
ID1 (U3, f1 ) + k
Le dispositif délégant I2 n’a alors pas accès à la valeur ID1 (U3, f1 ) isolée, puisque seul le dispositif délégué I3 connaît la valeur du nombre aléatoire k.
A l’étape 1200, le calcul de la valeur de délégation Del’ par le délégant I2 est modifié. La valeur de délégation Del’ est ici égale à une paire. Le premier élément de la paire Del’ est égal à la différence entre la valeur d’identification pour le délégant I2 et la valeur précédemment retournée par le délégué I3 : ID1 (U2, f1 ) - [ID1 (U3, f1 ) + k].
Le deuxième élément de la paire Del’ est égal à une valeur obtenue avec la deuxième fonction d’identification ID2 pour le fichier f1 et le délégant I2 : ID2 (U2, f1). Ainsi, dans cet Exemple 2, le délégant I2 transmet une valeur qui permet ultérieurement au délégué I3 de savoir quelle entrée d’accès doit être requise dans la liste ACL(f1 ) auprès de la base DB.
Par exemple, la deuxième fonction d’identification ID2 se calcule comme suit :
ID2 (U2, f1 ) = sha256(concatenation(U2, f1,’ID2’))
Les valeurs ‘ID1 ’ et ‘ I D2’ sont des chaînes de caractères distinctes. De cette manière, les valeurs fournies par les deux fonctions d’identification ID1 et ID2 sont décorrélées et distinctes.
De préférence, la transmission 1300 au dispositif délégué I3 de la délégation Del’ prend la forme d’un envoi de message signé sur un canal hautement sécurisé, de même que dans l’Exemple 1 .
Au cours d’un accès à un fichier f1 chiffré par un délégué I3 à l’aide de la délégation (similaire à la Figure 3), à l’étape 2100, le délégué I3 envoie une requête d’accès Req ACL à la base DB de gestion d’accès. Le délégué I3 associe à sa requête d’accès Req ACL le deuxième élément ID2(U2, f1 ) de la paire Del’ précédemment reçue.
A l’étape 2200, le délégué I3 obtient en retour une valeur numérique ACL(ID2(U2, f1 )) de l’entrée d’accès propre au délégant I2 pour le fichier f1 . Dans cet Exemple 2, l’entrée d’accès prend la forme ACL(ID2(U2, f1 )). Pour obtenir une entrée d’accès auprès de la base DB, il faut soumettre une valeur numérique obtenue à l’aide de la deuxième fonction d’identification ID2. La liste d’accès ACL demeure publique.
Pour le calcul de la clé de déchiffrement sk à l’étape 2400, le délégué 13 obtient ou recalcule la valeur d’identification ID1 (U3, f1 ) qui lui est propre pour le fichier d1. A partir de cette valeur et du nombre aléatoire k, le délégué I3 obtient la valeur ID1 (U2, f1 ).
On rappelle que le nombre aléatoire k est connu du délégué I3. Ce nombre a par exemple été conservé de manière sécurisée dans une mémoire du dispositif délégué I3. La clé de déchiffrement sk est obtenue comme suit par le délégué I3 à l’étape 2400, sur la base des valeurs précédemment reçues : sk = Aut(ID1 (U2, fl ), ACL(ID2(U2, fl )), 0)
Dans un cas simple, la fonction d’autorisation Aut utilisée pour calculer la clé retourne une somme des variables prises en entrée : sk = ID1 (U2, f1 ) + ACL(ID2(U2, f1 )).
Le déchiffrement et l’accès au fichier fl se déroulent comme dans l’Exemple 1 .
Au cours de la création et du chiffrement d’un nouveau fichier (similaire à la Figure A), le propriétaire 11 utilise la première fonction d’identification ID1 pour le calcul de la nouvelle clé de déchiffrement sk associée au fichier fl , et utilise la deuxième fonction d’identification ID2 pour le calcul de la nouvelle entrée d’accès qui lui est propre.
Ainsi, à l’étape 3200, le propriétaire 11 calcule non seulement un entier aléatoire correspondant à la valeur de sa future entrée d’accès, mais calcule également la valeur ID2 (U1 , f1 ). La valeur insérée dans la base DB à l’étape 3350 est égale à ACL(ID2(U1 , f1 )). Enfin, à l’étape 3500, la clé de déchiffrement sk est calculée de la même manière que ci-avant : sk = Aut (I D 1 (U 1 , fl ), ACL(ID2(U1, fl )), 0)
Il n’est pas souhaitable que le propriétaire 11 ajoute un entier aléatoire secret pour obtenir la valeur de la clé. Au cours de la génération de nouveaux droits d’accès par un propriétaire 11 pour un délégant I2 (similaire à la Figure 5), il est préférable que la valeur d’identification communiquée par le délégant I2 soit randomisée à l’aide d’un nombre aléatoire k’. La valeur du nombre aléatoire k’ n’est pas connue du propriétaire 11.
Ainsi, à l’étape 4100, le délégant I2 communique au propriétaire 11 la valeur suivante : [ID1 (U2, f1 ) + k’].
Ici, le propriétaire 11 n’a donc pas accès en clair à la valeur ID1 (U2, f1 ), contrairement à l’Exemple 1 où le propriétaire 11 reçoit la valeur ID(U2, f1 ) à l’étape 4100.
A l’étape 4400, une différence avec l’Exemple 1 est que le propriétaire 11 ne calcule pas de manière autonome la nouvelle entrée d’accès ACL(ID2(U2, f1 )) qui doit être ajoutée à la liste d’accès ACL pour le délégant I2 et le fichier f1. Le calcul de ladite entrée d’accès est réalisé de manière distribuée entre le propriétaire 11 et le délégant I2.
Dans cet Exemple 2, à une première sous-étape de l’étape 4400, le propriétaire 11 transmet au délégant I2 la valeur suivante : sk - [ID1 (U2, f 1 ) + k’]
Sur cette base, à une deuxième sous-étape de l’étape 4400, le délégant I2 (qui est le seul à connaître le nombre aléatoire k’) peut recalculer la valeur [sk - ID1 (U2, fl )].
C’est donc le délégant 12 qui, à l’étape 4500, communique à la base DB la valeur de l’entrée d’accès ACL(ID2(U2, f1 )) qui lui sera associée dans la liste ACL pour le fichier f1 :
ACL(ID2(U2, f 1 )) = sk - ID1 (U2, f 1 )
Enfin, les étapes d’un accès au fichier f1 chiffré par le délégant I2 à l’aide de droits d’accès issus de la base DB (similaire à la Figure 6) sont similaires à l’Exemple 1. Le délégant I2 doit soumettre sa valeur d’identification I D1 (U2,f 1 ) à la base DB de sorte à obtenir l’entrée d’accès ACL(ID2(U2, f1 )). Par construction de la valeur de l’entrée d’accès à l’étape 4500 précédente, le délégant I2 est en mesure de calculer la clé de déchiffrement sk sans être connecté au réseau simultanément au propriétaire 11.
Vis-à-vis de l’Exemple 1 , un premier avantage du protocole selon l’Exemple 2 est que les entrées d’accès sont anonymisées. A partir de la valeur numérique d’une entrée d’accès publique, par exemple ACL(ID2(U2,f1 )), présente dans la liste d’accès ACL(f1 ), un tiers ne peut pas remonter à l’identité du dispositif I2. La valeur de l’entrée d’accès est obtenue auprès de la base DB non pas en fournissant un identifiant du dispositif I2, mais en fournissant la valeur numérique ID2(U2,f1 ) obtenue avec la deuxième fonction d’identification ID2.
Un deuxième avantage du protocole selon l’Exemple 2 est de masquer les valeurs de la première fonction d’identification ID1 associées aux différents dispositifs, avec une randomisation des valeurs de la première fonction d’identification ID1 lors des échanges. Ainsi, un attaquant tiers qui intercepterait les communications de données ne pourrait pas avoir accès en clair aux valeurs de la première fonction d’identification ID1 pour le délégant I2 ou pour le délégué I3. La sécurité des échanges de données est ainsi renforcée.

Claims

REVENDICATIONS
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 ensemble de données (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 ensemble de données (fl ) é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 ensemble de données (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 oeuvre 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 ensemble de données (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), de sorte que le dispositif délégué (I3) peut ultérieurement recevoir la valeur de délégation, obtenir l’entrée d’accès (ACL(U2, f1 )) propre au dispositif délégant (I2) à l’aide de la valeur de délégation (Del)et calculer la clé (sk) de déchiffrement dudit ensemble de données (f1 ).
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 ensemble de données 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é
(13),
- et en fonction d’une valeur d’identification (ID(U2, f1 )) propre au dispositif délégant
(12) et associée audit ensemble de données (f1 ).
5. Procédé d’échange de données selon la revendication 4, dans lequel la valeur d’identification (ID(U2, fl )) 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, fl )) propre au délégant étant construite de sorte qu’un tiers ne peut pas obtenir ladite valeur d’identification (ID(U2, fl )) 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, fl )) propre au dispositif délégant (I2) associée audit ensemble de données (fl ) et la valeur d’identification (ID(U3, fl )) propre au dispositif délégué
(13) associée audit ensemble de données (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 audit ensemble de données (fl ) et la valeur d’identification (ID1 (U3, fl )) propre au dispositif délégué (I3) associée audit ensemble de données (fl ), 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 ensemble de données (fl ).
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, comprenant la transmission au dispositif délégué (I3) 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 ensemble de données (fl ) 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 ensemble de données (f1 ) chiffré dépend d’une fonction Aut vérifiant l’égalité suivante :
Aut(ID(U2, f1 ), ACL(U2, f1 ), 0) = Aut(ID(U3, fl ), ACL(U2, fl ), Del) où f1 est ledit ensemble de données 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 audit ensemble de données (f1 ) a été préalablement obtenue par un serveur propriétaire (11 ) en fonction de la clé (sk) de déchiffrement dudit ensemble de données (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 audit ensemble de données (f1 ) comprend des sous-étapes mises en oeuvre par le serveur propriétaire (11 ) de :
- obtention (4100) d’une valeur d’identification (ID(U2, f1 )) propre au dispositif délégant (I2) et associée audit ensemble de données (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 (11 ) et associée audit ensemble de données
(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 audit ensemble de données (f1 ), en fonction de ladite entrée d’accès (ACL(U1 , f1 )) propre au serveur propriétaire (11 ) 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 ensemble de données (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 ensemble de données (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 ensemble de données (f1 ), le dispositif délégué (I3) ayant préalablement reçu une valeur de délégation (Del) générée par 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 oeuvre 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 ensemble de données (f1 ),
- calcul (2300) de la clé (sk) de déchiffrement dudit ensemble de données (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 ensemble de données (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 ensemble de données (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 (12).
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 ensemble de données (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 oeuvre par l’unité de traitement du dispositif délégué (I3), de :
- obtention (2400) de l’ensemble de données (f1 ) chiffré auprès d’une mémoire,
- déchiffrement (2500) de l’ensemble de données (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 oeuvre un procédé d’échange de données selon l’une quelconque des revendications 1 à 14 avec un dispositif délégué (I3).
21. Système de partage d’ensembles de données 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, fl )),
- 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 oeuvre 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. Système de partage d’ensembles de données 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. Système de partage d’ensembles de données chiffrés selon l’une quelconque des revendications 21 ou 22, l’ensemble comprenant en outre un serveur propriétaire de donnée (11 ) configuré pour calculer des entrées d’accès (ACL(U2, f1 )) propres à des dispositifs délégants (12) associées à au moins un ensemble de données (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 oeuvre 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 oeuvre un procédé d’échange de données selon l’une quelconque des revendications 1 à 14.
PCT/FR2022/050520 2021-03-25 2022-03-22 Gestion de droits d'accès à des fichiers numériques avec possible délégation des droits WO2022200726A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
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

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
FRFR2103009 2021-03-25

Publications (1)

Publication Number Publication Date
WO2022200726A1 true WO2022200726A1 (fr) 2022-09-29

Family

ID=75690577

Family Applications (1)

Application Number Title Priority Date Filing Date
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

Country Status (3)

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

Cited By (1)

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

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
"European Wireless", EUROPEAN WIRELESS CONFÉRENCE, 2019, pages 1 - 6
JAWAD, SERRANO-ALVARADO, VALDURIEZ, DESIGN OF PRISERV, A PRIVACY SERVICE FOR DHTS,, 2008
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] *
STEICHEN ET AL.: "Blockchain-Based, Decentralized Access Control for IPFS", IEEE INTERNATIONAL CONFÉRENCE ON INTERNET OF THINGS, 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 *

Cited By (2)

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

Also Published As

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

Similar Documents

Publication Publication Date Title
CN110033258B (zh) 基于区块链的业务数据加密方法及装置
Zhao et al. Trusted data sharing over untrusted cloud storage providers
Kamara et al. Cryptographic cloud storage
EP3506556B1 (fr) Méthode d&#39;échange de clés authentifié par chaine de blocs
CN102318262B (zh) 受信云计算和服务框架
EP2396922B1 (fr) Cadre de services et informatique en nuage sécurisé
CN102687133B (zh) 用于可信计算和数据服务的无容器数据
WO2009130089A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
US8995655B2 (en) Method for creating asymmetrical cryptographic key pairs
CN102687132A (zh) 用于可信计算和数据服务的可信的可扩展标记语言
CN102656589A (zh) 通过包装器合成的用于数据的可验证的信任
FR3007551A1 (fr) Procede et serveur de traitement d&#39;une requete d&#39;acces d&#39;un terminal a une ressource informatique
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.
Wise et al. Cloud docs: secure scalable document sharing on public clouds
FR3104870A1 (fr) Plateforme sécurisée, décentralisée, automatisée et multi-acteurs de gestion d’identités d’objets au travers de l’utilisation d’une technologie de chaîne de blocs.
EP4315741A1 (fr) Gestion de droits d&#39;accès à des fichiers numériques avec possible délégation des droits
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
Aloui et al. Protocol for preserving privacy in distributed system (PPDS)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22715137

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18283658

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2022715137

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022715137

Country of ref document: EP

Effective date: 20231025