FR 3085506 A1 20200306 FR 1857797 A 20180830 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 L'invention a trait au domaine de l'informatique, et plus précisément du partage de fichiers de données informatiques entre plusieurs utilisateurs émetteurs et plusieurs utilisateurs destinataires. 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 20 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 25 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 30 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. 35 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 B013 FR 2 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 5 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. 10 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 15 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 P (P un entier, P 2) utilisateurs destinataires, 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 à : Recevoir d'un utilisateur émetteur maître une requête contenant une instruction de création d'un conteneur de LAP B013 FR 3 données à partager, un identifiant de chaque autre utilisateur émetteur et un identifiant de chaque utilisateur destinataire ; o Créer le conteneur dans un serveur de fichiers ; o Associer au conteneur un délai prédéterminé d'écriture ; 5 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 aux utilisateurs émetteurs l'accès, au moins en écriture, au conteneur ; 10 o Effectuer une copie du conteneur pour chaque utilisateur destinataire, en associant chaque copie au profil correspondant, dans la base de données, à l'utilisateur destinataire ; o Crypter chaque copie du conteneur à l'aide de la clé publique 15 de l'utilisateur destinataire pour former un conteneur crypté ; o Associer à chaque 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 ; 20 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é ; 25 c) Déterminer, à partir de cette donnée d'horodatage, une date courante ; 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 30 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 : Le délai d'écriture peut être défini par l'utilisateur émetteur maître, ou automatiquement. 35 - Le délai d'archivage peut être défini par l'utilisateur émetteur maitre, ou automatiquement. LAP B013 FR 4 Le délai d'archivage peut être défini séparément pour chaque utilisateur destinataire. Le conteneur est avantageusement subdivisé en plusieurs espaces mémoires propres, chacun alloué à un utilisateur émetteur 5 respectif. Dans ce cas, l'accès par un utilisateur émetteur à un espace mémoire d'un autre utilisateur émetteur est de préférence interdit. Il peut être prévu la réception, par le serveur de communication, d'une notification de décryptage du conteneur par chaque 10 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 couvre du procédé tel que présenté ci-dessus, 15 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 20 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 à : 25 o Recevoir d'un utilisateur émetteur maître une requête contenant une instruction de création d'un conteneur de données à partager, un identifiant de chaque autre utilisateur émetteur et un identifiant de chaque utilisateur destinataire ; o Créer le conteneur dans un serveur de fichiers ; 30 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 à 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 aux utilisateurs 35 émetteurs l'accès, au moins en écriture, au conteneur ; LAP B013 FR 5 o Effectuer une copie du conteneur pour chaque utilisateur destinataire, en associant chaque copie au profil correspondant, dans la base de données, à l'utilisateur destinataire ; 5 o Crypter chaque copie du conteneur à l'aide de la clé publique de l'utilisateur destinataire pour former un conteneur crypté ; o Associer à chaque conteneur crypté un délai prédéterminé d'archivage ; o Stocker le conteneur crypté dans un serveur de fichiers en en 10 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 ; 15 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 20 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. 25 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 ; 30 - 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 35 l'invention ; LAP B013 FR 6 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 5 entre N utilisateurs Ai émetteurs (N un entier tel que N 2 ; i un entier tel que 1 i N) et P utilisateurs Bk destinataires (P un entier tel que P 2 ; k un entier tel que 1 2) de chaque autre utilisateur Ai (i > 2) 20 émetteur, et un identifiant IDBk de chaque utilisateur Bk destinataire ; o Créer le conteneur 6 dans un serveur 5 de fichiers ; - 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 à 25 chaque utilisateur Ai émetteur l'accès en écriture au conteneur 6. En pratique, l'utilisateur Al émetteur maître 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 30 les vérifications d'identité de l'utilisateur Al émetteur maître, typiquement par comparaison d'une information communiquée par celui-ci (par ex. un mot de passe) avec une information associée à son profil IDA1 tel que mémorisé dans la base 7 de données. Dès lors que l'utilisateur Al émetteur maître est identifié, accès lui est donné 35 (éventuellement par un autre canal de communication, comme illustré sur la FIG.1) au serveur 5 de fichiers. LAP B013 FR 8 Le système 1 vérifie que les identifiants IDAi (i > 2) communiqués par l'utilisateur Al émetteur maître correspondent effectivement à des profils utilisateurs PAi mémorisés. Dès lors, pendant la phase d'écriture, chaque utilisateur Ai 5 é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 chaque terminal Ai 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 10 compte à rebours) peut être défini par l'utilisateur Al émetteur maître, 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, par ex. au moyen d'une horloge interne pilotée par (ou intégrée à) l'unité 8 de contrôle. 15 Selon un mode avantageux illustré sur la FIG.4, le conteneur 6 est subdivisé en plusieurs espaces 6.i mémoires propres, chacun alloué à un utilisateur Ai émetteur respectif - c'est-à-dire que les fichiers 2 de données déposés par chaque utilisateur Ai émetteur dans son espace 6.i mémoire propre n'affectent pas les fichiers 2 de données déposés 20 par un autre utilisateur Al émetteur (j un entier tel que j i) dans son espace 6.j mémoire propre. Il est même préférable que soit interdit l'accès (en lecture et/ou en écriture) par un utilisateur Ai émetteur à un espace 6.j mémoire propre alloué à un autre utilisateur Aj émetteur. 25 Une deuxième phase, dite d'archivage, inclut les opérations consistant à : o A l'expiration du délai T1 d'écriture, interdire à chaque utilisateur Ai émetteur l'accès, au moins en écriture, au conteneur 6 ; 30 o Effectuer une copie du conteneur 6 pour chaque utilisateur Bk destinataire, en associant chaque copie au profil IDBk correspondant, dans la base 7 de données, à l'utilisateur Bk destinataire ; o Crypter chaque copie du conteneur 6 à l'aide de la clé ZBk 35 publique de l'utilisateur Bk destinataire pour former un conteneur 6Bk crypté ; LAP B013 FR 9 o Associer à chaque conteneur 6Bk 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 6Bk crypté dans un serveur 5 de fichiers en en 5 interdisant l'accès au moins à l'utilisateur Bk destinataire. On a illustré sur la FIG.4 l'obtention de deux conteneurs 6Bk, 6B1 (I un entier tel que I k) cryptés à l'aide, respectivement, des clés publiques ZBk, ZBI de deux utilisateurs Bk, BI destinataires distincts ayant chacun leur clé BkZ, BIZ privée respective. 10 Le délai T2 d'archivage (schématisé sur les dessins par un deuxième compte à rebours) peut être défini par l'utilisateur Al émetteur maître, ou automatiquement. Le délai T2 d'archivage est avantageusement implémenté au sein du système 1 informatique, et plus précisément dans l'unité 8 de contrôle. 15 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 délai T2 d'archivage peut être défini séparément pour chaque utilisateur Bk destinataire. 20 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 25 (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 : 30 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) 35 et appelé bloc de genèse (Genesis Block en anglais) ; o Une empreinte numérique des données du bloc 10 ; LAP B013 FR 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 5 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 c, Epoch » - par ex. le 1 er janvier 1970 pour les systèmes fonctionnant sous le système d'exploitation UNIX (marque déposée). 10 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 une chaîne de 256 bits (ayant 0 à f), ce qui en binaire correspond à chacun la valeur 0 ou la valeur 1). 15 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 condensat, ou hash) des données du 20 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 ». 25 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 (cf. 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 30 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 35 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 B013 FR 11 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 5 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. 10 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 noeud 14. Sur chaque noeud 14 est implémenté un protocole informatique (par ex. Bitcoin ou Ethereum, marques déposées) de participation à l'élaboration de la blockchain 9. 15 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 oeuvre un mécanisme de validation des blocs 10 par consensus entre tout ou partie des noeuds 14. 20 Un mécanisme possible, dit de preuve de travail (proof of work ou PoW), consiste à mettre en concurrence les noeuds 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. 25 Pour surmonter la difficulté, chaque noeud 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. 30 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 35 successives du calcul vers l'objectif (une valeur du condensé ou hash inférieure à la difficulté). LAP B013 FR 12 Le premier noeud 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 5 cryptomonnaie (actuellement 12,5 bitcoins dans la blockchain Bitcoin). Le noeud 14 vainqueur communique alors aux autres noeuds 14 le nonce ayant permis de surmonter la difficulté. Les autres noeuds 14 vérifient eux-mêmes la justesse du calcul effectué par le noeud 14 vainqueur et, constatant que la difficulté est effectivement surmontée, 10 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 15 noeud 14 vainqueur (laquelle peut être synchronisée avec les horloges locales des autres noeuds 14), ou encore, lorsque par exemple les noeuds 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 noeud 14 vainqueur, du décalage temporel moyen (qui peut être négatif) 20 de cette horloge avec celles des autres noeuds 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. 25 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 30 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) ; 35 b) Extraire le timestamp du bloc 10 sélectionné (ici le bloc 10 de rang N) ; LAP B013 FR 13 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 5 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 10 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é 15 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 20 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. 25 Selon un mode préféré de réalisation, l'unité 8 de contrôle est dépourvue d'instructions pour communiquer à chaque l'utilisateur Bk destinataire, pendant la phase d'archivage, l'existence même d'un conteneur 6 ou d'un conteneur 6Bk crypté à son attention, de sorte que les utilisateurs réels associés aux utilisateurs Bk destinataires sont 30 tenus 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 à chaque 35 utilisateur Bk destinataire de télécharger le conteneur 6Bk crypté en vue de le décrypter à l'aide de sa clé BkZ privée. LAP B013 FR 14 Concrètement, l'unité 8 de contrôle est par ex. programmée pour adresser à l'utilisateur Bk destinataire (notamment via le serveur 4 de communication) une notification de mise à disposition du conteneur 6Bk crypté. Cette notification contient avantageusement un identifiant IDA1 5 associé à l'utilisateur Al émetteur maître, ou un identifiant IDAi associé à chaque utilisateur Ai émetteur. Le téléchargement est alors de préférence commandé par l'utilisateur Bk destinataire, plutôt qu'effectué automatiquement sur commande de l'unité 8 de contrôle. La connaissance au moins du profil IDA1 de l'utilisateur Al émetteur 10 maître (et de préférence des profils IDAi de tous les utilisateurs émetteurs) par l'utilisateur Bk destinataire peut constituer pour celui-ci un indice de confiance de la provenance et/ou de l'innocuité des données partagées par les utilisateurs Ai émetteurs. Concrètement, chaque conteneur 6Bk crypté est adressé, sur 15 commande de l'unité 8 de contrôle, à l'utilisateur Bk destinataire correspondant via le réseau 3. Le décryptage est réalisé localement par l'utilisateur Bk destinataire, par l'intermédiaire de sa clé BkZ privée stockée localement. L'utilisateur Bk destinataire peut alors accéder en lecture (et le cas échéant en écriture) au conteneur 6, c'est-à-dire aux 20 fichiers 2 de données qu'il contient, tels que déposés à l'initiative de l'utilisateur A émetteur. On a illustré sur la FIG.4 l'envoi des deux conteneurs 6Bk, 6B1 cryptés aux deux utilisateurs Bk, BI destinataires respectifs : on voit que chaque utilisateur Bk, BI destinataire effectue le décryptage à 25 l'aide de sa clé BkZ, BIZ privée respective pour accéder aux fichiers 2. A l'issue du décryptage, les fichiers 2 de données peuvent être stockés localement par chaque utilisateur Bk destinataire. A l'issue du décryptage, chaque utilisateur Bk destinataire peut adresser (de manière automatique ou sur commande externe) au 30 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 6Bk crypté correspondant sur le serveur 5 de fichiers après réception, par le système 1, de la notification de décryptage. 35 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. LAP B013 FR 15 Le procédé (et 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 5 - ni a fortiori modifiées - par l'un quelconque des utilisateurs Ai émetteurs ou par l'un quelconque des utilisateurs Bk destinataires. 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 Bk destinataire pour décrypter le conteneur 6Bk. 10 On voit même que le contrôle exercé par les utilisateurs Ai émetteurs 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 encore accessible pour aucun utilisateur Bk destinataire. Le retard (prédéterminé) avec lequel les utilisateurs Bk 15 destinataires accède aux fichiers 2 de données partagées par les utilisateurs Ai émetteurs 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 optimisation de la bande passante nécessaire, dans les réseaux, REVENDICATIONS1. Procédé de partage de fichiers (2) de données informatiques entre N utilisateurs (Ai) émetteurs (N un entier, N > 2 ; i un entier tel que 1 2 ; k un entier tel que 1 2) de chaque utilisateur (Ai où i > 2) émetteur et un identifiant (IDBk) de chaque utilisateur (Bk) destinataire ; - Créer le conteneur (6) dans un serveur (5) de fichiers ; o Associer au conteneur (6) un délai (T1) prédéterminé d'écriture ; o Tant que le délai (Ti) d'écriture n'a pas expiré, permettre à chaque utilisateur (Ai) émetteur l'accès en écriture au conteneur (6) ; Une phase d'archivage, qui inclut les opérations consistant à : - A l'expiration du délai (Ti) d'écriture, interdire aux utilisateurs (Ai) émetteurs l'accès, au moins en écriture, au conteneur (6) ; LAP B013 FR 17 o Effectuer une copie du conteneur (6) pour chaque utilisateur (Bk) destinataire, en associant chaque copie au profil (IDBk) correspondant, dans la base (7) de données, à l'utilisateur (Bk) destinataire ; 5 o Crypter chaque copie du conteneur (6) à l'aide de la clé (ZBk) publique de l'utilisateur (Bk) destinataire pour former un conteneur (6Bk) crypté ; o Associer à chaque conteneur (6Bk) crypté un délai (T2) prédéterminé d'archivage ; 10 o Stocker le conteneur (6Bk) crypté dans un serveur (5) de fichiers en en interdisant l'accès au moins à l'utilisateur (Bk) destinataire ; o Répéter périodiquement la séquence de vérification suivante : a) Sélectionner un bloc (10) dans un registre informatique 15 constitué en chaîne (9) de blocs 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 20 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 25 que le délai (T2) d'archivage est égal ou postérieur à la date courante, à permettre à l'utilisateur (Bk) destinataire de télécharger le conteneur (6Bk) crypté en vue de le décrypter à l'aide de sa clé (BkZ) privée. 2. Procédé selon la revendication 1, dans lequel le délai (Ti) 30 d'écriture est défini par l'utilisateur (A1) émetteur maître. 3. Procédé selon la revendication 1, dans lequel le délai (Ti) d'écriture est défini automatiquement. 4. Procédé selon l'une des revendications 1 à 3, dans lequel le délai (T2) d'archivage est défini par l'utilisateur (A1) émetteur maître. 35 5. Procédé selon l'une des revendications 1 à 3, dans lequel le délai (T2) d'archivage est défini automatiquement. LAP B013 FR 18 6. Procédé selon l'une des revendications précédentes, dans lequel le délai (T2) d'archivage est défini séparément pour chaque utilisateur (Bk) destinataire. 7. Procédé selon l'une des revendications précédentes, dans 5 lequel le conteneur (6) est subdivisé en plusieurs espaces (6.i) mémoires propres, chacun alloué à un utilisateur (Ai) émetteur respectif. 8. Procédé selon l'une des revendications précédentes, qui comprend la réception, par le serveur (4) de communication, d'une 10 notification de décryptage du conteneur (6) par chaque utilisateur (Bk) destinataire. 9. Procédé selon la revendication 8, qui comprend la destruction du conteneur (6Bk) crypté sur le serveur (5) de fichiers après réception de la notification de décryptage par l'utilisateur (Bk) destinataire. 15 10. 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 20 profils (PAi, PBk) associés respectivement aux utilisateurs (Ai, Bk), chaque profil (PAi, PBk) comprenant au moins un identifiant (IDAi, IDBk) et au moins une clé (ZAi, ZBk) cryptographique publique à laquelle correspond une clé (AiZ, BkZ) privée, Ce système (1) comprenant en outre une unité (8) de contrôle 25 comprenant une mémoire programmable contenant des instructions pour opérer : - Une phase d'écriture, qui inclut les opérations consistant à : o Recevoir d'un utilisateur (Al) émetteur maître une requête contenant une instruction de création d'un conteneur (6) de 30 données à partager, un identifiant (IDAi où i > 2) de chaque utilisateur (Ai où i > 2) émetteur et un identifiant (IDBk) de chaque utilisateur (Bk) destinataire ; o Créer le conteneur (6) dans un serveur (5) de fichiers ; - Associer au conteneur (6) un délai (Ti) prédéterminé 35 d'écriture ; LAP B013 FR 19 o Tant que le délai (T1) d'écriture n'a pas expiré, permettre à chaque utilisateur (Ai) émetteur l'accès en écriture au conteneur (6) ; Une phase d'archivage, qui inclut les opérations consistant à : 5 o A l'expiration du délai (T1) d'écriture, interdire aux utilisateurs (Ai) émetteurs l'accès, au moins en écriture, au conteneur (6) ; o Effectuer une copie du conteneur (6) pour chaque utilisateur (Bk) destinataire, en associant chaque copie au profil (IDBk) 10 correspondant, dans la base (7) de données, à l'utilisateur (Bk) destinataire ; o Crypter chaque copie du conteneur (6) à l'aide de la clé (ZBk) publique de l'utilisateur (Bk) destinataire pour former un conteneur (6Bk) crypté ; 15 o Associer à chaque conteneur (6Bk) crypté un délai (T2) prédéterminé d'archivage ; o Stocker le conteneur (6Bk) crypté dans un serveur (5) de fichiers en en interdisant l'accès au moins à l'utilisateur (Bk) destinataire ; 20 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 ayant chacun une donnée d'horodatage ; b) Extraire la donnée d'horodatage du bloc (10) 25 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 30 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 (Bk) destinataire de télécharger le conteneur (6Bk) crypté en vue de le décrypter à 35 l'aide de sa clé (BkZ) privée. LAP B013 FR