method of certifying sharing of a file, method of confirming sharing of a file and corresponding devices

Abstract

Method for certifying the sharing of a file, method for confirming the sharing of a file and corresponding devices A method for certifying by a first device (A) the sharing of a file (file) to at least one second device (B), is implemented by said first device (A) and comprises: - a reception (E2), from said second device (B), of an acknowledgment of receipt (ack_file) by the second device of the encrypted file (c_file), - a storage (E3), in a digital storage space (BDD1), of a first data item (d1) encrypted and decipherable by the second device, and of said acknowledgment of receipt (ack_file) of the encrypted file (c_file), - a reception (E6), from said second device, of a second data item (d2), - a verification (E7) whether the second data item (d2) is equal to the first data item (d1), and, in the event of a positive verification,triggering (E8) a transmission to the second device (B) of a decryption key (k_file) of the encrypted file (c_file). Figure for the abstract: figure 1,

Description

Title of the invention: Method for certifying the sharing of a file, method for confirming the sharing of a file and corresponding devices 1. Field of the invention

[0001] The invention relates to the field of digital file sharing. More specifically, the invention aims at a file sharing certification solution. 2. Prior art

[0002] With the increasing digitalization of commerce, more and more contractual exchanges are taking place partially or completely digitally. During these exchanges, a contract must therefore be signed.

[0003] During a face-to-face signing of a paper contract, at least one copy per party of a contract is signed. Before this signing, each party can ensure that the copies to be signed are identical, and that the other party(ies) have received them. Each signing party can also verify the identity of the other signing parties.

[0004] However, when the contract is in digital form, this verification of the identical nature of the (digital) copies of the contract is not possible. A fortiori, when the signing of such a digital contract is carried out remotely, it is not possible to verify the identity of each party to the contract. There is currently no reliable and easy-to-implement solution for remotely verifying that a contract has been received by a signatory party. Furthermore, there is also no reliable way of storing the result of such a verification, so as to be able to prove that such a contract has been obtained by the signatory parties, in the event of a dispute.

[0005] The invention improves the situation. 3. Statement of the invention

[0006] To this end, the invention proposes a method for certification by a first device of sharing a file with at least one second device, the method being implemented by said first device and comprising:

[0007] - a reception, from said second device, of an acknowledgment of receipt by the second device of the encrypted file,

[0008] - storage, in a digital storage space, of a first piece of data encrypted and decipherable by the second device, and said acknowledgment of receipt of the encrypted file,

[0009] - a reception, from said second device, of a second piece of data,

[0010] - a check of whether the second data is equal to the first data, and, if positive verification, triggering a transmission to the second device of a decryption key for the encrypted file.

[0011] Thus, thanks to this certification process, the first device (device "certifying" the sharing of the file to be shared) is able to certify the correct reception of the encrypted file by the second device for which the file to be shared is intended ("recipient" device). This certification is carried out using the comparison between the first data item and the second data item, equality between these two data items meaning that the identity of the recipient device is indeed verified. Once this guarantee is obtained, the first device provides, directly or indirectly, to this second recipient device the decryption key allowing the file to be shared to be decrypted.

[0012] The fact of registering, within a digital storage space (database, register, blockchain, etc.), the acknowledgment of receipt and the first data advantageously makes it possible to keep a trace of the correct reception, by the second device, of the file to be shared in encrypted form.

[0013] At the time of transmission of the first encrypted data, the first device has knowledge of the first data "in clear", but not the second device. Thus, the comparison by the first device between the first data and the second data, which only the second recipient device can obtain by decrypting the first encrypted data, allows the first device to ensure the identity of the recipient device.

[0014] Thus, this new type of method allows a first device to ensure the identity of the second device for which the encrypted file is intended. This method also allows the first device to verify that the second device actually holds, thanks to the acknowledgment of receipt, a copy of the encrypted file. The first device, thanks to this method, can verify the validity of these two conditions (identity and good reception) before transmitting the decryption key to the second device. Storing this first encrypted data and the acknowledgment of receipt of the encrypted file in the first database makes it possible to keep a record of this reception.

[0015] According to an exemplary embodiment, the first device is an orchestrator device, providing a user with a file sharing certification service. The orchestrator device thus plays a role of third-party equipment during the sharing of the file between a sending device of a sender and the recipient device.

[0016] According to an exemplary embodiment, the first device is a sending device seeking to certify the sharing of a file between itself and the recipient device.

[0017] According to an exemplary embodiment, the first device obtains a first digest of the encrypted file, and wherein the acknowledgment of receipt of the encrypted file comprises a second digest of the encrypted file as obtained by the second device,

[0018] the reception of the first digest triggering a verification of whether said first digest is equal to the second digest, and, in the event of a positive verification, a triggering of said storage, in the first digital storage space, of said first encrypted data and of at least the first digest.

[0019] Thus, the first device can verify with certainty that the second device has indeed received the encrypted file, thanks to this comparison of the digests (“hash” in English). Due to the properties of the digest, it can play the role of an acknowledgment of receipt, by the second device, of said encrypted file. The result of this verification can be entered in the first database, possibly at the same time as the first information and the first encrypted data and the acknowledgment of receipt comprising said digest.

[0020] Using a digest further allows the first device to ensure the integrity of the encrypted file as received by the second device.

[0021] According to an exemplary embodiment, the certification method further comprises:

[0022] - a reception, from the second device, of an acknowledgment of receipt of said decryption key, and

[0023] - storage, in a second digital storage space, of said acknowledgment of receipt of said decryption key.

[0024] Thus, the first device can also store in the second database proof that the second recipient device has indeed received the decryption key, making it possible to decrypt the encrypted file for which the first device has already obtained acknowledgment of receipt from the second device.

[0025] The storage of this second acknowledgment of receipt may be separate from the first acknowledgment of receipt, and triggered immediately after the comparison of the first data (or session tokens). This makes it possible to generate proof of receipt of the encrypted file separate from proof of receipt of the key.

[0026] Alternatively, the first database and the second database are the same database. The storage of the two acknowledgments of receipt may optionally be simultaneous. Thus, the first device generates a unique proof of both the receipt by the second device of the encrypted file and its decryption key.

[0027] This thus makes it possible to verify, in the future, in a transparent and lasting manner, this guarantee of reception that the first device has entered in the database.

[0028] According to an exemplary embodiment, the acknowledgment of receipt of the decryption key comprises a digest of a decrypted file, and wherein the storage of said acknowledgment of receipt of the decryption key comprises the verification of whether the digest of the decrypted file from the second device is identical to a digest of the decrypted file that the first device determines using the encrypted file and the decryption key.

[0029] Thus, by comparing the digests of the decrypted file, the first device can guarantee that the second device has indeed obtained the decryption key and, more importantly, that the decryption key has indeed allowed the encrypted file to be decrypted. In fact, this verification and the recording of the digest of the decrypted file makes it possible to keep a secure and reliable record of the correct reception of the file by the second device.

[0030] According to an exemplary embodiment, at least one digital storage space is a blockchain.

[0031] The fact that the storage of the first data and the acknowledgment of receipt of the encrypted file, possibly the acknowledgment of receipt of the decryption key, is carried out in a blockchain advantageously makes it possible to obtain proof whose registration is transparent and tamper-proof. The proof thus stored, or registered, is thus available without time limit, to third parties. This also means that the first device cannot subsequently reverse a certification registered in the blockchain.

[0032] The invention also relates to a method for confirming sharing to at least one second device, the method being implemented by the second device having obtained an encrypted file and comprising:

[0033] - a transmission, to a first device, of an acknowledgment of receipt of the encrypted file,

[0034] - a transmission, to the first device, of a second piece of data obtained by decryption of a first encrypted data item obtained by the second device following the transmission of the acknowledgment of receipt of the encrypted file,

[0035] - a reception, from the first device, of a decryption key of the encrypted file.

[0036] According to an exemplary embodiment, the sharing confirmation method further comprising:

[0037] - obtaining, from the encrypted file, a digest of it, and

[0038] - a transmission, to the first device, of the digest thus obtained.

[0039] According to an exemplary embodiment, the sharing confirmation method comprises in besides :

[0040] - a transmission, to the first device, of an acknowledgment of receipt of said decryption key.

[0041] According to an exemplary embodiment, the acknowledgment of receipt of the decryption key comprises a digest of the decrypted file obtained by the second device using the encrypted file and the decryption key.

[0042] The invention further relates to a first device for certifying a sharing of a file to at least one second device, the first device comprising:

[0043] - means for receiving, from said second device, an acknowledgment of reception by the second device of the encrypted file,

[0044] - means for storing, in a digital storage space, a first data encrypted and decipherable by the second device, and said acknowledgment of receipt of the encrypted file,

[0045] - means for receiving, from said second device, a second given,

[0046] - means for verifying whether the second data item is equal to the first data item, and, in the event of a positive verification, means for triggering a transmission to the second device of a decryption key for the encrypted file.

[0047] The invention further relates to a second device for confirming a sharing of a file, the method being implemented by the second device having obtained an encrypted file and comprising:

[0048] - means for transmitting, to a first device, an acknowledgment of receipt of the encrypted file,

[0049] - means for transmitting, to the first device, a second data obtained by decrypting a first encrypted data item obtained by the second device following the transmission of the acknowledgment of receipt of the encrypted file,

[0050] - means for receiving, from the first device, a key of decryption of the encrypted file.

[0051] The invention further relates to a computer program product comprising program code instructions for implementing a method as set forth above, when executed by a processor.

[0052] Such a computer program may be recorded on a computer-readable recording medium. This recording medium may be any entity or device capable of storing the program. For example, the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a USB key or a hard disk.

[0053] On the other hand, such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the computer program it contains is remotely executable. The program according to the invention may in particular be downloaded over a network, for example the Internet.

[0054] Alternatively, the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method which is the subject of the aforementioned invention. 4. List of figures

[0055] Other characteristics and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which: - [Fig. 1] represents a file certification method and a file sharing confirmation method according to one embodiment of the invention; - [Fig.2] represents a particular example of the processes of [Fig.l]; - [Fig.3] represents a particular example of the processes of [Fig.2]; - [Fig.4] represents a particular example of the processes of [Fig.3]; - [Fig.5] represents a particular example of the processes of [Fig.3]; - [Fig.6] represents a first device according to an embodiment of the invention; - [Fig.7] represents a second device according to an embodiment of the invention. 5. Detailed description

[0056] 5.1. General principle

[0057] Reference is made to [Fig.l], which represents the main steps of a file certification method and a file sharing confirmation method according to one embodiment of the invention.

[0058] The general principle of the invention is to provide a method of certification, by a first device A, of sharing with a second device B, of a file to be shared, hereinafter called “file”.

[0059] This method makes it possible, according to at least one embodiment, to verify the correct reception of the file by the second device and to ensure the identity of the second device. This method makes it possible, for example, to reproduce, digitally and between two remote terminals, the correct properties of a face-to-face signature of a paper contract.

[0060] Although the reason for the invention arises from the constraints of contractual exchanges between parties, it is not limited to this contractual context alone. Thus, the file can be any type of digital file, in particular text or multimedia.

[0061] Prior to steps E1 to E9 described below, the second device obtains an encrypted file c_file. This encrypted file c_file may have been transmitted by the first device A, directly or indirectly, to said second device B. Alternatively, the second device B may have obtained this encrypted file c_file by another means, for example via a sharing server or any other third-party equipment, or from a device having generated this file, also called the sending device.

[0062] The encrypted file c_file is associated with a decryption key (k_file), which, at this stage, is not held by the second device B. The first device A may, for example, have encrypted the file to be shared itself, or alternatively have obtained an encrypted file / decryption key pair provided by third-party equipment. Alternatively, the first device A may only have the decryption key k_file in its possession, or may even hold neither the decryption key nor the encrypted file.

[0063] In a step E1, the second device B transmits, to the first device A, an acknowledgment of receipt ack_file of the encrypted file c_file. Different examples of acknowledgment of receipt will be described below.

[0064] In a step E2, the first device A receives, from the second device B, said acknowledgment of receipt ack_file by the second device B of the encrypted file c_file.

[0065] In a step E3, the first device A obtains a first data item dl. Different ways of obtaining this first data item dl will be described below. The first device A can, for example, generate the first data item dl. Then, the first device A can encrypt the first data item dl, so that the second device B can decrypt it. Then, the first device A can transmit, to a server hosting a first digital storage space BDD1, said first encrypted data item c_dl and the acknowledgment of receipt ack_file of the encrypted file c_file.

[0066] The encryption of the first data item dl so that the second device B can decrypt the first encrypted data item c_dl can for example be carried out using a public key kpb_B of the second device B, the latter being able to decrypt this first encrypted data item c_dl with a private key kpv_B. Alternatively, the encryption can be symmetrical, i.e. carried out with an encryption key held by the first device A and the second device B.

[0067] In a step E4, the first data dl, encrypted, is stored in the first digital storage space BDD1.

[0068] In a step E5, the second device B obtains the first data item dl in encrypted form c_dl. After obtaining this first encrypted data item c_dl, the second device B decrypts it, so as to obtain a second data item d2. The second device B then transmits this second data item d2 to the first device A. In principle, if the second device B is the device for which the file to be shared is intended, this second data item d2 is assumed to be identical to the first data item dl, known to the first device A.

[0069] The second device B may have directly received this first encrypted data c_dl from the first device A. Alternatively, the second device B may have obtained this first encrypted data c_dl from third-party equipment, the transmission of this first encrypted data c_dl being, for example, triggered by the storage thereof in the first digital storage space. These different examples will be described below.

[0070] The first device A receives this second data d2 in a step E6.

[0071] In a step E7, the first device A checks whether the second data item d2 is equal to the first data item d1. In the event of a positive verification, this effectively means that the second device B is indeed the second device for which the file is intended. When this verification is positive, the decryption key k_file is transmitted in a step E8 to the second device B, the latter receiving it in a step E9. This transmission of the decryption key can be carried out directly by the first device A, or via third-party equipment. Alternatively, the verification of the identity between the first data item d1 and the second data item d2 can trigger the transmission of a message to third-party equipment which in turn transmits the decryption key k_file to the second device B.

[0072] Thus, thanks to the certification (first device A side) and confirmation (second device B side) methods for sharing a file according to the embodiment described above, the first device A is able to verify the correct reception of an encrypted file, but also to verify the identity of the second device B before transmitting the decryption key to it, while keeping a trace of the exchanges during the sharing. The first data dl thus plays the role of identifier, potentially unique and specific to a sharing session, allowing the second device B to recover the decryption code from the first device A.

[0073] A simultaneous storage of the first encrypted data item c_dl and the acknowledgment ack_file has been described above. The method described allows, as a variant, storage by the first device A of the first encrypted data item c_dl in a manner decoupled from the reception of the acknowledgment ack_file from the second device B. In such a case, the second device B can obtain the first data item encrypted c_dl (directly from the first device A, or from a third-party device), and transmit the second data d2. In parallel (or before, or after), the second device B can obtain the encrypted file c_file, and transmit to the first device A the acknowledgment ack_file, the first device A storing it in the first digital storage space.

[0074] In an exemplary embodiment, the sharing can be carried out with several recipient terminals. In such a case, the first encrypted data c_dl can be encrypted symmetrically, with a decryption key common to several recipient terminals. Thus, each of these terminals is able to decrypt the first encrypted data c_dl. It is also possible to use a symmetric encryption key by a second device. Alternatively, the first data dl can be encrypted into a plurality of first encrypted data c_dl_Bl, c_dl_B2... c_dl_Bn for n recipient terminals B1... Bn with n integer, each first encrypted data c_dl_Bi (with i integer) being encrypted with a public key kpb_Bi of the second device Bi. It is possible to combine symmetric and asymmetric encryption cases.

[0075] Subsequently, the first device A is called the certifying device, and the second device B is called the recipient device of a file to be shared. The certifying device may in particular be integrated into a device sending the file to be shared, or separate from the device sending the file to be shared.

[0076] 5.2. Description of a first example of embodiment of the invention

[0077] Reference is made to [Fig.2], which represents a first example of implementation of the file certification and file sharing confirmation processes.

[0078] In the embodiment described here, the first digital storage space is a database BDD1, hosted on a third-party server. Alternatively, the certifying device A can itself host this first database.

[0079] In a step F1, the certifying device A transmits, directly or indirectly, an encrypted version c_file of the file to be shared, to said recipient device B. The encrypted file c_file is associated with a decryption key (k_file) held by the certifying device A. The certifying device A can either encrypt the file to be shared itself, or have obtained an encrypted file / decryption key pair provided by third-party equipment.

[0080] In a step F2, the recipient device B receives the encrypted file c_file from the certifying device A. During this step, the certifying device A does not transmit the decryption key k_file, which it retains.

[0081] In a step F3, the recipient device B transmits, to the certifying device A, an acknowledgment of receipt ack_file of the encrypted file c_file. Different examples of acknowledgment of receipt will be described below.

[0082] In a step F4, the certifying device A receives, from the recipient device B, said acknowledgment of receipt ack_file of the encrypted file c_file.

[0083] Sharing occurs during a sharing session, i.e. a logical and / or temporal window whose object relates at least to the sharing of this file.

[0084] In a step F5, the certifying device A determines a first data item d1 identifying the current sharing session. The first data item d1 may comprise several deterministic and / or random pieces of information, as will be seen below, the important thing according to this exemplary embodiment being that this first data item d1 uniquely identifies the current session, and that only the certifying device A can have access to its determination as long as it does not transmit it to other terminals.

[0085] In a step F6, the certifying device A encrypts the first data item dl using a public key kpb_B of the recipient device B. Then, the certifying device A transmits, to a server hosting a first database BDD1, said first encrypted data item dl and the acknowledgment of receipt ack_file of the encrypted file c_file.

[0086] In a step F7, the first data dl, encrypted, is stored in the first database BDD1 by this server.

[0087] In a step F8, the certifying device A transmits, directly or indirectly, the first encrypted data c_dl with the public key kpb_B to the destination device B. When the transmission is direct, the certifying device A can transmit this first encrypted data c_dl as such to the destination device B, possibly via third-party equipment.

[0088] When the transmission is indirect, the certifying device A can transmit to the recipient device B information allowing it to obtain this first data dl, such as for example an address or an identifier allowing the recipient device B to obtain this information in the first database BDD1. This identifier can for example be a registration identifier id_tag_c_dl resulting from a registration of the first encrypted data c_dl in a block chain, as will be seen below.

[0089] In a step F9, the recipient device B receives the first data item d1 encrypted using its own public key kpb_B. The recipient device B decrypts this first data item d1 encrypted with its private key kpv_B, so as to obtain a second data item d2. In principle, if the recipient device B is the device for which the file to be shared is intended, this second data item d2 is assumed to be identical to the first data item d1, in the possession of the certifying device A.

[0090] In a step F10, the recipient device B transmits this second data d2 to the certifying device A. As for the other transmissions described above, This can be direct or indirect. The certifying device A receives this second data d2 in a Fil step.

[0091] In a step F12, the certifying device A checks whether the second data d2 is equal to the first data d1. In the event of a positive verification, this effectively means that the destination device B is indeed the destination device for which the file is intended. When this verification is positive, the certifying device A transmits in a step F13, to the destination device B, the decryption key k_file used to decrypt the encrypted file c_file previously transmitted to the destination device B. The destination device B receives this decryption key k_file in a step F14.

[0092] 5.3 Acknowledgment of receipt of the encrypted file

[0093] The ack_file acknowledgment can be a message signed by the recipient device. Thus, the certifying device is able, upon receipt of the ack_file acknowledgment, to attest its authenticity, which offers good guarantees as to the identity of the recipient device.

[0094] In an exemplary embodiment, the acknowledgment ack_file may comprise or take the form of a digest hash_B of the encrypted file c_file received by the recipient device B. More specifically, the recipient device B may, in step F2, apply a hash function F1 to the encrypted file c_file, resulting in a digest hash_B.

[0095] For its part, before or upon receipt of the digest hash_B, the certifying device A can apply this same hash function F1 to the encrypted file c_file of which it holds a copy, and obtain a second digest hash_A. The certifying device A can then compare the digest hash_B, which it received from the recipient device B, and the digest hash_A which it obtained itself. If these two digests hash_A and hash_B are identical, then the certifying device A obtains the guarantee that the recipient device B is indeed in possession of a version of the encrypted file c_file identical to its own.

[0096] This makes it possible, for example, to ensure that the encrypted file c_file has not been altered during its transmission to the destination device. Indeed, an alteration of even a single byte of the encrypted file c_file would result in a hash_B digest different from the hash_A digest, due to the mathematical properties of the FL hash function.

[0097] The certifying device A can condition the storage of the first encrypted data kpb_B(dl) in the first database (step F7) on the fact that these two digests hash_A and hash_B are identical. The storage of this digest hash_B = hash_A can be carried out in clear on the database BDD1, since by the mathematical properties of the hash function, it is not possible from this digest to go back to the encrypted file c_file.

[0098] Thus, in this example of acknowledgment of receipt, the hash_B digest transmitted by the recipient device B can play a dual role, both as an acknowledgment of receipt of the encrypted file and as proof of the integrity of its transmission.

[0099] It is possible to envisage, as an alternative to a hash function, a CRC (Cyclic Redundancy Check or cyclic redundancy code) type function to verify the integrity of the encrypted file transmitted to the recipient device B. Other types of acknowledgment of receipt can also be envisaged.

[0100] 5.4 Key Acknowledgment

[0101] Reference is made to [Fig.3], which describes an improved variant of the method of [Fig.2],

[0102] Steps F1 to F14 are similar to those described above, in relation to [Fig.2],

[0103] In the method of [Fig.2], the recipient device, in a step F15, transmits, to the certifying device A, an acknowledgment of receipt ack_key of the decryption key k_file that it received in step F14. The certifying device A receives this acknowledgment of receipt ack_key in a step F16.

[0104] In a step F17, the certifying device A transmits the acknowledgment ack_key of the decryption key to a server hosting a second database BDD2. This acknowledgment ack_key of the decryption key is thus stored in the second database in a step F18.

[0105] It should be noted that the first database BDD1 and the second database BDD2 may be the same database, or alternatively two separate databases. In the case where these two databases are separate, they may be hosted on the same server, or on two separate servers. Alternatively, as will be described below, one and / or the other of these two databases may be a blockchain, stored in a decentralized manner.

[0106] The fact that the certifying device A stores in the second database BDD2 the acknowledgment of receipt ack_key of the decryption key, which was transmitted to it by the recipient device B, makes it possible to keep track of the fact that the latter has indeed obtained the decryption key.

[0107] This acknowledgment ack_key may comprise or take the form of a message signed by the recipient device B.

[0108] Alternatively, this acknowledgment of receipt ack_key may take the form of a digest hash_B' of the decrypted file, this digest hash_B' being obtained by the recipient device B from the decrypted file using the decryption key k_file that it received in step F14. Upon receipt of this digest hash_B', the device Certifier A can obtain a hash_A' digest of the decrypted file using the decryption key (which it has), then compare the two digests hash_A' and hash_B'. If these two digests are identical, then Certifier A can be certain that the recipient device has the decrypted file in its possession. This verification can be a condition for the Certifier to write the acknowledgment of receipt of the decryption key in the second database BDD2.

[0109] Thus, the storage of this acknowledgment of receipt of the decryption key in the form of a digest of the decrypted file makes it possible to verify, subsequently and by third parties such as by the certifying device A, that the file has indeed been decrypted by the recipient device B. This also makes it possible to verify the integrity of the decrypted file, which is very advantageous, especially if the integrity of the encrypted file c_file has not been verified beforehand.

[0110] The storage of the ack_key acknowledgment may be separate from that of the first ack_file acknowledgment. This makes it possible to generate proof of receipt of the encrypted file separate from proof of receipt of the key.

[0111] Alternatively, the first database and the second database are the same database. The storage of the two acknowledgments of receipt may possibly be simultaneous, or even concatenated. In this case, the certifying device A may carry out step F6 of storing the first data item after receiving the acknowledgment of receipt ack_key of the decryption key, and concatenate the two acknowledgments of receipt ack_file and ack_key. Thus, the first device generates a single proof of both the receipt by the second device of the encrypted file and its decryption key.

[0112] 5.5 Use of a blockchain as digital storage space

[0113] In one embodiment, the first and / or the second digital storage space is a blockchain. The step(s) of storing a data item d (such as for example the encrypted data item c_dl, the acknowledgment ack_file or the acknowledgment ack_key) within such a blockchain may then comprise, on the certifying device A side: - A registration of the data within the blockchain, in the form of an entry hereinafter referred to as a “tag”, - A reception, in response to this registration, of a registration identifier id_tag_d of the data d thus registered.

[0114] Thus, optionally, instead of transmitting the first encrypted data c_dl to the recipient device B, it is possible to transmit the registration identifier id_tag_c_dl of the latter to the recipient device B. Recipient device B can then obtain, using the registration identifier id_tag_c_dl, the first encrypted data c_dl within the blockchain.

[0115] The registration of the first encrypted data c_dl within the blockchain can trigger the automatic transmission of a notification, intended for the recipient device B, comprising the registration identifier id_tag_c_dl of the first encrypted data c_dl. Thus, in this case, the certifying device A does not need to transmit the first encrypted data c_dl itself to the recipient device B. The transmission of such an automatic notification can be carried out using an address of the recipient device B attached to the first encrypted data c_dl and to the acknowledgment of receipt ack_file that the certifying device A has registered in the blockchain.

[0116] This automatic notification transmission can also be implemented by a server hosting a traditional database.

[0117] It is possible to use, instead of a blockchain, a third-party service providing a database serving as a register, provided that this register is tamper-proof, transparent and accessible to third parties.

[0118] 5.6 Content of the first data

[0119] The first data dl may include a token. Such a token, token_A, may be generated randomly. Thus, only the certifying device A holds this token.

[0120] In addition, the first data dl may comprise at least one of the following session elements: - a unique sharing identifier, for example a URL where the encrypted file is stored); - a timestamp, i.e. a date and / or time of the current sharing session; - an address of the recipient device B, such as an email address, an IP address, a MAC address, etc.

[0121] Alternatively, at least some of these elements may not be included in the first data item dl — which is stored on the first database by being encrypted with the public key kpb_B of the recipient device B — but concatenated with the first encrypted data item dl. Thus, these elements can be freely inspected by a third party without needing the private key kpv_B of the recipient device B. These third parties can thus ascertain the date of sharing and / or the recipient of the sharing.

[0122] In the case where an address of the destination device B is concatenated with the first encrypted data c_dl, this address of the destination device B can be used to carry out the issuance of an automatic notification of a registration in a blockchain or a database as explained above.

[0123] As an alternative to random generation, the token token_A can be generated by concatenating one or more of the session elements listed above, then applying a second hash function F2, distinct from the hash function Fl applied to the encrypted file c_file, to which the certifying device has access. Thus, in this case as in the case of random generation, only the certifying device A has knowledge of the method for generating the first data dl.

[0124] 5.7 Certifying device as a service provider

[0125] Reference is made to [Fig.4]. Steps F1 to F18 are, unless otherwise stated, similar to those described above.

[0126] In this exemplary embodiment, the certifying device A is an orchestrator device, also called a data manager. The orchestrator device A provides users with a sharing certification service. Here, a user of a sending device U wishes to share a file with the receiving device B.

[0127] In a step Gl, the sending device U sends, to the orchestrator device A, a sharing request reql. The sharing request may include the file, the encrypted file, an identifier of the encrypted file, and / or a sharing link for the file (encrypted or not), the latter being stored on a third-party sharing server.

[0128] Alternatively, the sharing request reql may have more generic content and not contain information relating to the file to be shared as such. For example, the orchestrator device A may make available to the sending device U a standard predetermined file sharing service, the sending device U simply issuing a request containing an identification of the recipient device B, the file to be shared already being determined.

[0129] The orchestrator device A receives this sharing request reql, and triggers the sharing certification process described above.

[0130] When the orchestrator device A receives the acknowledgment ack_file of the encrypted file, in step F4, the orchestrator device A transmits in a step G3 this acknowledgment ack_file to the sending device U. Alternatively, the orchestrator device A can transmit to the sending device U an acknowledgment ack_ack_file of the acknowledgment ack_file of the encrypted file c_file. The sending device receives this acknowledgment ack_ack_file in a step G4 and can see that the encrypted file has thus been received by the receiving device B. The performance of step G3 of transmitting the acknowledgment of the encrypted file can be conditioned on the verification of the equality between the data d1 and d2 carried out in step F5.

[0131] In the case where an acknowledgment ack_key of the decryption key k_file is returned by the recipient device B to the orchestrator device A, in step F16, the orchestrator device A transmits in a step G5 this acknowledgment ack_key to the sender device U. Alternatively, the orchestrator device A can transmit to the sender device U an acknowledgment ack_ack_key of the acknowledgment ack_key of the decryption key k_file. The sender device receives this acknowledgment ack_ack_key in a step G6 and can see that the decryption key has thus been received by the recipient device B.The performance of step G5 of transmitting the acknowledgment of receipt of the decryption key may be conditioned on the verification of the equality between a digest hash_A' of the unencrypted file determined by the orchestrating device A internally and a digest hash_B' of the unencrypted file determined by the recipient device B following the reception of the decryption key. If the orchestrating device A does not have the unencrypted file (either directly or by having the encrypted file and the decryption key available), the verification of the equality of the digests may be carried out by the sending device U. .

[0132] The two acknowledgments ack_ack_file and ack_ack_key can be grouped into a single acknowledgment reporting the successful receipt, by the recipient device B, of all the elements (encrypted file, decryption key) enabling it to obtain the decrypted file.

[0133] As explained above, in a particular embodiment, the acknowledgment ack_ack_file may comprise or take the form of a registration identifier id_tag_ack_file resulting from the registration of the acknowledgment ack_file in a blockchain. Thus, this acknowledgment being registered in such a blockchain, it is possible to keep a transparent and tamper-proof trace that any third party can consult without time limit. In such a case, the sending device U receives this registration identifier id_tag_ack_file, and obtains the acknowledgment ack_file from the blockchain. This obtaining of the acknowledgment ack_file of the encrypted file may also be implemented to obtain the acknowledgment of the decryption key.

[0134] 5.8 Certifying device as issuing device

[0135] In another exemplary embodiment of the invention, the certifying device is a device wishing to share a file, also called a transmitting device. It may for example be a user device such as a computer or smartphone. Alternatively, this transmitting device may for example be a server of a company, this server generating and transmitting contracts to subscribe to a service or a product. In both cases, according to this exemplary embodiment of the invention, a same device plays both the role of certifying device and the role of issuing device.

[0136] 5.9 Registration in a blockchain by the recipient device

[0137] Reference is made to [Fig.5], which represents an alternative to the method of [Fig.3]. Steps F1 to F16 are, unless otherwise stated, similar to those described above.

[0138] In this embodiment, the digital storage space is preferably a BC blockchain.

[0139] The recipient device B, before sending the acknowledgment ack_file of the encrypted file to the certifying device (step F3), can according to this exemplary implementation write in a step H1 the acknowledgment ack_file in a chain of blocks BC. The acknowledgment ack_file is written in a step H1'. A registration identifier id_tag_ack_file is generated in a step H2'. The recipient device B receives in response the registration identifier id_tag_ack_file in a step H2.

[0140] The device then transmits the registration identifier id_tag_ack_file in step F3.

[0141] Upon receipt by the certifying device A of the acknowledgment ack_file comprising this registration identifier id_tag_ack_file (step F4), the certifying device A can send in a step H3 a request comprising this registration identifier id_tag_ack_file to the blockchain. The request comprising the registration identifier id_tag_ack_file is received in a step H3'. The acknowledgment ack_file is determined in a step H4' using the registration identifier id_tag_ack_file. In response, in a step H4, the certifying device A obtains the acknowledgment ack_file. The certifying device A can optionally verify the identity of the recipient device B having registered this acknowledgment ack_file in the blockchain, by virtue of the properties of the blockchain. This additional verification reinforces the security of the certification method.

[0142] As an alternative or complementary to the registration by the recipient device B, in the block chain, of the acknowledgment of receipt ack_file, the recipient device B can proceed in a similar manner for the acknowledgment of receipt ack_key of the decryption key.

[0143] The recipient device B can thus, before sending the acknowledgment ack_key of the decryption key k_file to the certifying device (step F15), write in a step H5 the acknowledgment ack_key in the block chain BC, or another separate block chain. The acknowledgment ack_key is written in a step H5'. A registration identifier id_tag_ack_key is generated in a step H6'. The Recipient device B receives in response the registration identifier id_tag_ack_key in a step H6.

[0144] The device then transmits the registration identifier id_tag_ack_key in step F15.

[0145] Upon receipt by the certifying device A of the acknowledgment ack_key comprising this registration identifier id_tag_ack_key (step F16), the certifying device A can send in a step H7 a request comprising this registration identifier id_tag_ack_key to the blockchain. The request comprising the registration identifier id_tag_ack_key is received in a step H7'. The acknowledgment ack_key is determined using the registration identifier id_tag_ack_key in a step H8'. In response, in a step H8, the certifying device A obtains the acknowledgment ack_key. The certifying device A can optionally verify the identity of the recipient device B having registered this acknowledgment ack_key in the blockchain, by virtue of the properties of the blockchain. This additional verification reinforces the security of the certification method.

[0146] It should be noted that, in this embodiment, the certifying device A does not need to write the acknowledgments ack_file and ack_key itself in the blockchain, because these are already written by the recipient device B.

[0147] In the case where the acknowledgment ack_key includes a digest hash_B' of the decrypted file (described above), the certifying device A can implement the verification of equality between this digest hash_B' and a digest hash_A' that it determines from the decrypted file on its side.

[0148] This embodiment where the recipient device B itself writes the digest of the decrypted file hash_B' in the block chain is particularly advantageous in that it makes it possible to obtain unfalsifiable and irrefutable proof that the recipient device B was indeed able to obtain, thanks to the method described above, the decrypted file. Indeed, it would be impossible for the recipient device B to obtain such a digest and write it in the block chain if it had not been able to decrypt the file beforehand.

[0149] If the certifying device A is of the orchestrator type making available to a sending device U a document sharing certification service, the certifying device can, in a step subsequent to step H8, transmit to the sending device an acknowledgment of receipt certifying the correct reception by the recipient device B of the file. This acknowledgment of receipt can comprise the registration identifier id_tag_ack_file obtained in step H4. This acknowledgment of receipt can also comprise the registration identifier obtained in step H8, when this is implemented, i.e. the certifying device A receives an acknowledgment of ack_key receipt of the decryption key. The registration identifier of the decryption key acknowledgment is particularly useful to the sending device U when the ack_key acknowledgment includes the hash_A' digest of the decrypted file, because the sending device, when it has a copy of the decrypted file, can check its integrity itself.

[0150] More generally, it is possible to summarize the certification process implemented by the certifying device A, in this variant where the acknowledgment of receipt is recorded by the recipient device and not by the certifying device, as follows:

[0151] - reception, from the recipient device B, of information (such as the identifier id_tag_ack_file) allowing to obtain an acknowledgment of receipt ack_file of the encrypted file c_file from a first digital storage space (like the blockchain above),

[0152] - storage, in a second digital storage space, of the first data dl encrypted and decipherable by the second device,

[0153] - reception, from said second device, of a second data item d2,

[0154] - checking whether the second data d2 is equal to the first data dl, and, in case of positive verification, triggering of a transmission to the destination device B of a decryption key k_file of the encrypted file c_file.

[0155] The sharing confirmation method according to this variant, executed by the recipient device, comprises:

[0156] - storage, in a first digital storage space, of an acknowledgment of receipt ack_file of the encrypted file c_file,

[0157] - transmission, to the first device A, of information allowing the first device to obtain said acknowledgment of receipt ack_file of the encrypted file c_file,

[0158] - transmission, to the first device A, of a second data item d2 obtained by decrypting a first encrypted data dl obtained by the second device following the transmission of the information allowing the first device to obtain the acknowledgment of receipt ack_file of the encrypted file c_file,

[0159] - reception, from the first device A, of a decryption key k_file of the encrypted file c_file.

[0160] Thus, this method advantageously allows the recipient device to record, in the digital storage space (such as a blockchain), the acknowledgment of receipt of the encrypted file. This allows a trace of such receipt to be kept, and in particular this allows the recipient device not to have to trust the certifying device with regard to recording this acknowledgment of receipt.

[0161] 5.10 Devices

[0162] Finally, in relation to figures 6 and 7, the simplified structures of a certifying device A and of a recipient device B according to an embodiment of the invention are presented.

[0163] As illustrated in [Fig.6], a first device A according to one embodiment of the invention comprises a memory 100, a processing unit 110, equipped for example with a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program 120, implementing steps of the certification method according to at least one embodiment of the invention.

[0164] At initialization, the code instructions of the computer program 120 are for example loaded into a RAM memory before being executed by the processor of the processing unit 110.

[0165] The processor of the processing unit 110 implements steps of the sharing certification method described previously, according to the instructions of the computer program 120, to:

[0166] - receive, from said second device B, an acknowledgment of receipt ack_file by the second device of the encrypted file c_file,

[0167] - store, in a digital storage space BDD1, a first data dl encrypted and decipherable by the second device, and said acknowledgment ack_file of the encrypted file c_file,

[0168] - receive, from said second device, a second data item d2,

[0169] - check if the second data d2 is equal to the first data dl, and, in case of positive verification, trigger a transmission to the second device B of a decryption key k_file of the encrypted file c_file.

[0170] As illustrated in [Fig.7], a second device B according to an embodiment of the invention comprises a memory 200, a processing unit 210, equipped for example with a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program 220, implementing steps of the certification method according to at least one embodiment of the invention.

[0171] At initialization, the code instructions of the computer program 220 are for example loaded into a RAM memory before being executed by the processor of the processing unit 210.

[0172] The processor of the processing unit 210 implements steps of the sharing certification method described previously, according to the instructions of the computer program 220, to:

[0173] - transmit, to the first device A, an acknowledgment of receipt ack_file of the encrypted file c_file,

[0174] - transmit, to the first device A, a second data item d2 obtained by decrypting a first encrypted data dl obtained by the second device following the transmission of the acknowledgment of receipt ack_file of the encrypted file c_file,

[0175] - receive, from the first device A, a decryption key k_file of the encrypted file c_file.

Claims

Claims

1. Method for certification by a first device, called a certifier, (A) of a sharing of a file (file) to at least one second device (B), the method being implemented by said first certifier device (A) and comprising: - obtaining a first digest (hash_A) of the encrypted file (c_file), - receiving (E2), from said second device (B), an acknowledgment of receipt (ack_file) by the second device of the encrypted file (c_file), said acknowledgment of receipt of the encrypted file (ack_file) comprising a second digest (hash_B) of the encrypted file as obtained by the second device, - verifying whether said first digest (hash_A) is equal to the second digest (hash_B), and in the event of a positive verification triggering of a storage (E3), in a digital storage space (BDD1), of a first encrypted data item (c_dl) and decipherable by the second device,and said acknowledgment of receipt (ack_file) of the encrypted file (c_file) comprising said first digest (hash_A), - a reception (E6), from said second device, of a second data item (d2) obtained by decryption of said first encrypted data item (c_dl), - a verification (E7) whether the second data item (d2) is equal to the first data item (dl), and, in the event of a positive verification, triggering (E8) of a transmission to the second device (B) of a decryption key (k_file) of the encrypted file (c_file).,

2. Certification method according to claim 1, further comprising - receiving, from the second device, an acknowledgment of receipt (ack_key) of said decryption key, and - storing, in a second digital storage space, said acknowledgment of receipt (ack_key) of said decryption key.

3. The method of claim 2, wherein the acknowledgment of the decryption key comprises a digest of a decrypted file, and wherein storing said acknowledgment of the decryption key comprises verifying whether the digest of the decrypted file from the second device is identical to a digest of the decrypted file that the first device determines using the encrypted file (c_file) and the decryption key (k_file).

4. Certification method according to one of the preceding claims, in which at least one digital storage space is a blockchain.

5. Method for confirming sharing to at least one second device (B), the method being implemented by the second device having obtained an encrypted file (c_file) and comprising: - obtaining a second digest (hash_B) of the encrypted file (c_file), - transmitting (El), to a first device (A), an acknowledgment of receipt (ack_file) of the encrypted file (c_file) comprising the second digest (hash_B) of the encrypted file, - transmitting (E5), to the first device (A), a second data item (d2) obtained by decrypting a first encrypted data item (dl) obtained by the second device following the transmission of the acknowledgment of receipt (ack_file) of the encrypted file (c_file), - receiving (E9), from the first device (A), a decryption key (k_file) of the encrypted file (c_file).

6. Sharing confirmation method according to claim 5, further comprising: - a transmission, to the first device (A), of an acknowledgment of receipt (ack_key) of said decryption key.

7. A sharing confirmation method according to claim 6, wherein the acknowledgment (ack_key) of the decryption key (k_file) comprises a digest of the decrypted file obtained by the second device (B) using the encrypted file (c_file) and the decryption key (k_file).

8. First device, called certifier, for certifying a sharing of a file (file) to at least one second device (B), characterized in that the first certifier device (A) comprises: - means for obtaining a first digest (hash_A) of the encrypted file (c_file), - means for receiving (E2), from said second device (B), an acknowledgment of receipt (ack_file) by the second encrypted file device (c_file), said acknowledgment of receipt of the encrypted file (ack_file) comprising a second digest (hash_B) of the encrypted file as obtained by the second device, - means for verifying whether said first digest (hash_A) is equal to the second digest (hash_B), and in the event of a positive verification, triggering storage means (E3), in a digital storage space (BDD1), of a first encrypted data item (c_dl) decipherable by the second device, and of said acknowledgment of receipt (ack_file) of the encrypted file (c_file) comprising said first digest (hash_A), - means (E6) for receiving, from said second device, a second data item (d2) obtained by decrypting said first encrypted data item (c_dl), - means of verification (E7) if the second data (d2) is equal to the first data (dl), and, in the event of a positive verification, means of triggering (E8) a transmission to the second device (B) of a decryption key (k_file) of the encrypted file (c_file).

9. Second device for confirming a sharing of a file, the method being implemented by the second device having obtained an encrypted file (c_file) and comprising: - means of obtaining a second digest (hash_B) of the encrypted file (c_file), - means of transmission (El), to a first device (A), of an acknowledgment of receipt (ack_file) of the encrypted file (c_file) comprising the second digest (hash_B) of the encrypted file, - means of transmission (E5), to the first device (A), of a second data item (d2) obtained by decryption of a first encrypted data item (dl) obtained by the second device following the transmission of the acknowledgment of receipt (ack_file) of the encrypted file (c_file), - means for receiving (E9), from the first device (A), a decryption key (k_file) of the encrypted file (c_file).

10. A computer program product comprising program code instructions for implementing a method according to one of claims 1 to 7, when executed by a processor.

Images