FR3134908A1 - Method and system for managing access rights in a fair transaction of digital data - Google Patents

Abstract

A method of accessing a set of encrypted blocks comprising data blocks and blocks corresponding to nodes of a first Merkle tree, each block being encrypted by a device-specific identification value is disclosed. owner (P) and specific of the file and the block, ID-P-FBi. A recipient device (R) implements the following steps: for each block, reception, from a trusted server (T), of an access entry specific to the recipient device and specific to the file and the block, ACL- R-FBi, determining ID-P-FBi from ACL-R-FBi and decrypting the block using ID-P-FBi; constructing a second Merkle tree (MT2) from the blocks decrypted and the verification of a concordance of the Merkle trees; in the absence of concordance, the transmission, to the trusted server (T), of a challenge comprising a set of undecrypted blocks and, for each of said blocks, of a identification value specific to the receiving device and specific to the file and the block, V-R-FBi. Figure for abstract: Figure 2

Description

Method and system for managing access rights in a fair transaction of digital data

The field of the invention is that of distributed computer systems for the transmission and sharing of digital data. The invention relates more particularly to the regulation of access to a computer file.

An access rights management protocol is, for example, necessary when a user of a calculation server wishes to perform calculations from a file encrypted by its owner. According to such a protocol, the owner can encrypt the file upstream and upload it to a storage server. The user can then download the encrypted file from the storage server and request access rights from the owner.

Furthermore, obtaining the file may be subject to compensation, for example financial. It is then necessary to ensure that the transaction between the user and the owner is fair in the sense that neither the user nor the owner uses the exchange of the file to their advantage by recovering the other's data but without send what he should have. To draw a parallel with the real world, we do not want a seller to deliver a good without the buyer giving money in exchange or, on the contrary, for the buyer to give the money but the seller does not give the good in exchange. The “fairswap” protocol, proposed by Stefan Dziembowski, Lisa Eckey, and Sebastian Faust. 2018. FairSwap: How To Fairly Exchange Digital Goods. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS '18). Association for Computing Machinery, New York, NY, USA, 967–984, addresses this need for computer data exchange. This protocol introduces a trusted third party acting as judge of conflicts between the seller and the buyer.

The encryption of the file upstream by the owner before being uploaded to the storage server complicates the integration of the access rights management protocol into a fair transaction protocol of the fairswap type because in the latter each transaction must be based on a unique key.

Furthermore, in the event of a conflict, the trusted third party becomes aware of certain blocks of the file. However, by leaving this file on a storage server, the trusted third party could download all the blocks and decrypt them (at least for those blocks involved in the fairswap protocol), which risks compromising security.

The invention aims to propose a protocol for managing access rights to a file encrypted by its owner integrated into a fair transaction protocol of the fairswap type, which makes it possible to overcome the difficulties previously mentioned without being accompanied by 'too much calculation time.

To do this, the invention proposes a method of accessing a file by a receiving device, in which an encoding of the file is stored on a storage server, the encoding of the file comprising a plurality of encrypted blocks consisting of a first set of blocks corresponding to a division of the file into blocks and a second set of blocks corresponding to values of the nodes of a first Merkle tree constructed from the blocks of the first set, each block of the plurality of blocks being encrypted by an identification value specific to a proprietary device and specific to the file and the block, ID-P-FBi. This method includes the implementation of the following steps by the receiving device:

• for each block of the plurality of blocks, receiving, from a trusted server, an access entry specific to the receiving device and specific to the file and the block, ACL-R-FBi, determining ID-P- FBi from ACL-R-FBi and decrypting the block using ID-P-FBi;
• constructing a second Merkle tree from the decrypted blocks of the first set of blocks of the plurality of blocks and verifying a match of the second Merkle tree with the decrypted blocks of the second set of blocks of the plurality of blocks ;
• in the absence of a match:
  • creating a challenge comprising a set of undecrypted blocks of the plurality of blocks, said set consisting of at least one contested block and a block of a Merkle check of the contested block; And
  • the transmission, to the trusted server, of the challenge and, for each of the blocks of the challenge, of an identification value specific to the receiving device and specific to the file and the block, VR-FBi.

Some preferred but non-limiting aspects of this process are as follows:

• it includes the implementation of the following steps by the trusted server:
  • verifying the validity of the VR-FBi of the protest blocks;
  • in the event of unverified validity, the rejection of the challenge;
  • in case of verified validity:
    • for each of the blocks in the dispute, determining ID-P-FBi from VR-FBi and ACL-R-FBi and decrypting the block using ID-P-FBi;
    • a Merkle verification of each of the decrypted contested blocks.
• it includes the preliminary steps consisting for the recipient device to be carried out:
  • downloading the file encoding from the storage server;
  • for each block of the plurality of blocks of the file encoding, determining and transmitting to the VR-FBi trusted server.
• it further comprises, through the proprietary device, for each block of the plurality of blocks, the preliminary steps of:
  • reception, from the trusted server, of VR-FBi;
  • the generation of ACL-R-FBi, from ID-P-FBi and VR-FBi;
  • the transmission, to the trusted server, of ACL-R-FBi.
• it further comprises the realization by the receiving device, for each block of the plurality of blocks, of an encryption of V-R-FBi by means of a public key of the proprietary device.
• it further comprises the carrying out by the owner device, for each block of the plurality of blocks, of a decryption of V-R-FBi by means of a private key of the owner.
• it further comprises the realization by the receiving device, for each block of the plurality of blocks, of a calculation and transmission to the trusted server of a hash value of V-R-FBi.
• It further comprises the realization by the proprietary device, for each block of the plurality of blocks before generating ACL-R-FBi, of a reception from the trusted server of the hash value of V-R-FBi calculated by the device recipient, a calculation of a hash value from V-R-FBi received from the trusted server and a comparison of the received hash value and the calculated hash value.
• the verification, by the trusted server, of the validity of the V-R-FBi of the challenge blocks comprises, for each of the challenge blocks, the calculation of a hash value from V-R-FBi transmitted by the receiving device to the trusted server with the challenge and comparison of the calculated value with the hash value of V-R-FBi previously transmitted to the trusted server by the receiving device.
• it includes the preliminary steps consisting for the recipient device to be carried out:
  • downloading the file encoding from the storage server;
  • for each block of the plurality of blocks of the file encoding:
    • the determination of VR-FBi;
    • calculating and transmitting to the trusted server a first Diffie-Hellman value based on VR-FBi.
• It also includes, through the proprietary device, the preliminary steps of:
  • calculation and transmission to the trusted server of a second Diffie-Hellman value; And
  • for each block of the plurality of blocks:
    • receiving, from the trusted server, the first Diffie-Hellman value based on VR-FBi;
    • determination of a shared Diffie-Hellman key;
    • generation of ACL-R-FBi, from ID-P-FBi and the Diffie-Hellman shared key;
    • transmission, to the trusted server, of ACL-R-FBi.
• the verification, by the trusted server, of the validity of the V-R-FBi of the challenge blocks comprises, for each of the challenge blocks, the calculation of a third Diffie-Hellman value based on V-R-FBi transmitted by the device recipient to the trusted server with the challenge and comparison of the third Diffie-Hellman value with the first Diffie-Hellman value previously transmitted to the trusted server by the receiving device.
• it includes the steps consisting for the proprietary device to carry out:
  • generating the first set of blocks by splitting the file;
  • constructing the first Merkle tree from the first set of blocks;
  • generating the second set of blocks from the nodes of the first Merkle tree;
  • generating the encoding of the file comprising, for each of the blocks of the first and second set, the encryption of the block by ID-P-FBi;
  • transmitting the file encoding to the storage server.

Other aspects, aims, advantages and characteristics of the invention will appear better on reading the following detailed description of preferred embodiments thereof, given by way of non-limiting example, and made with reference to the appended drawings. on which ones :

- there is a diagram representing a system for sharing computer files between computer devices of several organizations;

- there is a diagram illustrating the different stages of the process according to the invention;

- there illustrates the different blocks constituting the file encoding;

- there illustrates the encryption of the different blocks of file encoding by the proprietary device;

- there illustrates the decryption of the file by the proprietary device;

- there illustrates a verification of Merkle proof by the trusted server.

DETAILED DESCRIPTION OF PARTICULAR EMBODIMENTS

The invention relates to the realization of fair transactions between entities of a network integrating management of access rights to encrypted files. The entities are considered to have previously shared an access rights management protocol together.

There schematically represents a system 1 for sharing files between computer devices from several organizations Org1, Org2, Org3, etc., connected to the same network N, preferably a remote telecommunications network. The N network is typically an Internet, Intranet, 3G, 4G, 5G, DECT, Bluetooth, etc. telephone network.

In this example, the organizations Org1, Org2, Org3 are geophysical and/or environmental data management organizations. By “geophysical data” we mean data relating to the physical characteristics of the Earth, typically resulting from measurements. This 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 and/or processing data. 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 calculation servers.

We consider here that each of the organizations Org1, Org2, Org3 is independent. For example, organizations wish to selectively pool some of their hardware and data, so that each of them can rely on at least some of the resources and data of the other organizations.

Additionally, here, organization Org1 has a compute server I3 and organization Org2 has a compute server I3'. By “computation server” we mean a server having very significant computing power, typically greater than each of the devices I1, I1’, I2, I2’, I2’’, etc. We would like to be able to selectively make one and/or the other of these servers I3 and I3' available to other organizations in the network in order to carry out processing on geophysical and/or environmental data.

The invention is, however, not limited to the case of geophysical and/or environmental data. It can advantageously be implemented regardless of the type of file content or the type of organizations Org1, Org2, Org3, etc. or also for two organizations. An application to geophysical and/or environmental data is advantageous because the computational processing of said data may require high computing power. Local authorities should be able to temporarily entrust certain processing to calculation servers, without calling into question the integrity and confidentiality of the data contained in the files.

Advantageously, all the nodes of system 1 (that is to say here in particular the devices I1, I1', I2, I2', I2'', etc.) can access each of the encrypted files f1, f2, etc. without control, for example through a distributed storage system, for example conforming to the IPFS protocol, managing memories M, M', M''. The encrypted files f1, f2, etc. are then available. Access to the information contained in the file is regulated by the presence of encryption keys, but access to the file itself is preferably not regulated.

In one possible embodiment, metadata is associated with each of the files, for example the name of the file, its type, its size, the root value (i.e. the vertex hash) of a Merkle tree constructed for the file (see below). ). This metadata is transmitted by the storage system along with the list of available files and allows a node to select the file it wishes to download.

Private keys belonging to the different devices are stored very securely. These are, for example, numerical values specific to each device. It is assumed that none of the devices share their private key, neither on network N, nor with any of the other devices.

Here, system 1 further includes:

• for the organization Org1, an owner server I1 and a user server I2. The owner server I1 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 further 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 I1.

• for the organization Org2, an owner server I1’ and a user server I2’. The owner server I1' 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 Org2 organization 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 I1’.

• for the Org3 organization, an I2” user server. The Org3 organization does not have significant computing power here suitable for carrying out heavy processing on geophysical and/or environmental data.

System 1 further includes a storage memory M. Here, memory M belongs to the organization Org1. Alternatively, the memory M could be integrated into any of the devices of one of the organizations Org1, Org2, Org3, etc., or remote from each of these devices.

Furthermore, the organization Org2 has here a storage memory M', and the organization Org3 has here a storage memory M''.

Preferably, when several memories (here M, M’, M’’) are present, a common name space is used. The memories M, M’, M’’ belong to a distributed storage system, for example produced using an overlay network.

Preferably, each device I1, I1', I2, I2', etc. requests the memory which is available in its local server; thus, in the example illustrated on the , the device I1 can interrogate the memory M and the device I1' can interrogate the memory M'. To the extent that the memories M, M', and M'' belong to the same distributed storage system, the files stored in the other memories are also accessible.

Preferably, the recordings on a memory cannot be modified subsequently. This last property is for example provided as a service by the distributed storage solution used.

Each encrypted file is recorded either on any of the memories M, M’, M’’, etc., or on a remote memory. In this example, file f1 is stored on memory M of organization Org1 and file f2 is stored on memory M' of organization Org2. Other files, preferably encrypted or possibly unencrypted, can be saved in memory.

Each of the devices I1, I1', I2, I2', I2'', I3, I3' comprises processing means such as for example a processing unit, not shown on the . Each of these processing means may comprise in memory one or more computer program products comprising code instructions for implementing the methods described below, and/or may read one or more computer-readable storage means on which are recorded code instructions for implementing the methods described below.

Returning to the previous example, the organizations Org1, Org2, Org3 wish to be able to request the calculation servers I3, I3' in order to have their computing power to carry out processing on the geophysical and/or environmental data to which any one devices I1, I1', I2, I2', I2''. To do this, we wish to assign access (typically only for reading) to one of the encrypted files f1 and/or f2 for one of the calculation servers I3 and/or I3', in a selective and preferably temporary manner.

In reference to the , we consider below a device owner P of a file (for example the server I2'' of the organization Org3) and a recipient device R (for example the calculation server I3 of the organization Org3) which wishes to have access to the file. The file, encrypted by the owner device P, is stored on a storage server S. The owner device P and the recipient device R implement a fair transaction within the meaning of a fairswap type protocol via a trusted server T.

In reference to the , the file has previously been encrypted by the proprietary device (step no. 1 designated by ENC) and transmitted in its encrypted form Z (step no. 2) to the storage server S. The encryption of the file F is more particularly carried out as follows , with reference to Figures 3 and 4. The proprietary device P first divides the file into a plurality of n blocks B1, B2, B3, B4, …, Bn forming a first set of blocks. The proprietary device P then constructs a first Merkle tree MT1 from the first set of blocks. This first Merkle tree MT1 includes a plurality of nodes H1, H2, …, Hm which forms a second set of blocks. The blocks B1, B2, B3, B4, ..., Bn of the first set and the blocks H1, H2, ..., Hm are united in a vector Y. The proprietary device then generates a Z encoding of the file by encrypting, during an ENC operation, each of the blocks of the first and second set, by an identification value specific to the proprietary device and specific to the file and the block (value denoted ID-P-FBi for the block Bi in what follows). The encoding Z thus comprises a first set of encrypted blocks ZB1, ZB2, ZB3, ZB4, etc., ZBn resulting from the encryption of blocks B1, B2, B3, B4, etc., Bn resulting from the cutting of the file Z and a second set of encrypted blocks ZH1, ZH2, ZH3, …, ZBm resulting from the encryption of blocks H1, H2, H3, …, Hm corresponding to the nodes of the first Merkle tree MT1. This Z encoding is transmitted to the storage server S, where applicable with the root value Hm of the Merkle tree MT1 of the file F.

The identification value specific to the owner device P and specific to the file F and the block Bi, ID-P-FBi, depends on the private key Up of the owner device. This identification value is constructed in such a way that a third party cannot obtain this value by simply knowing an identity of the block Bi, without knowing the private key Up. The identification value here also depends on the identity of the file F and the identity of the block Bi. In other words, the identification values of the owner device differ for each file, and for each block within the same file.

Preferably, the different identification values appear random from the point of view of a third party who does not know the private key used, but these values are deterministic for the user having knowledge of the private key used. These values can correspond to the results of an ID identification function such as ID-P-FBi = ID(Up, F, Bi). In an exemplary embodiment, the value ID-P-FBi is obtained as follows: ID-P-FBi = ID(Up, F, Bi) = Up+ sha256(concatenation(Up, F, Bi)), where Up is the private key of the proprietary device, F is the name of the file, Bi is the i-th block of vector Y, “concatenation” corresponds to the concatenation function and “sha256” corresponds to a known cryptographic hash function operating on a word size of 32 bits. We understand that it is possible to use another hash function here.

Still with reference to the , the receiving device R then (step no. 3) downloads the encoding Z of the file from the storage server S, if necessary with certain metadata associated with the file such as for example its name and the root value Hm of the first tree of Merkle.

Then, for each block of the plurality of encrypted blocks ZB1, ..., ZBn, ZH1, ..., ZHm of the encoding of the file, the receiving device R determines an identification value of the receiving device associated with the file and the encrypted block (noted V-R-FBi for block n°i).

In a first embodiment, the V-R-FBi value is calculated using the ID identification function presented above. Thus, V-R-FBi = ID(Ur, F, Bi) = Ur+ sha256(concatenation(Ur, F, Bi)) where Ur is the private key of the receiving device, F is the name of the file, Bi is the i-th encrypted block of encoding Z. This value is then transmitted (step no. 4) to the trusted third party T, for example after encryption using a public key of the proprietary device. The receiving device R can also calculate, for each encrypted block of encoding Z, a hash value of V-R-FBi and transmit this hash value to the trusted server T.

A second embodiment makes it possible to avoid public key encryption to transmit the V-R-FBi values and to have to post to the trusted server all of the hash values of these V-R-FBi values. In this second embodiment, the V-R-FBi value is used to determine a first Diffie-Hellman value, i.e. a number transmitted by one of the agents of a Diffie-Hellman protocol to the other of the agents so that these agents can develop a shared Diffie-Hellman key. Any variation of the Diffie-Hellman protocol can be used here, such as for example that based on elliptic curves (from the English “Elliptic curve Diffie–Hellman”, abbreviated ECDH). In this second embodiment, the receiving device randomly draws two numbers g and p, determines the first Diffie-Hellman value according to g^{V -R- FBI} [p] and transmits to the trusted third party T this first Diffie-Hellman value g^{V -R- FBI}[p] as well as the numbers g and p.

In a first variant, the VR-FBi value is calculated using the identification function ID presented above. Thus, VR-FBi= ID(Ur, F, Bi) and the first Diffie-Hellman value associated with the i-th encrypted block is written g ^{ID(Ur, F, Bi)} [p]. In a second variant, the receiving device R proceeds, for each of the encrypted blocks of encoding Z, to randomly draw a value xi. The first Diffie-Hellman value associated with the i-th encrypted block is then written g ^(xi) mod p.

During an optional step, the recipient device R can also transmit to the trusted server T the value of the root node of the Merkle tree of the expected file (of which it is aware, for example, by means of the metadata) and/or the value of the root node of a Merkle tree constructed on the set of encrypted blocks ZB1, …, Zbn and ZH1, …, ZHm.

During step no. 5, the owner device P retrieves from the trust server T all of the information posted by the recipient device R on the trust server T.

When the optional step mentioned above is implemented, the owner device P verifies that the value(s) of the root node transmitted by the recipient device R to the trusted server are correct. If not, the exchange is stopped.

In the context of the first embodiment, the proprietary device P retrieves from the trusted server T the V-R-FBi values (possibly encrypted using the public key of the proprietary device) and, where appropriate, the associated hash values. The proprietary device P, if necessary, decrypts the V-R-FBi using its private key Up. If necessary, the owner device can, for each block of the plurality of blocks, calculate a hash value of V-R-FBi (possibly after decryption) and compare the calculated value to the corresponding hash value received from the trusted server.

Then, for each block of the plurality of blocks, the owner device P generates an access entry specific to the recipient device and specific to the file and the block, ACL-R-FBi, from ID-P-FBi and VR-FBi. This ACL-R-FBi access entry is then transmitted to the trusted server T (step no. 6 on the ). In an exemplary embodiment, this access entry corresponds to the difference of the two identification values ACL-R-FBi = ID-P-FBi - VR-FBi.

In the context of the second embodiment, the proprietary device P retrieves from the trusted server the numbers g and p, and for each block of the plurality of blocks, the first corresponding Diffie-Hellman value g ^{V -R- FBi} [ p]. The proprietary device P generates a random value T and determines a second Diffie-Hellman value g ^T [p]. The proprietary device P also determines the Diffie-Hellman shared key according to (g ^{V -R- FBi} [p]) ^T [p] = g ^{V -R- FBi *T} [p], generate an access entry specific to the receiving device and specific to the file and the block, ACL-R-FBi, from ID-P-FBi and the Diffie-Hellman shared key. This ACL-R-FBi access entry is then transmitted to the trusted server T with the second Diffie-Hellman value g ^T [p]. In an exemplary embodiment, the access entry corresponds to the difference between the identification value specific to the proprietary device and specific to the file and the block and the shared Diffie-Hellman key: ACL-R-FBi = ID- P-FBi - g ^{V -R- FBi *T} [p].

Then, during a step no. 7, the recipient device R receives, from the trust server T, for each block of the plurality of blocks, the access entry specific to the recipient device and specific to the file and the block, ACL-R-FBi. The receiving device R then calculates, for each block of the plurality of blocks, the identification value specific to the proprietary device and specific to the file and the ID-P-FBi block from ACL-R-FBi.

In the first embodiment, this calculation can thus consist of ID-P-FBi = ACL-R-FBi + V-R-FBi. In the second embodiment, the receiving device also recovers the second Diffie-Hellman value g^T[p], calculates the Diffie-Hellman shared key according to (g^T[p]) ^{VR- FBI}[p])= g^{T * VR- FBI}[p] and the value ID-P-FBi according to for example ID-P-FBi = ACL-R-FBi + g^{T * VR- FBI}[p].

Once the ID-P-FBi value has been determined for each of the blocks, the receiving device proceeds using this value (step no. 8 designated by DEC on the ) upon decryption of the corresponding block. There illustrates this operation, the decrypted blocks being distributed into a first set of decrypted blocks (corresponding to the blocks in the file) and a second set of decrypted blocks (corresponding to the blocks constructed with the nodes of the first Merkle tree MT1).

Then, the receiving device constructs a second Merkle tree MT2 from the decrypted blocks B1, …, Bn of the first set of blocks of the plurality of blocks and verifies the concordance of the second Merkle tree MT2 with the decrypted blocks H1, …, Hm of the second set of blocks of the plurality of blocks. In particular, checking this concordance may consist of verifying that the root node H'm of the second Merkle tree MT2 matches the decrypted block Hm of the second set of blocks of the plurality of blocks corresponding to the root node of the first tree by Merkle MT1.

If there is a match, the decrypted blocks correspond to the expected file. The file can then be reconstructed by bringing together the decrypted blocks B1, ..., Bn of the first set of blocks of the plurality of blocks.

In the absence of a match, the receiving device R proceeds to create a challenge comprising a set of undecrypted blocks of the plurality of blocks (blocks of the vector Z before its decryption DEC), said set being made up of at least 'a contested block and a block of a Merkle check of the contested block. By way of example and with reference to the , the lack of concordance can be linked to the fact that the node H'2 of the second Merkle tree differs from the deciphered block H2 representing the corresponding node of the first Merkle tree. The challenge then includes the undecrypted contested block ZH2 and blocks allowing a Merkle verification of the contested block to be carried out, in this case ZB3 and ZB4. This challenge may also include a certain number of nodes of a Merkle tree constructed on all the encrypted blocks of encoding Z. These nodes constitute a proof of Merkle which allows the trusted server to verify that the blocks of the dispute (ZH2; ZB3 and ZB4) have not been modified by the recipient.

This dispute is then transmitted (step no. 9 designated by CONST on the ) by the recipient device R to the trusted server T with, for each of the blocks in the dispute, the identification value specific to the recipient device and specific to the file and the block, VR-FBi.

The trust server uses the Merkle proof nodes and the challenge blocks to recalculate the value of the root node of the Merkle tree built on all the encrypted blocks of the Z encoding. The trust server compares then this value recalculated to the value he knows. The trusted server T then proceeds (step no. 10 designated by JUG) to process the dispute. This processing first includes checking the validity of the V-R-FBi of the protest blocks.

In the context of the first embodiment, this verification may include, for each of the challenge blocks, the calculation of a hash value from V-R-FBi transmitted by the receiving device to the trusted server with the challenge and the comparison of the value calculated with the hash value of V-R-FBi previously transmitted (in step no. 4) to the trusted server by the receiving device.

In the context of the second embodiment, this verification may include, for each of the blocks of the dispute, the calculation of a third Diffie-Hellman value based on VR-FBi transmitted by the receiving device R to the trusted server T with contesting and comparing the third Diffie-Hellman value with the first Diffie-Hellman value previously transmitted (in step no. 4) to the trusted server T by the receiving device R. The third Diffie-Hellman value is written for example g ^{V -R- FBi} [p].

In the event of unverified validity, it is because the receiving device lied about a V-R-FBi value transmitted with the challenge (or had transmitted a wrong value during step no. 4). The trusted server then rejects the challenge.

In case of verified validity, the trusted server proceeds as illustrated by the , for each of the protest blocks (here ZB3, ZB4 and ZH2), determining the ID-P-FBi value from the VR-FBi value transmitted by the receiving device with the protest and the ACL input -R-FBi previously transmitted by the proprietary device (step no. 6).

In the first embodiment, this determination can thus consist of ID-P-FBi = ACL-R-FBi + V-R-FBi. In the second embodiment, the trust server T calculates the Diffie-Hellman shared key according to (g^T[p]) ^{VR- FBI}[p])= g^{T * VR- FBI}[p] and the value ID-P-FBi according to for example ID-P-FBi = ACL-R-FBi + g^{T * VR- FBI}[p].

Once the ID-P-FBi values of the contested blocks have been determined, the trusted server decrypts the contested blocks then carries out a Merkle verification of each of the decrypted contested blocks. As illustrated on the , this verification consists for example of verifying that the decrypted disputed block H2 matches a hash value H''2 determined from the other decrypted blocks of the dispute B3, B4.

More particularly, if a contested block corresponds to a leaf node of the first Merkle tree, the Merkle verification of this block may include the calculation of a hash value of a decrypted Merkle verification block (by occurrence a block from the first set) and comparing the calculated value with the decrypted contested block. Furthermore, if a contested block corresponds to a node of the first Merkle tree which is not a leaf node, the Merkle verification of this block may include the calculation of a hash value from blocks of the verification decrypted Merkle blocks (in this case two blocks from the second set, children of the contested block) and the comparison of the calculated hash value with the decrypted contested block.

If the Merkle verification of each of the contested blocks is positive, the challenge is accepted. Otherwise, the challenge is rejected.

Note that in accordance with the invention, the trusted server is only aware of the ID-P-FBi values allowing decryption in the event of a dispute. Furthermore, each block being encrypted with a different ID-P-FBi value, in the event of a dispute the trusted server can only decrypt the blocks which are transmitted to it with the dispute. So it cannot download the file from the storage server and decrypt it completely.

In a possible implementation of the invention, transactions can be chained in the sense that a transaction can be linked to another transaction (which itself can be linked to another transaction) and cannot validly take place only if the other transaction(s) upstream in the chain have been validated.

In the following we take the example of two transactions: a first transaction between a first owner P1 of a file F1 and a first receiver R1 and a second transaction between a second owner P2 of a file F2 and a second receiver R2 . In this implementation of the invention, the ACL values of the second transaction depend on the ACL values of the first transaction. More precisely, the access input of the second receiving device R2 to a block Bj of the second file F2 (denoted ACL-R2-F2Bj) does not depend solely on the encryption key of the block Bj (ie, the identification value of the second owner P2 for this block Bj denoted ID-P2-F2Bj) and the shared secret (exchanged by public key encryption or by Diffie-Hellman) but also of the value of an access entry of the first transaction (in the occurrence of the access input of the first receiving device R1 to a block Bi of the first file F1, denoted ACL-R1-F1Bi). Taking the example of a secret shared by Diffie-Hellman, we then have ACL-R2-F2Bj = ID-P2-F2Bj – g' ^{VR 2 -F 2 B j* T'} [p'] - ACL-R1- F1Bi where ACL-R1-F1Bi = ID-P1-F1Bi - g ^{VR 1 -F 1 Bi *T} [p]. Note that files F1 and F2 may or may not have the same number of blocks. In the general case in fact, a function can be used which takes as input a block number of the second transaction and which returns as output a block number of the first transaction. The most obvious function is: block #X of the second transaction -> X modulo the number of blocks of the first transaction.

We have seen that the ACL value of the second transaction depends on the ACL value of the first transaction. The second recipient must therefore retrieve from the trusted server the ACL value of the first transaction to calculate the decryption key of the blocks exchanged during the second transaction. The advantage of such an approach is that if a transaction is revoked, the trusted server can refuse new access to the ACL value, which automatically invalidates the entire chain that starts from the latter. In other words, the exchange between the second owner P2 and the second receiver R2 can only be done if the exchange between the first owner P1 and the first receiver R1 goes correctly.

A possible use case is that of a data calculation where the first receiver R1 is also the second owner P2. In this use case, during a first transaction a user (first owner) sends source data to the calculation node (first receiver). The compute node performs processing of the source data and, in a second transaction, returns the result (as the second owner) to another user (second receiver). In this situation, the sending of the result can only be valid if the reception of the source data was successful.

The invention is not limited to the method as previously described and also extends to a computing device, comprising a processing unit configured to implement the steps of the method previously described which are implemented by the proprietary device, by the receiving device or by the trusted server. The invention also relates to a computer program product comprising instructions which, when the program is executed by a computer, lead it to implement the steps of the method previously described which are implemented by the proprietary device, by the receiving device or by the trusted server. And the invention also relates to a digital data sharing system, comprising a proprietary device, a receiving device and a trusted server as previously described.

Claims (16)

Method of accessing a file (F) by a receiving device (R), in which an encoding of the file is stored on a storage server (M), the encoding of the file comprising a plurality of encrypted blocks (ZB1, … , ZBn, ZH1, …, ZHm) consisting of a first set of blocks corresponding to a division of the file into blocks (B1, …, Bn) and a second set of blocks corresponding to values of the nodes (H1, … , Hm) of a first Merkle tree (MT1) constructed from the blocks of the first set, each block of the plurality of blocks being encrypted by an identification value specific to a proprietary device (P) and specific to the file and of the block, ID-P-FBi,
the method comprising the implementation of the following steps by the receiving device (R):

• for each block of the plurality of blocks, reception, from a trusted server (T), of an access entry specific to the receiving device and specific to the file and the block, ACL-R-FBi, determination of ID -P-FBi from ACL-R-FBi and decrypting the block using ID-P-FBi;
• constructing a second Merkle tree (MT2) from the decrypted blocks of the first set of blocks of the plurality of blocks and verifying a match of the second Merkle tree with the decrypted blocks of the second set of blocks of the plurality of blocks;
• in the absence of a match:
  • creating a challenge comprising a set of undecrypted blocks of the plurality of blocks (ZB3, ZB4, ZH2), said set consisting of at least one contested block and a block of a Merkle verification of the block disputed; And
  • the transmission, to the trusted server (T), of the challenge and, for each of the blocks of the challenge, of an identification value specific to the receiving device and specific to the file and the block, VR-FBi.

Method according to claim 1, comprising the implementation of the following steps by the trusted server (T):

• verifying the validity of the VR-FBi of the protest blocks;
• in the event of unverified validity, the rejection of the challenge;
• in case of verified validity:
  • for each of the blocks in the dispute, determining ID-P-FBi from VR-FBi and ACL-R-FBi and decrypting the block using ID-P-FBi;
  • a Merkle verification of each of the decrypted contested blocks.

Method according to one of claims 1 and 2, comprising the preliminary steps consisting for the recipient device of carrying out:

• downloading the file encoding from the storage server;
• for each block of the plurality of blocks of the file encoding, determining and transmitting to the VR-FBi trusted server.

Method according to claim 3, further comprising by the proprietary device, for each block of the plurality of blocks, the preliminary steps of:

• reception, from the trusted server, of VR-FBi;
• the generation of ACL-R-FBi, from ID-P-FBi and VR-FBi;
• the transmission, to the trusted server, of ACL-R-FBi.

Method according to one of claims 3 and 4, further comprising the realization by the receiving device, for each block of the plurality of blocks, of an encryption of V-R-FBi by means of a public key of the proprietary device. The method of claim 5, further comprising the proprietary device performing, for each block of the plurality of blocks, a decryption of V-R-FBi using a private key of the owner. Method according to one of claims 3 to 6, further comprising the realization by the receiving device, for each block of the plurality of blocks, of a calculation and transmission to the trusted server of a hash value of V-R-FBi. Method according to claim 7, further comprising the proprietary device performing, for each block of the plurality of blocks before generating ACL-R-FBi, a reception from the trusted server of the hash value of V-R- FBi calculated by the receiving device, a calculation of a hash value from V-R-FBi received from the trusted server and a comparison of the received hash value and the calculated hash value. Method according to one of claims 7 and 8 taken in combination with claim 2, in which the verification, by the trusted server, of the validity of the V-R-FBi of the challenge blocks comprises, for each of the challenge blocks, calculating a hash value from V-R-FBi transmitted by the receiving device to the trusted server with contesting and comparing the calculated value with the hash value of V-R-FBi previously transmitted to the trusted server by the receiving device. Method according to one of claims 1 and 2, comprising the preliminary steps consisting for the recipient device of carrying out:

• downloading the file encoding from the storage server;
• for each block of the plurality of blocks of the file encoding:
  • the determination of VR-FBi;
  • calculating and transmitting to the trusted server a first Diffie-Hellman value based on VR-FBi.

Method according to claim 10, further comprising, through the proprietary device, the preliminary steps of:

• calculation and transmission to the trusted server of a second Diffie-Hellman value; And
• for each block of the plurality of blocks:
  • receiving, from the trusted server, the first Diffie-Hellman value based on VR-FBi;
  • determination of a shared Diffie-Hellman key;
  • generation of ACL-R-FBi, from ID-P-FBi and the Diffie-Hellman shared key;
  • transmission, to the trusted server, of ACL-R-FBi.

Method according to one of claims 10 and 11 taken in combination with claim 2, in which the verification, by the trusted server, of the validity of the V-R-FBi of the challenge blocks comprises, for each of the challenge blocks, calculating a third Diffie-Hellman value based on V-R-FBi transmitted by the receiving device to the trusted server with contesting and comparing the third Diffie-Hellman value with the first Diffie-Hellman value previously transmitted to the trusted server by the receiving device. Method according to one of claims 1 to 12, comprising the steps consisting for the proprietary device of carrying out:

• generating the first set of blocks by splitting the file;
• constructing the first Merkle tree from the first set of blocks;
• generating the second set of blocks from the nodes of the first Merkle tree;
• generating the encoding of the file comprising, for each of the blocks of the first and second set, the encryption of the block by ID-P-FBi;
• transmitting the file encoding to the storage server.

Computer device, comprising a processing unit configured to implement the steps of the method according to claim 1 or those of the steps of the method according to claim 2 which are implemented by the trusted server. Computer program product comprising instructions which, when the program is executed by a computer, cause the latter to implement the steps of the method according to claim 1 or those of the steps of the method according to claim 2 which are implemented by the trusted server. Digital data sharing system, comprising at least one device owner of a file, at least one device receiving the file comprising a processing unit configured to implement the steps of the method according to claim 1 and a trusted server comprising a processing unit configured to implement those of the steps of the method according to claim 2 which are implemented by the trusted server.