WO2023203301A1

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

Info

Publication number: WO2023203301A1
Application number: PCT/FR2023/050568
Authority: WO
Inventors: Bastien CONFAIS; Gustavo ROSTIROLLA; François MARQUES
Original assignee: Inatysco
Priority date: 2022-04-21
Filing date: 2023-04-20
Publication date: 2023-10-26
Also published as: FR3134908A1

Abstract

The invention relates to a method for accessing a set of encrypted blocks comprising data blocks and blocks corresponding to nodes of a first Merkle tree, each block being encrypted by an identification value specific to a proprietary device (P) and specific to the file and the block, ID-P-FBi. A receiving device (R) implements the following steps: - for each block, receiving, from a trusted server (T), 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 by means of ID-P-FBi; - building a second Merkle tree (MT2) from the decrypted blocks and checking that the Merkle trees match; - if there is no match, transmitting, to the trusted server (T), a challenge comprising a set of non-decrypted blocks and, for each of said blocks, an identification value specific to the receiving device and specific to the file and the block, V-R-FBi.

Description

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

TECHNICAL AREA

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.

PRIOR ART

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.

Upstream encryption of the file 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 of the blocks and decrypt them (at least for those of the blocks involved in the fairswap protocol), which risks compromising security.

STATEMENT OF THE INVENTION

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, I D-P-FBi. This method includes the implementation of the following steps by the receiving device:

- for each block of the plurality of blocks, the reception, from a trusted server, of an access entry specific to the receiving device and specific to the file and the block, ACL-R-FBi, the determination of I D-P- FBi from ACL-R-FBi and decrypting the block using I D-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 concordance of the second Merkle tree with the decrypted blocks of the second set of blocks of the plurality of blocks blocks;

- in the absence of a match: o 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 verification of the contested block; and o 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: o verification of the validity of the V-R-FBi of the protest blocks; o in the event of unverified validity, the rejection of the challenge; o in case of verified validity:

■ for each of the blocks in the dispute, the determination of I D-P-FBi from V-R-FBi and ACL-R-FBi and the decryption of the block by means of I D-P-FBi;

■ a Merkle verification of each of the decrypted contested blocks.

- it includes the preliminary steps consisting for the receiving device to carry out: o downloading the encoding of the file from the storage server; o for each block of the plurality of blocks of the file encoding, determination and transmission to the V-R-FBi trusted server.

- it further comprises, through the proprietary device, for each block of the plurality of blocks, the preliminary steps of: o reception, from the trusted server, of V-R-FBi; o the generation of ACL-R-FBi, from I D-P-FBi and V-R-FBi; o 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 VR-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 a transmission to the trusted server of a hash value of VR-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 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.

- the verification, by the trusted server, of the validity of the V-R-FBi of the challenge blocks includes, 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 receiving device to carry out: o downloading the encoding of the file from the storage server; o for each block of the plurality of blocks of the file encoding:

■ determination of V-R-FBi;

■ the calculation and transmission to the trusted server of a first Diffie-Hellman value based on V-R-FBi.

- It further includes, through the proprietary device, the preliminary steps of: o calculation and transmission to the trusted server of a second Diffie-Hellman value; and o for each block of the plurality of blocks:

■ reception, from the trusted server, of the first Diffie-Hellman value based on V-R-FBi;

■ determination of a shared Diffie-Hellman key;

■ generation of ACL-R-FBi, from I D-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 VR-FBi of the challenge blocks includes, for each of the challenge blocks, the calculation of a third Diffie-Hellman value based on VR-FBi transmitted by the receiving device 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: o the generation of the first set of blocks by cutting the file; o the construction of the first Merkle tree from the first set of blocks; o generating the second set of blocks from the nodes of the first Merkle tree; o generating the encoding of the file comprising, for each of the blocks of the first and second set, the encryption of the block by I D-P-FBi; o transmission of the file encoding to the storage server.

BRIEF DESCRIPTION OF THE DRAWINGS

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 :

- Figure 1 is a diagram representing a computer file sharing system between computer devices of several organizations;

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

- Figure 3 illustrates the different blocks constituting the encoding of the file;

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

- Figure 5 illustrates the decryption of the file by the proprietary device;

- Figure 6 illustrates a Merkle proof verification 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. We consider that the entities have previously shared together an access rights management protocol.

Figure 1 schematically represents a system 1 for sharing files between computer devices from several organizations Orgl, Org2, Org3, 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 Orgl, 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 Orgl, Org2, Org3 are, for example, distant from each other, and can belong to different territories. Each of the organizations Orgl, 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 Orgl, Org2, Org3 is independent. For example, organizations want 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. Furthermore, here, organization Orgl has a calculation server 13 and organization Org2 has a calculation server 13'. By "computation server" we mean a server having very significant computing power, typically greater than each of the devices 11, 11', 12, 12', 12'', etc. We wish to be able to selectively put the one and/or the other of these servers 13 and 13' 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 Orgl, Org2, Org3, ... 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 11, 11', 12, 12', 12'', etc.) can access each of the encrypted files fl, f2 , ... without control, for example through a distributed storage system, for example conforming to the IPFS protocol, managing memories M, M', M''. The encrypted files fl, f2, ... 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 Orgl, an owner server 11 and a user server 12. The owner server 11 is configured to create encrypted files and to calculate access entries specific to itself and/or the user server 12 and/ or to other devices present on the N network for these files; the Orgl organization further comprises, in the present example, a sensor Sa intended to collect geophysical and/or environmental data. The Sa sensor can here exchange data with the server 11.

• for the Org2 organization, an owner server 11' and a user server 12'. The owner server 11' is configured to create encrypted files and to calculate access entries specific to itself and/or to the user server 12' and/or to other devices present on the network N for these files; the Org2 organization further comprises, in the present 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'.

• for the Org3 organization, a 12" user server. The Org3 organization does not have significant computing power 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 Orgl. Alternatively, the memory M could be integrated into any of the devices of one of the organizations Orgl, Org2, Org3, etc., or remote from each of these devices.

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

Preferably, when several memories (here M, M', M") are present, a common naming space is used. The memories M, M', M" belong to a distributed storage system, for example produced using help from a collection network.

Preferably, each device 11, 11', 12, 12', ... uses the memory which is available in its local server; thus, in the example illustrated in Figure 1, the device It can interrogate the memory M and the device 11' can interrogate the memory M'. In the Since 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", ..., or on a remote memory. In the present example, the file fl is stored on the memory M of the organization Orgl and the file f2 is stored on the memory M' of the organization Org2. Other files, preferably encrypted or possibly unencrypted, can be saved in memory.

Each of the devices 11, 11', 12, 12', 12'', 13, 13' 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 implementing 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 processes described below.

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

With reference to Figure 2, we consider below a device owner P of a file (for example the server 12 "of the organization Org3) and a recipient device R (for example the calculation server 13 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 in the sense of a fairswap type protocol via a trusted server T.

With reference to Figure 2, 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. Encryption of the file F is more particularly produced as follows, with reference to Figures 3 and 4. The proprietary device P first cuts the file into a plurality of n blocks Bl, 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 comprises a plurality of nodes Hl, H2, ..., Hm which forms a second set of blocks. The blocks Bl, B2, B3, B4, ..., Bn of the first set and the blocks Hl, 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 noted 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, ..., ZBn resulting from the encryption of the blocks Bl, B2, B3, B4, ..., 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 the blocks Hl, 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, I D-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 I DP-FBi = ID(Up, F, Bi). In an exemplary embodiment, the value I DP-FBi is obtained as follows: I DP-FBi = ID(U p, F, Bi) = Up+ sha256(concatenation(Up, F, Bi)), where Up is the key private of the proprietary device, F is the name of the file, Bi is the i-th block of the vector Y, “concatenation” corresponds to the concatenation function and “sha256” corresponds to a known cryptographic hash function operating on a word size of 32-bit. We understand that it is possible to use another hash function here.

Still with reference to Figure 2, 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 Merkle tree.

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 to 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 VR-FBi values and to have to post to the trusted server all of the hash values of these VR-FBi values. In this second embodiment, the VR-FBi value is used to determine a first Diffie-Hellman value, ie 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 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 ^{VR FBi} [p] and transmits this first Diffie-Hellman value to the trusted third party T. Hellman g ^{VR 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(U r, 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 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 VR-FBi values (possibly encrypted using the public key of the proprietary device) and, where applicable, the associated hash values. The proprietary device P, if necessary, decrypts the VR-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 VR-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 I DP-FBi and VR -FBI. This ACL-R-FBi access entry is then transmitted to the trusted server T (step no. 6 in Figure 1). 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 ^{VR 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 ^{VR FBi} [p])T [p] = gV-R-FBi*T [p], generates an access entry specific to the recipient device and file and block specific, ACL-R-FBi, from I DP-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 = I DP -FBi - g ^{VR 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 block I D-P-FBi from ACL-R-FBi.

In the first embodiment, this calculation can thus consist of I DP-FBi = ACL-R-FBi + VR-FBi. In the second embodiment, the receiving device also retrieves 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 in Figure 1) at decryption of the corresponding block. Figure 5 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 Bl, ..., 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 Hl, ..., 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.

In case of a match, the decrypted blocks correspond to the expected file. The file can then be reconstructed by bringing together the decrypted blocks Bl, ..., 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 Figure 5, 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 in the figure

1) by the receiving device R to the trusted server T with, for each of the blocks of the dispute, the identification value specific to the receiving 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 the event of verified validity, the trusted server proceeds as illustrated in Figure 6, for each of the dispute blocks (here ZB3, ZB4 and ZH2), to determine the value I D-P-FBi from the value V-R -FBi transmitted by the receiving device with the challenge and the ACL-R-FBi input previously transmitted by the owner device (step no. 6).

In the first embodiment, this determination can thus consist of ID-P-FBi = ACL-R-FBi + VR-FBi. In the second embodiment, the trusted 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 for example I DP-FBi = ACL-R -FBi + g ^T * ^{VR FBi} [p].

Once the I D-P-FBi values of the contested blocks have been determined, the trusted server decrypts the contested blocks and then carries out a Merkle verification of each of the decrypted contested blocks. As illustrated in Figure 6, this verification consists for example of verifying that the decrypted contested 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 I D-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, the 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 what follows we take the example of two transactions: a first transaction between a first owner PI of a file Fl and a first recipient RI and a second transaction between a second owner P2 of a file F2 and a second recipient 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 RI to a block Bi of the first file Fl, denoted ACL-Rl-FIBi). Taking the example of a secret shared by Diffie-Hellman, we then have ACL-R2-F2Bj = ID-P2- F2Bj - g'V-R2-F2Bj*T- [ _p . ACL-Rl-FIBi where ACL-Rl-FIBi = I D-Pl-FIBi - g ^v ' ^R1 ' ^F1Bi * ^T [p], Note that files Fl 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 PI and the first receiver RI goes correctly.

A possible use case is that of a data calculation where the first receiver RI 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 worker performs some processing of the source data and, in a second transaction, returns the result (as the second owner) to another user (second recipient). 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 recipient device and a trusted server as previously described.

Claims

1. 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 (Bl, Bn) and a second set of blocks corresponding to values of the nodes (H 1, 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 the block, I D-P -FBi, the method comprising the implementation of the following steps by the receiving device (R):

- for each block of the plurality of blocks, the 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, the determination of I D-P-FBi from ACL-R-FBi and decrypting the block using I D-P-FBi;

- the construction of a second Merkle tree (MT2) from the decrypted blocks of the first set of blocks of the plurality of blocks and the verification of a concordance 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: o the creation of a dispute 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 d 'a Merkle verification of the contested block; and o 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.

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

- verification of the validity of the V-R-FBi of the protest blocks;

- in the event of unverified validity, rejection of the challenge;

- in the event of verified validity: o for each of the blocks in the dispute, the determination of I D-P-FBi from V-R-FBi and ACL-R-FBi and the decryption of the block using ID-P-FBi; o a Merkle verification of each of the decrypted contested blocks.

3. Method according to one of claims 1 and 2, comprising the preliminary steps consisting for the receiving device to carry out: downloading the encoding of the file from the storage server; for each block of the plurality of blocks of the file encoding, determining and transmitting to the trusted server of V-R-FBi.

4. Method according to claim 3, further comprising by the proprietary device, for each block of the plurality of blocks, the preliminary steps of: o reception, from the trusted server, of V-R-FBi; o the generation of ACL-R-FBi, from I D-P-FBi and V-R-FBi; o the transmission, to the trusted server, of ACL-R-FBi.

5. Method according to one of claims 3 and 4, further comprising the production 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 .

6. Method according to claim 5, further comprising carrying out by the owner device, for each block of the plurality of blocks, a decryption of VR-FBi by means of a private key of the owner.

7. 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 a transmission to the trusted server of a value of hash of V-R-FBi.

8. Method according to claim 7, further comprising 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 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.

9. 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 blocks of challenge, calculating 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.

10. Method according to one of claims 1 and 2, comprising the preliminary steps consisting for the receiving device to carry out: downloading the encoding of the file from the storage server; for each block of the plurality of blocks of the file encoding: o determining V-R-FBi; o calculating and transmitting to the trusted server a first Diffie-Hellman value based on V-R-FBi.

11. 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: o reception, from the trusted server, of the first Diffie-Hellman value based on VR-FBi; o determination of a shared Diffie-Hellman key; o generation of ACL-R-FBi, from I DP-FBi and the Diffie-Hellman shared key; o transmission, to the trusted server, of ACL-R-FBi.

12. 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 blocks of challenge, calculating a third Diffie-Hellman value based on V-R-FBi transmitted by the receiving device to the trusted server with the challenge and comparing the third Diffie-Hellman value with the first Diffie-Hellman value previously transmitted to the trusted server by the receiving device.

13. Method according to one of claims 1 to 12, comprising the steps consisting for the proprietary device to be produced: generating the first set of blocks by cutting 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 I D-P-FBi; transmitting the file encoding to the storage server.

14. 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.

15. Computer program product comprising instructions which, when the program is executed by a computer, lead it 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 implemented by the trusted server.

16. 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.