FR3085509A1 - Systeme et procede securises de partage retarde de donnees entre un utilisateur emetteur et un utilisateur destinataire, avec creation distante d'un conteneur et horodatage sur blockchain. - Google Patents

Systeme et procede securises de partage retarde de donnees entre un utilisateur emetteur et un utilisateur destinataire, avec creation distante d'un conteneur et horodatage sur blockchain. Download PDF

Info

Publication number
FR3085509A1
FR3085509A1 FR1857785A FR1857785A FR3085509A1 FR 3085509 A1 FR3085509 A1 FR 3085509A1 FR 1857785 A FR1857785 A FR 1857785A FR 1857785 A FR1857785 A FR 1857785A FR 3085509 A1 FR3085509 A1 FR 3085509A1
Authority
FR
France
Prior art keywords
container
user
data
writing
archiving
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR1857785A
Other languages
English (en)
Inventor
Raphael Louiset
Jonathan Attia
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to FR1857785A priority Critical patent/FR3085509A1/fr
Priority to PCT/IB2019/057187 priority patent/WO2020044216A1/fr
Publication of FR3085509A1 publication Critical patent/FR3085509A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2137—Time limited access, e.g. to a computer or data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2143—Clearing memory, e.g. to prevent the data from being stolen
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2151—Time stamp
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Procédé de partage de fichiers (2) entre un utilisateur (A) émetteur et un utilisateur (B) destinataire qui comprend trois phases : - Ecriture : ○ Créer, dans un serveur (5) de fichiers, à l'initiative de l'utilisateur (A) émetteur, un conteneur (6) de données, associé à l'utilisateur (B) destinataire ; ○ Pendant un délai (T1) d'écriture, permettre à l'utilisateur (A) émetteur l'accès en écriture au conteneur (6) ; - Archivage : ○ A l'expiration du délai (T1) d'écriture, interdire à l'utilisateur (A) émetteur l'accès au conteneur (6) ; ○ Crypter les données du conteneur (6) à l'aide de la clé (ZB) publique de l'utilisateur (B) destinataire ; ○ Pendant un délai (T2) d'archivage contrôlé par interrogation d'une blockchain, stocker le conteneur (6B) crypté dans un serveur (5) de fichiers ; - Partage : permettre à l'utilisateur (B) destinataire de télécharger le conteneur (6B) crypté en vue de le décrypter à l'aide de sa clé (BZ) privée.

Description

Système et procédé sécurisés de partage retardé de données entre un utilisateur émetteur et un utilisateur destinataire, avec création distante d’un conteneur et horodatage sur blockchain
L’invention a trait au domaine de l’informatique, et plus précisément du partage de fichiers de données informatiques entre un utilisateur émetteur et un utilisateur destinataire.
Le terme « utilisateur » est ici employé pour désigner un appareil communiquant (en anglais « user device »), typiquement un smartphone, une tablette, ou plus généralement un ordinateur, par ex. un ordinateur portable ou fixe ou encore une station de travail, capable de se connecter, via un réseau informatique local (LAN), métropolitain (MAN) ou étendu (WAN, typiquement l’Internet), à un serveur distant, le terme « serveur » désignant ici une unité physique ou, dans un cadre de virtualisation, un espace de calcul et/ou de mémoire alloué au sein d’une unité physique et sur lequel tourne un système d’exploitation ou une émulation de système d’exploitation.
Néanmoins on comprend qu’est associé à un tel dispositif électronique client un utilisateur réel (c'est-à-dire une personne physique ou morale) qui effectue des opérations à partir de ce dispositif.
L’utilisation des réseaux informatiques est aujourd’hui assez répandue, notamment pour le partage de données.
Il existe divers types de systèmes permettant de partager des données.
Les messageries électroniques de type boîte aux lettres, qui fonctionnent de manière asynchrone, permettent à un utilisateur A (émetteur) d’adresser à un utilisateur B (destinataire) un message contenant des informations qui peuvent être incluses dans le corps du message lui-même, ou sous forme de fichiers joints.
Dans une messagerie électronique, le délai d’acheminement du message dépend, pour l’essentiel, de la bande passante (disponibilité) du réseau reliant l’utilisateur émetteur et l’utilisateur destinataire, et de la taille mémoire du message, y compris ses éventuelles pièces jointes.
Bien souvent, l’acheminement prend quelques secondes. Le destinataire peut alors ouvrir et lire le message provenant de l’émetteur quand bon lui semble.
LAP B008 FR
A l’heure où sont écrites ces lignes, les messageries électroniques sont limitées quant à la taille des messages transmis, le plus souvent à une dizaine de Mégaoctets (Mo).
Pour échanger des données de gros volume (c'est-à-dire de taille supérieure à 10 Mo) environ, il est devenu usuel de recourir à des plateformes spécialisées, par ex. DropBox (marque déposée).
Dans leur principe, ces plateformes visent à permettre un accès permanent à un espace mémoire privé sur lequel sont mémorisés des fichiers, pour tout utilisateur identifié comme y ayant droit.
Le piratage des fichiers implique soit un accès non autorisé à cet espace mémoire, soit l’usurpation de l’identité d’un utilisateur ayant droit d’accès.
Ces plateformes sont simples d’utilisation mais rencontrent cependant des limites quant à la sécurisation des données. En particulier, l’usurpation d’identité est très efficace pour accéder aux données, et ce de manière immédiate, et - en général - tant en lecture qu’en écriture.
Il persiste par conséquent un besoin de partager des fichiers de données informatiques entre utilisateurs, avec un degré supérieur de sécurité, tout en préservant une certaine simplicité d’utilisation.
A cet effet, il est proposé, en premier lieu, un procédé de partage de fichiers de données informatiques entre un utilisateur émetteur et un utilisateur destinataire, via un système informatique équipé :
D’un serveur de communication,
D’au moins un serveur de fichiers, et
D’une base de données de profils contenant en mémoire des profils associés aux utilisateurs, chaque profil comprenant au moins un identifiant et au moins une clé cryptographique publique à laquelle correspond une clé privée,
Ce procédé comprenant, au niveau du système, trois phases successives :
Une phase d’écriture, qui inclut les opérations consistant à :
o Recevoir de l’utilisateur émetteur une requête contenant une instruction de création d’un conteneur de données à partager et un identifiant de l’utilisateur destinataire ;
o Créer le conteneur dans un serveur de fichiers ;
LAP B008 FR o Associer le conteneur au profil associé à l’utilisateur destinataire dans la base de données ;
o Associer au conteneur un délai prédéterminé d’écriture ;
o Tant que le délai d’écriture n’a pas expiré, permettre à l’utilisateur émetteur l’accès en écriture au conteneur ;
Une phase d’archivage, qui inclut les opérations consistant à : o A l’expiration du délai d’écriture, interdire à l’utilisateur émetteur l’accès, au moins en écriture, au conteneur ;
o Crypter les données du conteneur à l’aide de la clé publique de l’utilisateur destinataire pour former un conteneur crypté ;
o Associer au fichier crypté un délai prédéterminé d’archivage ;
o Stocker le conteneur crypté dans un serveur de fichiers en en interdisant l’accès au moins à l’utilisateur destinataire ;
o Répéter périodiquement la séquence de vérification suivante :
a) Sélectionner un bloc dans un registre informatique constitué en chaîne de blocs ayant chacun une donnée d’horodatage ;
b) Extraire la donnée d’horodatage du bloc sélectionné ;
c) Déterminer, à partir de cette donnée d’horodatage, une date courante ;
o Tant que le délai d’archivage est antérieur à la date courante, répéter la séquence de vérification en maintenant le stockage du conteneur crypté ;
Une phase de partage, qui inclut l’opération consistant, dès lors que le délai d’archivage est égal ou postérieur à la date courante, à permettre à l’utilisateur destinataire de télécharger le conteneur crypté en vue de le décrypter à l’aide de sa clé privée.
Diverses caractéristiques supplémentaires peuvent être prévues, seules ou en combinaison. Ainsi, par exemple :
L’utilisateur émetteur étant distinct de l’utilisateur destinataire, les profils associés, dans la base de données de profils, à l’utilisateur émetteur et à l’utilisateur destinataire sont distincts.
Le délai d’écriture peut être défini par l’utilisateur émetteur, ou automatiquement.
Le délai d’archivage peut être défini par l’utilisateur émetteur, ou automatiquement.
LAP B008 FR
Il peut être prévu la réception, par le serveur de communication, d’une notification de décryptage du conteneur par l’utilisateur récepteur. Dans ce cas, il est avantageusement prévu la destruction du conteneur sur le serveur de fichiers après réception de la notification de décryptage par l’utilisateur destinataire.
Il est proposé, en deuxième lieu, un système informatique qui, pour la mise en oeuvre du procédé tel que présenté ci-dessus, comprend :
Un serveur de communication,
Au moins un serveur de fichiers, et
Une base de données de profils contenant en mémoire des profils associés aux utilisateurs, chaque profil comprenant au moins un identifiant et au moins une clé cryptographique publique à laquelle correspond une clé privée,
Ce système comprenant une unité de contrôle comprenant une mémoire inscriptible contenant des instructions pour opérer :
Une phase d’écriture, qui inclut les opérations consistant à :
o Recevoir de l’utilisateur émetteur une requête contenant une instruction de création d’un conteneur de données à partager et un identifiant de l’utilisateur destinataire ;
o Créer le conteneur dans un serveur de fichiers ;
o Associer le conteneur au profil associé à l’utilisateur destinataire dans la base de données ;
o Associer au conteneur un délai prédéterminé d’ouverture ;
o Tant que le délai d’écriture n’a pas expiré, permettre à chaque utilisateur émetteur l’accès en écriture au conteneur ;
Une phase d’archivage, qui inclut les opérations consistant à :
o A l’expiration du délai d’écriture, interdire à chaque utilisateur émetteur l’accès, au moins en écriture, au conteneur ;
o Crypter les données du conteneur à l’aide de la clé publique de l’utilisateur destinataire pour former un conteneur crypté ;
o Associer au conteneur crypté un délai prédéterminé d’archivage ;
o Stocker le conteneur crypté dans un serveur de fichiers en en interdisant l’accès au moins à l’utilisateur destinataire ;
o Répéter périodiquement la séquence de vérification suivante :
LAP B008 FR
a) Sélectionner un bloc dans un registre informatique constitué en chaîne de blocs ayant chacun une donnée d’horodatage ;
b) Extraire la donnée d’horodatage du bloc sélectionné ;
c) Déterminer, à partir de cette donnée d’horodatage, une date courante ;
o Tant que le délai d’archivage est antérieur à la date courante, répéter la séquence de vérification en maintenant le stockage du conteneur crypté ;
Une phase de partage, qui inclut l’opération consistant, dès lors que le délai d’archivage est égal ou postérieur à la date courante, à permettre à l’utilisateur destinataire de télécharger le conteneur crypté en vue de le décrypter à l’aide de sa clé privée.
D’autres objets et avantages de l’invention apparaîtront à la lumière de la description d’un mode de réalisation, faite ci-après en référence aux dessins annexés dans lesquels :
La FIG.1 est un schéma synthétique d’un système informatique illustrant la phase d’écriture d’un procédé selon l’invention ;
La FIG.2 est schéma similaire à la FIG.1, illustrant la phase d’archivage ;
La FIG.3 est un schéma similaire à la FIG.1, illustrant la phase de partage ;
La FIG.4 est un schéma illustrant différentes étapes du procédé de l’invention ;
La FIG.5 est un schéma illustrant l’extraction d’une donnée d’horodatage d’une chaîne de blocs.
Sur les FIG.1 à FIG.3 est représenté un système 1 informatique, destiné à permettre le partage de fichiers 2 de données informatiques entre un utilisateur A émetteur et un utilisateur B destinataire. Le terme « utilisateur » désigne ici, concrètement, un appareil électronique, tel qu’un smartphone, un ordinateur, une tablette, et pourvu d’une interface de communication (filaire ou sans fil) par l’intermédiaire de laquelle cet appareil est capable de se connecter à un serveur distant, via un réseau 3 local (LAN), métropolitain (MAN) ou étendu (WIDE, tel que l’Internet). On comprend cependant que, par extension, le terme « utilisateur » désigne indirectement un (ou plusieurs) utilisateur(s)
LAP B008 FR réel(s) (par ex. une personne physique ou morale) associé(s) à cet appareil.
Le système 1 informatique comprend, en premier lieu, un serveur 4 de communication, programmé pour pouvoir établir des sessions de communication (de préférence sécurisées) avec des utilisateurs (notamment avec les utilisateurs A et B).
Le système 1 informatique comprend, en deuxième lieu, un serveur 5 de fichiers, sur lequel peuvent être créés des répertoires ou « conteneurs » 6 de fichiers de données à partager. Dans ces conteneurs peuvent être créés, déposés, copiés, collés, supprimés, modifiés, des fichiers 2 de données de tout type, par ex. des fichiers issus d’applications de bureautique (par ex. traitement de texte, tableur), des fichiers de son, d’image, ou encore de vidéo.
Le système 1 informatique comprend, en troisième lieu, une base 7 de données de profils qui contient en mémoire des profils PA, PB d’utilisateurs. En l’espèce, la base de données contient au moins un profil PA associé à l’utilisateur A émetteur, et un profil PB associé à l’utilisateur B destinataire.
Chaque profil PA, PB utilisateur comprend au moins un identifiant IDA, IDB lié à l’utilisateur A, B respectif (par ex. un nom, une adresse électronique, un numéro de téléphone) et au moins une clé ZA, ZB cryptographique publique respective.
A cette clé ZA, ZB cryptographique publique correspond une clé cryptographique AZ, BZ respective privée.
La clé AZ, BZ cryptographique privée associée à chaque utilisateur A ou B est stockée localement dans un espace mémoire de celui-ci.
Selon un mode particulier de réalisation, l’utilisateur A émetteur est distinct de l’utilisateur B destinataire. Dans ce cas, les profils PA, PB associés, dans la base 7 de données de profils, à l’utilisateur A émetteur et à l’utilisateur B destinataire, sont distincts (il en va de même de leurs clés ZA, ZB publiques - et de leurs clés AZ, BZ privées - respectives).
Le système 1 informatique comprend, en quatrième lieu, une unité 8 de contrôle, reliée au serveur 4 de communication, au serveur 5 de fichiers et à la base 7 de données. L’unité 8 de contrôle comprend au moins un processeur et une mémoire programmable. L’unité 8 de
LAP B008 FR contrôle est programmée pour contrôler le serveur 4 de communication, le serveur 5 de fichiers et pour administrer la base 7 de données.
L’unité 8 de contrôle (et plus précisément sa mémoire) comprend des instructions pour effectuer des opérations regroupées en plusieurs phases successives.
Une première phase, dite d’écriture, inclut les opérations consistant à :
o Recevoir de l’utilisateur A émetteur une requête contenant une instruction de création d’un conteneur 6 et un identifiant IDB de l’utilisateur B destinataire ;
o Créer le conteneur 6 dans un serveur 5 de fichiers ;
o Associer le conteneur 6 au profil associé à l’utilisateur B dans la base 7 de données ;
o Associer au conteneur 6 un délai T1 prédéterminé d’écriture ;
o Tant que le délai T1 d’écriture n’a pas expiré, permettre à l’utilisateur A émetteur l’accès en écriture au conteneur 6.
En pratique, l’utilisateur A émetteur adresse au système 1 informatique, via le réseau 3, la requête de création du conteneur 6. Cette requête transite par le serveur 4 de communication, qui effectue les vérifications d’identité de l’utilisateur A émetteur, typiquement par comparaison d’une information communiquée par celui-ci (par ex. un mot de passe) avec une information associée à son profil IDA tel que mémorisé dans la base 7 de données. Dès lors que l’utilisateur A émetteur est identifié, accès lui est donné (éventuellement par un autre canal de communication, comme illustré sur la FIG.1) au serveur 5 de fichiers.
Pendant la phase d’écriture, l’utilisateur A émetteur est autorisé à modifier le conteneur 6 en lui ajoutant ou en lui soustrayant des fichiers 2 de données. Ces fichiers 2 de données peuvent être issus de l’utilisateur A émetteur lui-même, ou être téléchargés depuis des serveurs distants via le réseau 3.
Le délai T1 d’écriture (schématisé sur les dessins par un premier compte à rebours) peut être défini par l’utilisateur A émetteur, ou automatiquement par l’unité 8 de contrôle. Le délai T1 d’écriture est avantageusement implémenté au sein du système 1 informatique, et plus précisément dans l’unité 8 de contrôle.
LAP B008 FR
Une deuxième phase, dite d’archivage, inclut les opérations consistant à :
o A l’expiration du délai T1 d’écriture, interdire à l’utilisateur A émetteur l’accès, au moins en écriture, au conteneur 6 ;
o Crypter le conteneur 6 à l’aide de la clé ZB publique de l’utilisateur B destinataire pour former un conteneur 6B crypté ;
o Associer au conteneur 6B crypté un délai T2 prédéterminé d’archivage ;
o Tant que le délai T2 d’archivage n’a pas expiré, stocker le conteneur 6B crypté dans un serveur 5 de fichiers en en interdisant l’accès au moins à l’utilisateur B destinataire.
Le délai T2 d’archivage (schématisé sur les dessins par un deuxième compte à rebours) peut être défini par l’utilisateur A émetteur, ou automatiquement. Le délai T2 d’archivage est avantageusement implémenté au sein du système 1 informatique, par ex. au moyen d’une horloge interne pilotée par (ou intégrée à) l’unité 8 de contrôle.
Le délai T2 d’archivage est avantageusement supérieur à une heure. Il est de préférence supérieur à un jour. Il peut atteindre un mois, voire une ou plusieurs années.
Le contrôle de l’expiration du délai T2 d’archivage est réalisé par interrogation d’un registre informatique constitué en chaîne de blocs ou blockchain 9 (selon la terminologie anglo-saxonne).
Pour les besoins de la présente demande, la blockchain 9 est un registre informatique contenant des données subdivisées en blocs 10 (ou blocks) reliés entre eux, contenant chacun :
Un corps 11 comprenant des signatures numériques de transactions (c'est-à-dire d’échanges de données) passées entre des utilisateurs,
Un en-tête 12 contenant des métadonnées parmi lesquelles :
o Un numéro d’ordre, ou rang, ou encore hauteur (height en anglais), qui se présente sous forme d’un entier qui désigne la position du bloc 10 au sein de la blockchain 9 dans l’ordre croissant à partir d’un bloc 10 initial portant le numéro zéro ou le numéro un (comme dans l’exemple illustré sur la FIG.5) et appelé bloc de genèse (Genesis Block en anglais) ;
LAP B008 FR o Une empreinte numérique des données du bloc 10 ;
o L’empreinte numérique (appelée pointeur) du bloc 10 précédent ;
o Une donnée d’horodatage ou timestamp, qui peut se présenter sous forme d’une date (incluant l’année, le mois et le jour, par ex. au format AAA-MM-JJ) ou d’un nombre correspondant au nombre de secondes écoulées depuis une date de référence ou « Epoch >> - par ex. le 1er janvier 1970 pour les systèmes fonctionnant sous le système d’exploitation UNIX (marque déposée).
L’empreinte numérique de chaque bloc 10 se présente sous forme d’une chaîne de caractères, typiquement de 64 caractères codés en base hexadécimale (pouvant chacun prendre une valeur quelconque de 0 à f), ce qui en binaire correspond à une chaîne de 256 bits (ayant chacun la valeur 0 ou la valeur 1).
La valeur de l’empreinte numérique dépend des données du bloc 10 : la moindre modification des données du bloc 10 entraîne la modification de l’empreinte numérique.
Selon un mode particulier de réalisation, l’empreinte numérique de chaque bloc est un condensé (ou condensât, ou hash) des données du bloc 10, c'est-à-dire le résultat d’une fonction de hachage appliquée aux données du bloc (y compris le corps 11 et l’en-tête 12 à l’exception de l’empreinte numérique elle-même). La fonction de hachage est typiquement SHA-256. Sur la FIG.5, l’empreinte numérique est désignée par le terme « Hash >>.
Pour un bloc 10 donné de rang N (N un entier), le pointeur assure avec le bloc 10 précédent de rang N-1 (et. FIG.5) une liaison inaltérable. En effet, toute modification des données du bloc 10 de rang N-1 aboutirait à la modification de son empreinte, et donc à un défaut de correspondance entre cette empreinte (modifiée) du bloc 10 de rang N-1 et le pointeur mémorisé parmi les métadonnées du bloc 10 de rang N.
La succession des blocs 10 reliés entre eux deux à deux par correspondance du pointeur d’un bloc 10 donné de rang N avec l’empreinte numérique du bloc 10 précédent de rang N-1 constitue par conséquent une chaîne de blocs corrélés, dans laquelle la moindre modification des données d’un bloc 10 de rang N-1 se traduit par une
LAP B008 FR rupture du lien avec le bloc 10 suivant de rang N - et donc la rupture de la blockchain 9.
C’est cette structure particulière qui procure aux données contenues dans la blockchain 9 - en particulier aux données d’horodatage - la réputation d’immuabilité.
La blockchain 9 est mémorisée sur un réseau 13 pair à pair composé d’une pluralité de noeuds 14 (chacun formé par un ou plusieurs ordinateurs, ou un ou plusieurs serveurs) qui, ensemble, forment une base de données distribuée.
Plus précisément, la blockchain 9 est mémorisée sur cette base de données distribuée en étant répliquée sur chaque nœud 14. Sur chaque nœud 14 est implémenté un protocole informatique (par ex. Bitcoin ou Ethereum, marques déposées) de participation à l’élaboration de la blockchain 9.
Ce protocole, dit « protocole blockchain », comprend un processus calculatoire d’ajout périodique d’un nouveau bloc 10 de rang N + 1 à la blockchain 9 contenant déjà un nombre N de blocs 10.
Ce processus met en œuvre un mécanisme de validation des blocs 10 par consensus entre tout ou partie des nœuds 14.
Un mécanisme possible, dit de preuve de travail (proof of work ou PoW), consiste à mettre en concurrence les nœuds 14 quant à leur puissance de calcul, en leur imposant une contrainte calculatoire, appelée difficulté, qui se présente typiquement sous forme d’une valeur numérique maximale à ne pas dépasser.
Pour surmonter la difficulté, chaque nœud 14 effectue de manière répétée un calcul de condensé (ou hash) des données du bloc 10 en ajoutant au préalable à ces données une variable (appelée nonce) qui est modifiée à chaque itération tant que le résultat du calcul n’est pas inférieur à la difficulté imposée.
Une particularité des fonctions de hachage, notamment SHA-256, est leur non-récursivité, c'est-à-dire le fait que deux itérations successives du calcul à partir de données initiales proches (ici différentiées par le seul incrément du nonce) produit des résultats décorrélés, ce qui rend impossible la convergence des itérations successives du calcul vers l’objectif (une valeur du condensé ou hash inférieure à la difficulté).
LAP B008 FR
Le premier nœud 14 surmontant la difficulté (c'est-à-dire produisant un condensé ou hash inférieur à la difficulté) est déclaré vainqueur et emporte une prime (ou incentive), généralement sous forme d’un versement prédéterminé en monnaie cryptographique ou cryptomonnaie (actuellement 12,5 bitcoins dans la blockchain Bitcoin).
Le nœud 14 vainqueur communique alors aux autres nœuds 14 le nonce ayant permis de surmonter la difficulté. Les autres nœuds 14 vérifient eux-mêmes la justesse du calcul effectué par le nœud 14 vainqueur et, constatant que la difficulté est effectivement surmontée, valident le nouveau bloc 10 de rang N + 1 en l’ajoutant, chacun, à la blockchain 9 existante qui se trouve ainsi incrémentée d’une unité.
Le timestamp de ce bloc 10 de rang N + 1 correspond, à quelques secondes ou à quelques minutes près, à la date et à l’heure courante à laquelle est fait l’ajout, typiquement sur la base de l’horloge locale du nœud 14 vainqueur (laquelle peut être synchronisée avec les horloges locales des autres nœuds 14), ou encore, lorsque par exemple les nœuds 14 ne sont pas synchronisés, sur la base d’une donnée d’horloge corrigée par l’ajout, à l’heure fournie par l’horloge locale du nœud 14 vainqueur, du décalage temporel moyen (qui peut être négatif) de cette horloge avec celles des autres nœuds 14.
Une fois le bloc 10 de rang N + 1 inséré dans la blockchain 9, les blocs 10 de rang inférieur se trouvent sécurisés contre les altérations malveillantes, et ce d’autant plus que leur numéro de rang est faible devant N + 1.
En particulier, l’insertion du bloc 10 de rang N + 1 sécurise le bloc 10 de rang N, et notamment son timestamp, qui peut dès lors servir de référence temporelle.
Ainsi, il est possible d’interroger la blockchain 9 pour en extraire une donnée temporelle fiable dont on peut déduire au moins la date courante.
Plus précisément, l’interrogation de la blockchain 9 comprend la répétition périodique de la séquence de vérification suivante :
a) Sélectionner un bloc (par ex. le bloc 10 de rang N dans la blockchain 9 comprenant au moins N + 1 blocs 10) ;
b) Extraire le timestamp du bloc 10 sélectionné (ici le bloc 10 de rang N) ;
LAP B008 FR
c) Déterminer, à partir de ce timestamp, une date courante (laquelle comprend au moins le jour courant, mais aussi, le cas échéant, également l’heure courante).
Lorsque le timestamp comprend en lui-même la date courante, au format AAAA-MM-JJ (éventuellement complétée de l’heure courante au format HH:MM:SS), c’est cette date qui est retenue par le système 1.
Lorsque le timestamp se présente sous forme du nombre de secondes écoulées depuis une date de référence (par ex. Epoch), le système 1 est programmé pour calculer la date courante à partir de ce nombre.
Tant que le délai T2 d’archivage est antérieur à la date courante ainsi déterminée, cette séquence de vérification est répétée tandis qu’est maintenu le stockage du conteneur (6Bk) crypté.
En d’autres termes, le délai T2 d’archivage est décrété non expiré tant qu’il n’a pas été atteint ou dépassé par la date courante issue de l’interrogation de la blockchain 9.
L’avantage du recours à la blockchain 9 est que les timestamps des blocs 10 sont très difficilement altérables - et donc très fiables. Il en résulte que la donnée temporelle déterminée à partir de la blockchain 9 est également très fiable, encore plus qu’une donnée temporelle issue d’un serveur, typiquement d’un serveur de temps (ou serveur NTP, cet acronyme étant issu de l’anglais Network Time Protocol), qui bien que réputé fiable demeure sensible aux attaques, notamment de déni de service.
Selon un mode préféré de réalisation, l’unité 8 de contrôle est dépourvue d’instructions pour communiquer à l’utilisateur B destinataire, pendant la phase d’archivage, l’existence même d’un conteneur 6 ou d’un conteneur 6B crypté à son attention, de sorte que l’utilisateur réel (ou les utilisateurs réels) associé(s) à l’utilisateur B destinataire est (sont) tenu(s) dans l’ignorance de cette existence.
Le délai T2 d’archivage est décrété expiré lorsqu’il a été dépassé par la date courante issue de l’interrogation de la blockchain 9.
Dès lors, une troisième phase, dite de partage, inclut l’opération consistant, à l’expiration du délai T2 d’archivage, à permettre à l’utilisateur B destinataire de télécharger le conteneur 6B crypté en vue de le décrypter à l’aide de sa clé BZ privée.
LAP B008 FR
En pratique, l’unité 8 de contrôle est par ex. programmée pour adresser à l’utilisateur B destinataire (notamment via le serveur 4 de communication) une notification de mise à disposition du conteneur 6B crypté. Cette notification contient avantageusement un identifiant IDA associé à l’utilisateur A émetteur. Le téléchargement est alors de préférence commandé par l’utilisateur B destinataire, plutôt qu’effectué automatiquement sur commande de l’unité 8 de contrôle. La connaissance du profil IDA de l’utilisateur A émetteur par l’utilisateur B destinataire peut constituer pour celui-ci un indice de confiance de la provenance et/ou de l’innocuité des données partagées par l’utilisateur A émetteur.
Concrètement, le conteneur 6B crypté est adressé, sur commande de l’unité 8 de contrôle, à l’utilisateur B destinataire via le réseau 3. Le décryptage est réalisé localement par l’utilisateur B destinataire, par l’intermédiaire de sa clé BZ privée stockée localement. L’utilisateur B destinataire peut alors accéder en lecture (et le cas échéant en écriture) au conteneur 6, c'est-à-dire aux fichiers 2 de données qu’il contient, tels que déposés à l’initiative de l’utilisateur A émetteur.
A l’issue du décryptage, les fichiers 2 de données peuvent être stockés localement par l’utilisateur B destinataire.
A l’issue du décryptage, l’utilisateur B destinataire peut adresser (de manière automatique ou sur commande externe) au système 1 une notification de décryptage. Cette notification est reçue par le serveur 4 de communication.
Dans ce cas, il est avantageusement prévu la destruction du conteneur 6 sur le serveur 5 de fichiers après réception, par le système 1, de la notification de décryptage.
De la sorte, de l’espace mémoire est libéré au sein du serveur 5 de fichiers, ce qui facilite la création ultérieure de nouveaux conteneurs 6.
Le procédé (comme le système) qui vient d’être présenté offre un avantage certain en termes de sécurité par comparaison avec les procédés (respectivement les systèmes) connus. En effet, pendant la phase d’archivage, les données des fichiers 2 ne peuvent pas être lues - ni a fortiori modifiées - par l’utilisateur A émetteur ou par l’utilisateur B destinataire. Toute usurpation d’identité de l’un quelconque d’entre eux est inopérante puisqu’il est nécessaire de disposer de la clé privée de l’utilisateur B destinataire pour décrypter le conteneur 6B.
LAP B008 FR
On voit même que le contrôle exercé par l’utilisateur A émetteur sur le conteneur 6 (c'est-à-dire sur les fichiers 2 de données à partager) cesse à l’expiration du délai T1 d’écriture, alors même que son contenu n’est pas encore accessible pour l’utilisateur B 5 destinataire. Le retard (prédéterminé) avec lequel l’utilisateur B destinataire accède aux fichiers 2 de données partagées par l’utilisateur A émetteur rend impossible tout dialogue entre eux en temps réel, au bénéfice de la parcimonie avec laquelle les utilisateurs échangent des données entre eux. Il en résulte notamment une 10 optimisation de la bande passante nécessaire, dans les réseaux, aux échanges entre utilisateurs.

Claims (9)

  1. REVENDICATIONS
    1. Procédé de partage de fichiers (2) de données informatiques entre un utilisateur (A) émetteur et un utilisateur (B) destinataire via un système (1) informatique équipé :
    D’un serveur (4) de communication,
    D’au moins un serveur (5) de fichiers, et
    D’une base (7) de données de profils contenant en mémoire des profils (PA, PB) associés respectivement aux utilisateurs (A, B), chaque profil (PA, PB) comprenant au moins un identifiant (IDA, IDB) et au moins une clé (ZA, ZB) cryptographique publique à laquelle correspond une clé (AZ, BZ) privée ;
    D’une unité (8) de contrôle, reliée au serveur (4) de communication, au serveur (5) de fichier et à la base (7) de données ;
    Ce procédé étant caractérisé en ce qu’il comprend, au niveau du système (1), trois phases successives :
    Une phase d’écriture, qui inclut les opérations consistant à :
    o Recevoir de l’utilisateur (A) émetteur une requête contenant une instruction de création d’un conteneur (6) de données à partager et un identifiant (IDB) de l’utilisateur (B) destinataire ;
    o Créer le conteneur (6) dans un serveur (5) de fichiers ;
    o Associer le conteneur (6) au profil (IDB) correspondant, dans la base (7) de données, à l’utilisateur (B) destinataire ;
    o Associer au conteneur (6) un délai (T1) prédéterminé d’écriture ;
    o Tant que le délai (T1) d’écriture n’a pas expiré, permettre à l’utilisateur (A) émetteur l’accès en écriture au conteneur (6) ;
    Une phase d’archivage, qui inclut les opérations consistant à :
    o A l’expiration du délai (T1) d’écriture, interdire à l’utilisateur (A) émetteur l’accès, au moins en écriture, au conteneur (6) ;
    o Crypter le conteneur (6) à l’aide de la clé (ZB) publique de l’utilisateur (B) destinataire pour former un conteneur (6B) crypté ;
    LAP B008 FR o Associer au conteneur (6B) crypté un délai (T2) prédéterminé d’archivage ;
    o Stocker le conteneur (6B) crypté dans un serveur (5) de fichiers en en interdisant l’accès au moins à l’utilisateur (B) destinataire ;
    o Répéter périodiquement la séquence de vérification suivante :
    a) Sélectionner un bloc (10) dans un registre informatique constitué en chaîne (9) de blocs (10) ayant chacun une donnée d’horodatage ;
    b) Extraire la donnée d’horodatage du bloc (10) sélectionné ;
    c) Déterminer, à partir de cette donnée d’horodatage, une date courante ;
    o Tant que le délai (T2) d’archivage est antérieur à la date courante, répéter la séquence de vérification en maintenant le stockage du conteneur (6Bk) crypté ;
    Une phase de partage, qui inclut l’opération consistant, dès lors que le délai (T2) d’archivage est égal ou postérieur à la date courante, à permettre à l’utilisateur (B) destinataire de télécharger le conteneur (6B) crypté en vue de le décrypter à l’aide de sa clé (BZ) privée.
  2. 2. Procédé selon la revendication 1, dans lequel, l’utilisateur (A) émetteur étant distinct de l’utilisateur (B) destinataire, les profils (PA, PB) associés, dans la base (7) de données de profils, à l’utilisateur (A) émetteur et à l’utilisateur (B) destinataire sont distincts.
  3. 3. Procédé selon la revendication 1 ou la revendication 2, dans lequel le délai (T1) d’écriture est défini par l’utilisateur (A) émetteur.
  4. 4. Procédé selon la revendication 1 ou la revendication 2, dans lequel le délai (T1) d’écriture est défini automatiquement.
  5. 5. Procédé selon l’une des revendications 1 à 4, dans lequel le délai (T2) d’archivage est défini par l’utilisateur (A) émetteur.
  6. 6. Procédé selon l’une des revendications 1 à 4, dans lequel le délai (T2) d’archivage est défini automatiquement.
  7. 7. Procédé selon l’une des revendications précédentes, qui comprend la réception, par le serveur (4) de communication, d’une notification de décryptage du conteneur (6) par l’utilisateur (B) destinataire.
    LAP B008 FR
  8. 8. Procédé selon la revendication 7, qui comprend la destruction du conteneur (6B) crypté sur le serveur (5) de fichiers après réception de la notification de décryptage par l’utilisateur (B) destinataire.
  9. 9. Système (1) informatique qui, pour la mise en oeuvre du procédé selon l’une des revendications précédentes, comprend :
    Un serveur (4) de communication,
    Au moins un serveur (5) de fichiers, et
    Une base (7) de données de profils contenant en mémoire des profils (PA, PB) associés respectivement aux utilisateurs (A, B, chaque profil (PA, PB) comprenant au moins un identifiant (IDA, IDB) et au moins une clé (ZA, ZB) cryptographique publique à laquelle correspond une clé (AZ, BZ) privée,
    Ce système (1) comprenant en outre une unité (8) de contrôle comprenant une mémoire programmable contenant des instructions pour opérer :
    Une phase d’écriture, qui inclut les opérations consistant à :
    o Recevoir de l’utilisateur (A) émetteur une requête contenant une instruction de création d’un conteneur (6) de données à partager et un identifiant (IDB) de l’utilisateur (B) destinataire ;
    o Créer le conteneur (6) dans un serveur (5) de fichiers ;
    o Associer le conteneur (6) au profil (IDB) correspondant, dans la base (7) de données, à l’utilisateur (B) destinataire ;
    o Associer au conteneur (6) un délai (T1) prédéterminé d’écriture ;
    o Tant que le délai (T1) d’écriture n’a pas expiré, permettre à l’utilisateur (A) émetteur l’accès en écriture au conteneur (6) ;
    Une phase d’archivage, qui inclut les opérations consistant à :
    o A l’expiration du délai (T1) d’écriture, interdire à l’utilisateur (A) émetteur l’accès, au moins en écriture, au conteneur (6) ;
    o Crypter les données du conteneur (6) à l’aide de la clé (ZB) publique de l’utilisateur (B) destinataire pour former un conteneur (6B) crypté ;
    o Associer au fichier conteneur (6B) crypté un délai (T2) prédéterminé d’archivage ;
    LAP B008 FR o Stocker le conteneur (6B) crypté dans un serveur (5) de fichiers en en interdisant l’accès au moins à l’utilisateur (B) destinataire ;
    o Répéter périodiquement la séquence de vérification suivante :
    a) Sélectionner un bloc (10) dans un registre informatique constitué en chaîne (9) de blocs (10) ayant chacun une donnée d’horodatage ;
    b) Extraire la donnée d’horodatage du bloc (10) sélectionné ;
    c) Déterminer, à partir de cette donnée d’horodatage, une date courante ;
    o Tant que le délai (T2) d’archivage est antérieur à la date courante, répéter la séquence de vérification en maintenant le stockage du conteneur (6Bk) crypté ;
    Une phase de partage, qui inclut l’opération consistant, dès lors que le délai (T2) d’archivage est égal ou postérieur à la date courante, à permettre à l’utilisateur (B) destinataire de télécharger le conteneur (6B) crypté en vue de le décrypter à l’aide de sa clé (BZ) privée.
FR1857785A 2018-08-30 2018-08-30 Systeme et procede securises de partage retarde de donnees entre un utilisateur emetteur et un utilisateur destinataire, avec creation distante d'un conteneur et horodatage sur blockchain. Pending FR3085509A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1857785A FR3085509A1 (fr) 2018-08-30 2018-08-30 Systeme et procede securises de partage retarde de donnees entre un utilisateur emetteur et un utilisateur destinataire, avec creation distante d'un conteneur et horodatage sur blockchain.
PCT/IB2019/057187 WO2020044216A1 (fr) 2018-08-30 2019-08-27 Système et procédé sécurisés de partage retardé de données entre un utilisateur émetteur et un utilisateur destinataire, avec création distante d'un conteneur et horodatage sur blockchain

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1857785 2018-08-30
FR1857785A FR3085509A1 (fr) 2018-08-30 2018-08-30 Systeme et procede securises de partage retarde de donnees entre un utilisateur emetteur et un utilisateur destinataire, avec creation distante d'un conteneur et horodatage sur blockchain.

Publications (1)

Publication Number Publication Date
FR3085509A1 true FR3085509A1 (fr) 2020-03-06

Family

ID=63722653

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1857785A Pending FR3085509A1 (fr) 2018-08-30 2018-08-30 Systeme et procede securises de partage retarde de donnees entre un utilisateur emetteur et un utilisateur destinataire, avec creation distante d'un conteneur et horodatage sur blockchain.

Country Status (2)

Country Link
FR (1) FR3085509A1 (fr)
WO (1) WO2020044216A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6604197B1 (en) * 1998-05-14 2003-08-05 International Business Machines Corporation Secure flexible electronic submission acceptance system
WO2007003783A2 (fr) * 2005-07-01 2007-01-11 France Telecom Serveur de distribution de donnees numeriques, serveur de decryptage de donnees numeriques, systeme de transmission et procede de transmission de donnees numeriques
US20150339497A1 (en) * 2014-05-23 2015-11-26 Bank Of America Corporation Secure media container

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6604197B1 (en) * 1998-05-14 2003-08-05 International Business Machines Corporation Secure flexible electronic submission acceptance system
WO2007003783A2 (fr) * 2005-07-01 2007-01-11 France Telecom Serveur de distribution de donnees numeriques, serveur de decryptage de donnees numeriques, systeme de transmission et procede de transmission de donnees numeriques
US20150339497A1 (en) * 2014-05-23 2015-11-26 Bank Of America Corporation Secure media container

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ZANTHRA: "A NTP like system in blockchain form, has this been thought of before?", BITCOIN FORUM, 21 January 2018 (2018-01-21), XP055575731, Retrieved from the Internet <URL:https://bitcointalk.org/index.php?topic=2796566.0> [retrieved on 20190329] *

Also Published As

Publication number Publication date
WO2020044216A1 (fr) 2020-03-05

Similar Documents

Publication Publication Date Title
EP3547203A1 (fr) Méthode et système de gestion d&#39;accès à des données personnelles au moyen d&#39;un contrat intelligent
EP3803670A1 (fr) Une application logicielle et un serveur informatique pour authentifier l&#39;identité d&#39;un créateur de contenu numérique et l&#39;intégrité du contenu du créateur publié
CN110289951A (zh) 一种基于门限密钥共享及区块链的共享内容监管方法
WO2020044217A1 (fr) Procédé sécurisé de partage retardé de données entre un utilisateur émetteur et un utilisateur destinataire, avec création locale d&#39;un conteneur et horodatage sur blockchain
WO2020044219A1 (fr) Procédé et système sécurisés de partage retardé de données entre un utilisateur émetteur et plusieurs utilisateurs destinataires, avec création distante d&#39;un conteneur et horodatage sur blockchain
WO2020044216A1 (fr) Système et procédé sécurisés de partage retardé de données entre un utilisateur émetteur et un utilisateur destinataire, avec création distante d&#39;un conteneur et horodatage sur blockchain
WO2020044218A1 (fr) Procédé et système sécurisés de partage retardé de données entre plusieurs utilisateurs émetteur et un utilisateur destinataire, avec horodatage sur blockchain
WO2020044221A1 (fr) Procédé et système sécurisés de partage retardé de données entre plusieurs utilisateurs émetteurs et plusieurs utilisateurs destinataires, avec horodatage sur blockchain
FR3085500A1 (fr) Systeme et procede securises de partage retarde de donnees entre un utilisateur emetteur et plusieurs utilisateurs destinataires, avec creation locale d&#39;un conteneur et horodatage sur blockchain.
WO2020044222A1 (fr) Procédé sécurisé de partage retardé de données entre au moins un utilisateur émetteur et au moins un utilisateur destinataire avec horodatage sur blockchain
Thakur et al. Data integrity techniques in cloud computing: an analysis
WO2020044225A1 (fr) Procédé et système sécurisés de partage retardé de données entre au moins un utilisateur émetteur et au moins un utilisateur destinataire, avec horodatage par interrogation multiple d&#39;une blockchain
WO2019215498A1 (fr) Procédé et système sécurisés de partage retardé de données entre un utilisateur émetteur et plusieurs utilisateurs destinataires, avec création distante d&#39;un conteneur
FR3107416A1 (fr) Tokenisation aléatoire efficace dans un environnement dématérialisé
Vatsaraj et al. Decentralized Document Holder Using Blockchain
Monti et al. An alternative information plan
CN109753813A (zh) 一种文件安全处理方法
EP3903210A1 (fr) Reseau de communication securisee et tracee
WO2019215492A1 (fr) Procede securise de partage retarde de donnees entre un utilisateur emetteur et un utilisateur destinataire, avec creation locale d&#39;un conteneur
FR3081066A1 (fr) Systeme et procede securises de partage retarde de donnees entre un utilisateur emetteur et un utilisateur destinataire, avec creation distante d&#39;un conteneur.
FR3081061A1 (fr) Procede securise de partage retarde de donnees entre un utilisateur emetteur et plusieurs utilisateurs destinataires, avec creation locale d&#39;un conteneur.
WO2020044226A1 (fr) Procédé et système sécurisés de partage retardé de données entre au moins un utilisateur émetteur et au moins un utilisateur destinataire, sous le contrôle d&#39;un tiers de confiance
FR3081065A1 (fr) Procede et systeme securises de partage retarde de donnees entre plusieurs utilisateurs emetteurs et plusieurs utilisateurs destinataires.
WO2019215493A1 (fr) Procédé et système sécurisés de partage retardé de données entre plusieurs utilisateurs émetteur et un utilisateur destinataire
FR3081067A1 (fr) Procede et systeme securises de partage retarde de donnees entre au moins un utilisateur emetteur et au moins un utilisateur destinataire.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200306

PLFP Fee payment

Year of fee payment: 3

RX Complete rejection

Effective date: 20210805