FR3085505A1 - SECURE METHOD AND SYSTEM FOR DELAYED SHARING OF DATA BETWEEN AT LEAST ONE TRANSMITTING USER AND AT LEAST ONE RECIPIENT USER, UNDER THE CONTROL OF A TRUSTED THIRD PARTY. - Google Patents

Abstract

File sharing method (2) between at least one sending user (Ai) and at least one recipient user (Bk), which comprises several phases: - Writing: ○ Create, at the request of at least one sending user (Ai) , a data container (6) associated with the recipient user (Bk); ○ Allow the sending user (Ai) write access to the container (6); - Archiving: ○ At the end of the writing phase, encrypt the container (6); ○ During an archiving period (T2), store the encrypted container (6Bk); - Verification of a condition by a third-party user (C); - Sharing: if the condition is met, decrypt the container (6Bk) to allow access to the recipient user (Bk).

Description

Secure method and system for delayed data sharing between at least one sending user and at least one receiving user, under the control of a trusted third party

The invention relates to the field of computing, and more specifically to the sharing of computer data files between at least one sending user and at least one receiving user.

The term “user” is used here to designate a communicating device (in English “user device”), typically a smartphone, a tablet, or more generally a computer, for example. a portable or fixed computer or a workstation capable of connecting, via a local computer network (LAN), metropolitan (MAN) or extended (WAN, typically the Internet), to a remote server, the term "server ”Designating here a physical unit or, in a virtualization framework, a computing and / or memory space allocated within a physical unit and on which an operating system or an operating system emulation is running.

However, it is understood that an actual user (that is to say a natural or legal person) who carries out operations using this device is associated with such an electronic client device.

The use of computer networks is quite widespread today, especially for data sharing.

There are various types of systems for sharing data.

Mailbox-type e-mails, which work asynchronously, allow user A (sender) to address user B (recipient) a message containing information that can be included in the body of the message itself , or as attached files.

In an electronic messaging system, the message delivery time depends essentially on the bandwidth (availability) of the network connecting the sending and receiving users, and on the memory size of the message, including its any attachments.

Quite often, routing takes a few seconds. The recipient can then open and read the message from the sender whenever they want.

LAP B017 FR

At the time of writing, e-mail is limited in size to the messages sent, usually around ten megabytes (MB).

To exchange data of large volume (that is to say of size greater than 10 MB), it has become customary to use specialized platforms, e.g. DropBox (registered trademark).

In principle, these platforms aim to allow permanent access to a private memory space on which files are stored, for any user identified as having the right to it.

Hacking files involves either unauthorized access to this memory space, or the theft of the identity of a user with access rights.

These platforms are easy to use but nevertheless meet limits with regard to data security. In particular, identity theft is very effective in accessing data immediately, and - in general - both read and write.

There therefore remains a need to share computer data files between users, with a higher degree of security, while preserving a certain simplicity of use.

To this end, it is proposed, firstly, a method of sharing computer data files between at least one sending user and at least one recipient user, this method comprising:

A writing phase, which includes the operations of:

o Create, at the request of at least one sending user, at least one data container to share, associated with the user (or each user) recipient;

o Designate a third-party user;

o As long as no end of writing instruction has been taken into account, allow each sending user write access to the container;

An archiving phase, which includes the operations of:

o When taking the end of writing instruction into account, encrypt the or each container to form an encrypted container associated with each recipient;

LAP B017 FR o Associate the (or each) encrypted container with a predetermined archiving period;

o As long as the archiving period has not expired, store the encrypted container by preventing access to it at least to the recipient user (or to each recipient user);

A verification phase, which includes the operation consisting, at the end of the archiving period, of transmitting to the third-party user a request containing a condition to be fulfilled;

Renewal of the archiving period if the condition is indicated by the third-party user as not fulfilled, or

A sharing phase, which includes, if the condition is indicated by the third-party user as fulfilled, the operation of decrypting the container to allow the recipient user (or each user) to access it.

Various additional characteristics can be provided, alone or in combination. So, for example:

It is advantageously provided, during the writing phase, an operation consisting in associating with the container a predetermined writing period at the end of which an end of writing instruction is issued.

The write time can be set by the sending user, or automatically.

The archiving period can be defined by the sending user, or automatically.

The archiving period can be defined separately for each recipient user.

Other objects and advantages of the invention will emerge in the light of the description of an embodiment, given below with reference to the appended drawings in which:

FIG.1 is a synthetic diagram of a computer system illustrating the writing phase of a method according to the invention;

FIG.2 is a diagram similar to FIG.1, illustrating the archiving phase;

FIG.3 is a diagram similar to FIG.1, illustrating the sharing phase;

LAP B017 FR

FIG.4 is a diagram illustrating different stages of the process of the invention.

In FIG. 1 to FIG. 3 is shown a computer system 1, intended to allow the sharing of files 2 of computer data between at least one user Ai transmitter (i an integer such as 1 <i <N; N an integer such than N> 1) and at least one recipient user Bk (k an integer such as 1 <k <P; P an integer such as P> 1), under the control of a third user C.

The term “user” here designates, in concrete terms, an electronic device, such as a smartphone, a computer, a tablet, and provided with a communication interface (wired or wireless) through which this device is capable to connect to a remote server, via a local (LAN), metropolitan (MAN) or wide area network (WIDE, such as the Internet). It is understood, however, that, by extension, the term “user” indirectly designates one (or more) real user (s) (for example a natural or legal person) associated with this device.

The computer system 1 comprises, first of all, a communication server 4, programmed to be able to establish communication sessions (preferably secure) with users (in particular with users Ai, Bk, C).

The computer system 1 comprises, secondly, a file server 5, on which directories or “containers” 6 of data files to be shared can be created or deposited. In these containers can be created, deposited, copied, pasted, deleted, modified, 2 data files of any type, eg. files from office applications (eg word processing, spreadsheet), sound, image, or video files.

The computer system 1 comprises, thirdly, a profile database 7 which contains profiles of users PAi, PBk, PC in memory. In this case, the database contains at least one profile PAi associated with each sending user Ai, a profile PBk associated with each recipient user Bk, and a profile PC associated with the third-party user C.

Each PAi, PBk, PC user profile includes at least one IDAi, IDBk, IDC identifier linked to the respective user Ai, Bk, C (e.g.

LAP B017 FR a name, an e-mail address, a telephone number) and at least one key ZAi, ZBk, ZC respective public cryptographic.

This public cryptographic key ZAi, ZBk, ZC corresponds to a respective private cryptographic key AiZ, BkZ, CZ.

The private cryptographic AiZ, BkZ, CZ key associated with each user Ai, Bk or C is stored locally in a memory space thereof.

The computer system 1 comprises, fourthly, a control unit 8, connected to the communication server 4, to the file server 5 and to the database 7. The control unit 8 comprises at least one processor and a programmable memory. The control unit 8 is programmed to control the communication server 4, the file server 5 and to administer the database 7.

Data sharing between at least one sending user Ai and at least one receiving user Bk under the control of at least one third-party user C comprises several phases.

A first phase, called writing, includes the operations of:

o Create, at the request of at least one sending Ai user, at least one container 6 of data to be shared;

o Designate at least one third C user;

o As long as no end of write instruction has been taken into account, allow each sending user Ai write access to container 6.

The container 6 can be created locally by a sending user Ai, for example when this sending user Ai is unique (N = 1; i = 1), or, as in the example illustrated, on the file server 5, in particular when several transmitting Ai users share this container 6.

During the writing phase, each sending user Ai is authorized to modify the container 6 by adding or subtracting from it data files 2. These data files 2 can come from (or from each) terminal Ai itself, or be downloaded from remote servers via the network 3.

According to a preferred embodiment, a writing delay T1 (shown diagrammatically in the drawings by a first countdown) is advantageously defined by a user A1 master transmitter, or

LAP B017 FR automatically by control unit 8. The T1 writing delay is advantageously implemented within the computer system 1, e.g. by means of an internal clock controlled by (or integrated into) the control unit 8.

It is at the end of this T1 writing period that the end of writing instruction is issued.

User C third party is e.g. associated with a legal entity, e.g. a notary office, reputed to be trustworthy. As such, the third party user C can also be designated under the name "trusted third party".

The designation of the third-party user C appears for example. in the form of metadata associated with container 6 and containing the IDC identifier of user C in the database 7.

A second phase, called archiving, includes the operations of:

o When taking the write end instruction into account (that is to say, in the example presented above, at the end of the T1 write delay), encrypt the or each container (6) to form an encrypted container (6Bk) associated with each recipient (Bk);

o Associate (or each) encrypted container (6Bk) with a predetermined archiving time (T2);

o As long as the archiving period (T2) has not expired, store the encrypted container (6Bk) by preventing access to it at least to the recipient user (Bk).

According to a preferred embodiment, the encryption is carried out by means of the public key ZBk of the recipient (or of each) user Bk. When several users Bk are designated when the container 6 is created, the container 6 is advantageously copied in as many copies as there are recipients, each copy in this case preferably being encrypted using the public key ZBk of the corresponding user Bk.

The T2 archiving period (shown schematically in the drawings by a second countdown) can be defined by the user A1 master transmitter, or automatically. The T2 archiving period is advantageously implemented within the IT system 1, e.g. by means of an internal clock controlled by (or integrated into) the control unit 8.

LAP B017 FR

The T2 archiving period is advantageously greater than one hour. It is preferably greater than one day. It can reach a month or even one or more years.

The T2 archiving period can be defined separately for each recipient Bk user.

According to a preferred embodiment, the control unit 8 is devoid of instructions for communicating to each recipient user Bk, during the archiving phase, the very existence of a container 6 or a container 6Bk encrypted to its attention, so that the actual users associated with the recipient Bk users are kept in the dark about this existence.

A third phase, called verification, comprises the operation consisting, at the end of the T2 archiving period, in transmitting to user C third a request containing a condition to be fulfilled.

This request is advantageously encrypted, e.g. using the public ZC key of third party user C. In this case, the request is decrypted, upon receipt, by user C using his private CZ key.

The condition to be fulfilled, e.g. :

An alternative to which it is possible to answer simply by YES (signifying that the condition is fulfilled) or by NO (signifying that the condition is not fulfilled),

A list of questions or options, the combined answers of which determine whether the condition is met or not met;

Note that the response to the condition can be in the form of data entered manually at the level of third-party user C, or result from an automated query of an integrated database or associated with user C.

Thus, the condition to be fulfilled can be linked to the legal status (eg legal majority) or the state of health (eg living or deceased) of the natural person associated with the user (or each user) Ai sender, or the user (or each user) Bk recipient.

Thus, when the container 6 contains a will, the communication of which to the sender (or to each sender) Bk recipient, the condition may be: has the user Ai sender died?

LAP B017 FR

To this question, third party user C, who is supposed to be able to answer (in particular when he is associated with a notary office), can only do so by YES (condition fulfilled) or by NO (condition not fulfilled).

When container 6 contains data which can only be viewed by a person who has reached the legal majority (18 years in most countries), the condition may be: has user Bk reached the legal majority?

To this question, third party user C, who is supposed to be able to answer (in particular when he is associated with a notary office), can only do so by YES (condition fulfilled) or by NO (condition not fulfilled).

The T2 archiving period is then renewed if the condition is indicated by third party C user as not fulfilled.

In a first case, the original T2 period (eg five years) can be renewed in the strict sense, that is to say that the 6Bk container is kept stored and encrypted for a new period which extends over an identical T2 period (five years in this example).

In a second case, the original T2 period is not retained, but a new T2 period of different duration is introduced (eg one year).

In both cases, the archiving phase is extended.

The verification phase is then repeated at the end of the renewed period.

If (or as soon as) the condition is indicated by the third party (C) user as fulfilled, there is a fourth phase, called sharing, which includes the operation consisting, at the expiration of the T2 archiving period ( possibly after being renewed one or more times according to the procedure described above), to decrypt the container 6 (or each copy of it) to allow access to the user (or each user) (Bk ) recipient.

In practice, the sharing phase consists of allowing each recipient Bk user to download the encrypted 6Bk container in order to decrypt it using their private BkZ key.

Concretely, the control unit 8 is for example. programmed to send to the recipient user Bk (in particular via the communication server 4) a notification of availability of the encrypted container 6Bk. This notification advantageously contains an IDAi identifier associated with at least one sending Ai user, or an IDAi identifier

LAP B017 FR associated with each sending Ai user. The download is then preferably ordered by the recipient user Bk, rather than carried out automatically on command from the control unit 8. Knowledge at least of the profile IDAi of the user (or of each user) Ai sending by the user Bk recipient can constitute for the latter an index of confidence of the origin and / or the harmlessness of the data shared by the Users have transmitters.

Concretely, each encrypted container 6Bk is sent, on command from the control unit 8, to the corresponding recipient user Bk via the network 3. The decryption is carried out locally by the recipient user Bk, using his key Private BkZ stored locally. The recipient user Bk can then read (and if necessary write) the container 6, that is to say the data files 2 which it contains, as deposited at the initiative of the user Has transmitter.

After decryption, the data files 2 can be stored locally by each recipient Bk user.

At the end of the decryption, each recipient Bk user can send (automatically or on external command) to system 1 a decryption notification. This notification is received by the communication server 4.

In this case, it is advantageously provided for the destruction of the (or each) corresponding encrypted container 6Bk on the file server 5 after reception, by the system 1, of the decryption notification.

In this way, memory space is freed up within the file server 5, which facilitates the subsequent creation of new containers 6.

The process which has just been presented offers a certain advantage in terms of safety compared with the known processes (respectively the systems). In fact, during the archiving phase, the data in files 2 cannot be read - nor a fortiori modified - by the user (or each user) Ai sending or by any of the users Bk recipients. Any impersonation of any of them is ineffective since it is necessary to have the private key of the recipient user Bk to decrypt the container 6Bk.

LAP B017 FR

We even see that the control exerted by the user (or by each user) Ai on the container 6 (that is to say on the data files 2 to be shared) ceases at the expiration of the T1 writing delay , even though its content is not yet accessible to any 5 Bk recipient user. The delay (predetermined) with which the recipient users Bk accesses the files 2 of data shared by the sending users Ai makes any dialogue between them in real time impossible, to the benefit of the parsimony with which the users exchange data with each other. This notably results in an optimization of the bandwidth necessary, in networks, for exchanges between users.

The use of a third party user C (or trusted third party) makes it possible to provide additional security by subjecting to one (or more) condition (s) the communication of the data of the container 6 to the user (or to each user). Bk recipient.

Claims (6)

1. Method for sharing files (2) of computer data between at least one sending user (Ai) (i an integer such as 1 <i <N; N an integer such as N> 1) and at least one user (Bk ) addressee (k an integer such as 1 <k <P; P an integer such as P> 1;), this method being characterized in that it comprises: A writing phase, which includes the operations of: o Create, at the request of at least one sending user (Ai), at least one container (6) of data to be shared, associated with the recipient user (or each user) (Bk); o Designate a third party user (C); o As long as no write end instruction has been taken into account, allow each sending user (Ai) write access to the container (6); An archiving phase, which includes the operations of: o When taking the end of writing instruction into account, encrypt the or each container (6) to form an encrypted container (6Bk) associated with each recipient (Bk); o Associate (or each) encrypted container (6Bk) with a predetermined archiving time (T2); o As long as the archiving period (T2) has not expired, store the encrypted container (6Bk) by prohibiting access to it at least to the recipient user (Bk); A verification phase, which includes the operation consisting, at the end of the archiving period (T2), in transmitting to the third-party user (C) a request containing a condition to be fulfilled; The renewal of the archiving period (T2) if the condition is indicated by the third party (C) user as not fulfilled, or A sharing phase, which includes, if the condition is indicated by the third party (C) user as fulfilled, the operation consisting in decrypting the container (6) to allow access to the user (or to each user) ) (Bk) recipient. 2. Method according to claim 1, which comprises, during the writing phase, an operation consisting in associating with the container (6) LAP B017 FR a predetermined writing delay (T1) at the end of which an end of writing instruction is issued. 3. Method according to claim 2, in which the writing delay (T1) is defined by a sending user (Ai). 5 4. Method according to claim 2, wherein the writing delay (T1) is automatically defined. 5. Method according to one of claims 1 to 4, wherein the archiving time (T2) is defined by a user (Ai) transmitter. 6. Method according to one of claims 1 to 4, wherein the 10 archiving delay (T2) is automatically defined.