FR 3163518 A1 20251219 FR 2406249 A 20240612 L’invention concerne un procédé de gestion d’un groupe comprenant une pluralité de membres (U 1 … U n ), chaque membre (U i ) détenant ou étant en mesure de détenir une clé secrète (SKj,k,p) de groupe. Le procédé fait appel à un crypto-système asymétrique et à un registre (B) dans lequel un smart contract (SC) est déployé. Une structure de données telle qu’un arbre binaire ou une liste chaînée (A) est utilisée pour ordonner les membres du groupe. Le procédé comprend une procédure d’ajout de membre pour intégrer au groupe un candidat souhaitant rejoindre le groupe, durant laquelle par des opérations similaires au protocole de Diffie-Hellman et à l’aide du smart contract , le nouveau membre est ajouté au groupe, et une nouvelle clé secrète du groupe est calculée et partagée par chacun des membres du groupe y compris le nouveau membre. Figure pour l’abrégé : figure 1. Procédé de gestion d’un groupe partageant une clé secrète DOMAINE TECHNIQUE DE L’INVENTION Le domaine de l’invention est la réalisation d’opérations de manière sécurisée par un ou plusieurs membres d’un groupe. Ces opérations sont notamment l’échange de messages entre les membres du groupe, le contrôle d’accès à des zones sensibles (en utilisant un identifiant unique), etc. Pour assurer la réalisation de telles opérations de manière sécurisée, de manière connue en soi un secret de groupe, que l’on peut également appeler une clé secrète, peut être partagée par les membres du groupe. Par conséquent, l’invention plus précisément concerne un procédé de gestion de groupe permettant le partage d’un secret de groupe au sein du groupe. ÉTAT DE LA TECHNIQUE La communication d’informations entre personnes, par exemple au moyen d’une application de messagerie instantanée, nécessite la prise en compte d’un certain nombre de contraintes. Une telle application peut devoir fournir une garantie de confidentialité au sein de chaque groupe, et protéger les données d’identification des membres, afin de répondre aux différentes règlementations applicables, comme par exemple la Règlementation Globale de Protection des Données à caractère Personnel dans l’Union Européenne. La réalisation d’une telle application est particulièrement complexe dans un contexte où les membres communiquent via leurs dispositifs personnels, par exemple des smartphones, formant un réseau décentralisé de communications asynchrones. Pour réaliser une telle application avec un niveau élevé de sécurité des communications, une solution connue consiste à gérer chaque groupe de membres devant échanger des messages de manière sécurisée de telle sorte qu’un secret commun soit partagé entre les membres du groupe. Ce secret commun servira alors (notamment) à calculer une clé de chiffrement, par exemple symétrique, pour permettre l’échange d’informations entre les membres du groupe de manière sécurisée. Cela étant, maintenir un secret commun et singulier à chaque groupe permettant à ses membres d’échanger des messages chiffrés connus de eux seuls, de telle façon que ce secret soit mis à jour à chaque nouveau départ ou arrivée d’un membre dans le groupe, tout en assurant aux autres membres du groupe la continuité des échanges confidentiels, requiert d’assurer plusieurs propriétés : La continuité de mise à jour ( update ) de la clé de chiffrement du groupe lors de l’arrivée d’un nouveau membre, La mise à niveau ( upgrade ) de la clé de chiffrement du groupe lors du départ d’un membre, L’accès à tout moment ( continuous access ) à la clé de chiffrement du groupe à tous les membres du groupe. Des exigences de sécurité peuvent s’ajouter, notamment : Que les secrets soient calculés et conservés au niveau de chaque dispositif utilisateur légitime à les connaitre, D’éviter les points de défaillance unique dans le système, dont une attaque pourrait compromettre la disponibilité et/ou la confidentialité de la solution, D’éviter les attaques de type ‘man-in-the-middle’ tout en préservant les données d’identification des membres. Pour permettre qu’un secret cryptographique commun soit partagé entre les membres d’un groupe, il est nécessaire de chiffrer des données afin de les échanger de façon confidentielle au sein du groupe. Cela nécessite un moyen pour partager des informations intermédiaires publiques permettant le calcul du secret commun en privé. Si les dispositifs de communication des membres du groupe sont connectés au sein d’un même réseau, ils peuvent échanger des messages permettant la création du secret commun. Par exemple, à travers internet, des informations publiques (telles que des clés publiques) peuvent être transmises si les adresses IP de chacun des membres du groupe sont connues de tous les autres membres. Dans la plupart des applications de messagerie existantes, un serveur est utilisé pour l'échange d’informations publiques au sein d’un groupe. Cependant, un tel serveur centralisé constitue un point de défaillance potentiel unique, particulièrement exposé par conséquences à différentes attaques cyber telles que les attaques par déni de service, attaques de type « man in the middle » , par malware s , etc. Pour éviter une telle faiblesse, une solution alternative consiste à utiliser la b lockchain pour permettre le partage d’informations entre deux personnes. De tels procédés de communication sont divulgués par exemple par les demandes de brevet français n°1763393 et n°1763394. Les procédés divulgués par ces brevets font appel au protocole de Diffie-Hellman pour l’échange d’informations entre deux acteurs. Ce protocole est une procédure permettant la génération d’un secret partagé entre deux personnes, connu seulement de ces deux personnes. La génération d’une telle clé de session s’appuie sur la possession d’une paire de clés asymétrique par chacune des deux personnes impliquées dans le protocole de Diffie-Hellman. Ainsi en mettant en œuvre ce protocole, une personne disposant d’une paire de clés asymétrique qui lui est propre est en mesure d’initier le calcul d’un secret partagé avec une autre personne disposant elle aussi d’une paire de clés asymétrique qui lui est propre. Pour la mise en œuvre de ce protocole de Diffie-Hellman, chacune des deux personnes doit disposer d’une paire de clés asymétrique, comprenant une clé privée et la clé publique correspondante (cette paire de clés asymétrique est donc calculée au moyen d’un crypto-système asymétrique). L’algorithme de cryptographie asymétrique utilisé est généralement un algorithme d'arithmétique modulaire : Le crypto-système peut être un crypto-système de Rivest–Shamir–Adleman , RSA), ou fondé sur des courbes elliptiques ( Elliptic Curve Cryptography , ECC). Le protocole de Diffie-Hellman comporte les étapes suivantes : A1) chacune des deux personnes enregistre la clé publique de sa paire de clés asymétrique dans le registre ; A2) chacune des deux personnes lit dans le registre la clé publique de l’autre ; et A3) chacune des deux personnes construit le secret partagé. Le protocole de Diffie-Hellman permet ainsi de générer un secret partagé entre deux personnes. Il est décrit plus en détail dans les demandes de brevet français n°1763393 et n°1763394 citées ci-dessus. Cependant, les procédés de communication sont limités à l’échange entre deux personnes. D’autres procédés ont été développés sur la base du protocole de Diffie-Hellman pour permettre l’échange sécurisé d’informations au sein d’un groupe comportant plus de deux personnes. Parmi ces procédés, les plus connus font appel à des représentations du groupe en anneau et en arbre. Dans ces derniers procédés, la génération d’un secret partagé par le groupe nécessite plusieurs exécutions successives du protocole de Diffie-Hellman. La principale différence entre ces différents procédés est l'organisation et l'ordre d’exécution de ces protocoles. Cependant, ces derniers procédés ne présentent pas un niveau de sécurité suffisant vis-à-vis des attaques de type « man in the middle ». Il existe donc un besoin de procédés de communication permettant l’échange d’informations de manière sécurisée entre membres d’un groupe, ces procédés étant robustes vis-à-vis d’attaques de type « man in the middle », et ne nécessitant pas l’utilisation d’un serveur central. La présente invention vise à remédier à tout ou partie des inconvénients de l’état de la technique cités ci-dessus. Pour permettre la réalisation d’applications de messagerie entre membres d’un groupe, ou plus généralement d’applications permettant l’échange d’informations entre membres d’un groupe, selon la présente divulgation, un procédé de gestion de groupe permettant le partage d’un secret de groupe (plus précisément une clé secrète de groupe) au sein du groupe est proposée. En effet, avantageusement la détention d’une clé secrète de groupe commun au sein d’un groupe permet de déterminer une clé de chiffrement, par exemple symétrique : cela permet alors l’échange d’informations de manière sécurisée entre les membres du groupe. Selon un premier aspect de l’invention, un premier procédé de gestion d’un groupe est proposé, dans lequel le groupe est suivi à l’aide d’un arbre binaire. Le procédé est un procédé de gestion d’un groupe comprenant une pluralité de membres, chaque membre détenant ou étant en mesure de détenir une clé secrète de groupe, le procédé faisant appel à un crypto-système asymétrique (Enc,Dec) vérifiant la propriété, pour deux paires de clés asymétriques (PK1,SK1) et (PK2,SK2) : Enc(PK1,SK2) = Enc(SK1,PK2), où Enc est la fonction de chiffrement du crypto-système, et à un registre dans lequel un smart contract est déployé ; un arbre binaire étant utilisé pour ordonner les membres du groupe ; chaque membre étant associé à un nœud terminal de l’arbre, ce nœud étant rattaché à un nœud racine de l’arbre, directement ou via une suite d’au moins un nœud, le nœud racine et lorsqu’elle existe ladite suite d’au moins un nœud constituant la chaîne de rattachement du membre considéré ; chaque membre du groupe disposant d’une paire de clés asymétrique, dont la clé secrète et la clé publique sont considérées comme la clé secrète de nœud et la clé publique de nœud pour le nœud terminal associé au membre ; la clé publique du nœud racine étant appelée clé publique du groupe ; le procédé comprenant une procédure d’ajout de membre pour intégrer au groupe un candidat souhaitant rejoindre le groupe, à un instant donné où le groupe est constitué par un ensemble de membres, dits membres avant-ajout, formant un arbre avant-ajout, chaque membre avant-ajout dispose de ou est en mesure de calculer une clé secrète avant-ajout de nœud pour tout nœud de sa chaîne de rattachement ; et pour chaque nœud de l’arbre avant-ajout, une clé publique avant-ajout de nœud est enregistrée dans le registre ; la procédure d’ajout de membre comprenant les opérations suivantes : S10) une demande d’admission dans le groupe du candidat est transmise au smart contract , la demande d’admission comprenant un authentifiant et une clé publique personnelle du candidat, le candidat détenant en outre une clé privée personnelle à partir de laquelle sa clé publique personnelle a été calculée au moyen du crypto-système ; S20) le smart contract enregistre dans le registre l’admission dans le groupe d’un nouveau membre ayant l’authentifiant du candidat et la clé publique du candidat ; S30) le candidat détermine ou obtient du smart contract une liste du ou des nœuds de sa chaîne de rattachement dans l’arbre ; S40) de proche en proche, pour chaque nœud de sa chaîne de rattachement, depuis le nœud de l’arbre auquel il est directement rattaché jusqu’au nœud racine (N1), le candidat calcule la clé secrète de nœud puis la clé publique de nœud ; S50) le candidat publie dans le registre la ou les clé(s) publique(s) de nœud calculée(s) à l’étape S40 ; S60) le smart contract envoie un message d’ajout de membre au moins à chaque membre actif avant-ajout du groupe ; et S70) à réception du message d’ajout de membre, de proche en proche, pour chaque nœud de sa chaîne de rattachement qui fait également partie de la chaîne de rattachement du candidat, dans le sens allant du nœud de l’arbre auquel il est directement rattaché vers le nœud racine, chaque membre actif avant-ajout calcule la clé secrète de nœud ; la clé secrète de nœud d’un nœud donné étant calculée par une personne dont la chaîne de rattachement contient un premier fils du nœud donné: - si ledit nœud donné a un deuxième fils et que ladite personne a accès à une clé publique non compromise du deuxième fils, en fonction de la clé secrète du premier fils actif et de la clé publique dudit deuxième fils dudit nœud donné ; ou dans tout autre cas, - en fonction de la clé secrète du premier fils dudit nœud donné. La méthode définie ci-dessus peut être mise en œuvre avec différents crypto-systèmes, à condition qu’ils vérifient la propriété énoncée ci-dessus (Enc(PK1,SK2) = Enc(SK1,PK2)). Il est ainsi possible de choisir un crypto-système sur courbes elliptique, un crypto-système RSA, ou éventuellement certains crypto-systèmes post-quantiques notamment à base de lattices. Pour la mise en œuvre du procédé, en outre une règle d’ajout de nouveau membre dans l’arbre (également appelée règle de construction de l’arbre) est choisie préalablement. Selon la règle qui est choisie, la position dans l’arbre à laquelle un nouveau membre du groupe est ajouté soit peut être calculée simplement à partir de l’information des arrivées et départs successifs des membres du groupe, soit résulte d’un choix. Dans le premier cas, à l’étape S30 le candidat peut déterminer lui-même sa chaîne de rattachement. C’est le cas par exemple si lors de la construction de l’arbre, d’une part en cas de départ d’un membre, aucun nouveau membre ne reprend la position de celui-ci ; et si les candidats sont placés dans l’arbre de telle sorte que tous les membres du groupe, à tout instant, soient placés à un même niveau dans l’arbre, et placés à ce niveau par ordre chronologique de dernière admission dans le groupe. Dans le deuxième cas, la position dans l’arbre affectée à un nouveau membre peut être déterminée par le smart contract ; celui-ci communique alors sa chaîne de rattachement au candidat, lors de son admission à l’étape S30. A l’étape S10, selon le cas, la demande d’admission dans le groupe du candidat peut être transmise au smart contract soit directement par le candidat (le groupe est alors dit ‘groupe ouvert’), ou soit par une personne chargée de vérifier qu’il y a bien lieu d’admettre le candidat dans le groupe, par exemple un administrateur du groupe. Avantageusement, à la suite de l’opération d’ajout de membre, chacun des membres du groupe – c’est-à-dire à la fois les membres avant-ajout et le nouveau membre (le candidat) -, dispose de ou est en mesure de calculer la clé secrète de nœud pour tout nœud de sa chaîne de rattachement. Les membres du groupe sont authentifiés dans le registre par leur adresse de compte qui est un authentifiant, noté accUser. Cet authentifiant sert de manière permanente à identifier le membre lors de ses interactions avec le smart contract . Ainsi, grâce notamment à l’utilisation du smart contract , le procédé proposé ci-dessus permet de constituer un groupe partageant une clé secrète de groupe avec un degré de sécurité élevé, seules des informations publiques (des clés publiques) étant transmises pour la constitution de la clé secrète de groupe. Notamment, le procédé proposé avantageusement ne nécessite pas l’utilisation d’un serveur central. Dans le présent document, les définitions et conventions suivantes sont utilisées. Un registre, appelé également ‘ledger’, désigne une structure dans laquelle sont enregistrées des données de manière sécurisée, dans le domaine des technologies de type ‘Distributed Ledger Technology’. Un registre est généralement distribué. Un registre peut être ouvert (ou ‘permissionless’), c’est-à-dire que toute personne peut consulter les données enregistrées dans le registre. Un exemple typique de registre est une blockchain , par exemple de type Bitcoin ou Ethereum. Un smart contract (parfois traduit ‘contrat intelligent’) est un code prévu pour interagir avec un registre, et enregistré dans celui-ci à une adresse spécifique au smart contract . Au moment du minage, les nœuds validateurs exécutent le smart contract ; s’il y a consensus sur le résultat, celui-ci est enregistré dans le registre. Les expressions ‘une nouvelle clé est calculée’ ou ‘une nouvelle valeur pour la clé est calculée’ ont le même sens et peuvent être utilisées de manière interchangeable. La blockchain présente l’avantage d’être décentralisée et ne présente pas de point de défaillance unique. Par ailleurs, la blockchain est robuste à la plupart des attaques par déni de service grâce à l’usage de gas , aux attaques man in the middle grâce à l’usage des adresses de compte comme authentifiants, ainsi qu’aux malwares en rendant le contenu du registre transparent et consultable par tous les acteurs. Ainsi avantageusement, le procédé selon la présente divulgation répond aux exigences protocolaires ( update , upgrade , continuous access ) à travers un procédé performant, efficace et sécurisé. De plus, le procédé selon la présente divulgation prend également en compte les exigences de sécurité et de protection des données à caractère personnel et des données identifiantes des membres, à travers une architecture novatrice décentralisée s’appuyant sur le smart contract exécuté sur une blockchain . Naturellement, un crypto-système de cryptographie asymétrique est défini sur un corps commutatif. Dans certains modes de mise en œuvre, le procédé comprend en outre une procédure de retrait d’un membre du groupe, dit membre partant (Up), autre que le membre ayant rejoint le groupe en dernier, pour retirer du groupe le membre partant, ladite procédure de retrait de membre comprenant : S100) une demande de retrait du membre partant est envoyée au smart contract ; S110) le smart contract envoie un message de mise à jour de clés au moins à chaque membre actif restant du groupe, indiquant comme clé(s) à renouveler et comme clé compromise la clé secrète de chacun dudit ou desdits nœuds de la chaîne de rattachement du membre partant ; S120) chaque membre restant actif, dit membre restant considéré (U2), évalue le nœud, dit premier nœud commun, qui est le nœud de sa chaîne de rattachement qui est le plus éloigné du nœud racine et qui appartient aussi à la chaîne de clés à renouveler ; S120-1) si la clé publique du premier nœud commun a été renouvelée depuis le message de mise à jour de clés, de proche en proche, le membre restant considéré calcule la clé secrète et la clé publique de nœud du nœud considéré, à partir du premier nœud commun et jusqu’au nœud racine ; inversement, S120-2) si la clé publique du premier nœud commun n’a pas été renouvelée depuis le message de mise à jour de clés : S120-22) pour chaque nœud, dit nœud à mettre à jour, situé sur la chaîne de rattachement allant du premier nœud commun au nœud racine, le membre restant considéré calcule la clé secrète et la clé publique de nœud du nœud à mettre à jour, et publie cette dernière dans le registre, ledit nœud à mettre à jour étant alors appelé nœud mis à jour ; tout nœud dont la clé publique est compromise étant considéré comme inexistant lors de tout calcul de clé secrète de nœud ; S120-24) le smart contract envoie un message de mise à jour de nœud au moins à chaque autre membre actif du groupe, c’est-à-dire au moins à chaque membre du groupe, actif, autre que le membre partant et le membre restant considéré, indiquant le nœud mis à jour ; S120-26) de proche en proche, chaque autre membre calcule la clé secrète de nœud du nœud considéré, pour chaque nœud mis à jour faisant également partie de sa chaîne de rattachement, dans le sens allant du nœud terminal de l’arbre auquel il est rattaché vers le nœud racine. Ainsi, chaque membre actif restant du groupe dispose de, ou du moins est en mesure de calculer, une clé secrète de groupe pour tous les nœuds de sa chaîne de rattachement. Avantageusement, la (ou les) nouvelle(s) clé(s) secrète(s) de groupe recalculée(s) dans le cadre de cette procédure de retrait ne sont pas accessibles au membre partant. Pour les membres qui sont inactifs au moment où la procédure de retrait de membre est exécutée, la procédure suivante peut être prévue. Dans une variante du mode de mise en œuvre décrit ci-dessus, le procédé de gestion d’un groupe comprend en outre comprenant en outre un procédé de reconnexion d’un membre du groupe après retrait d’un membre partant, dans lequel : S200) lorsqu’un membre du groupe, dit membre se reconnectant, active sa connexion au groupe après une période d’inactivité, le membre se reconnectant consulte les messages reçus du smart contract ; S210) lorsque le membre se reconnectant a reçu du smart contract un message de retrait de membre,le membre se reconnectant évalue le nœud, dit premier nœud commun, qui est le nœud de sa chaîne de rattachement qui est le plus éloigné du nœud racine et qui appartient aussi à la chaîne de clés à renouveler: S210-1) si la clé publique du nœud évalué a été publiée ou renouvelée depuis le message de mise à jour de clés, de proche en proche, le membre se reconnectant calcule la clé secrète et la clé publique de nœud du nœud considéré, à partir du premier nœud commun et jusqu’au nœud racine ; ou inversement, S210-2) si la clé publique du nœud évalué n’a pas été publiée ou renouvelée depuis le message de retrait de membre : S210-22) pour chaque nœud, dit nœud à mettre à jour, situé sur la chaîne de rattachement allant du premier nœud commun au nœud racine, le membre se reconnectant calcule la clé secrète et la clé publique de nœud du nœud à mettre à jour et publie cette dernière dans le registre, ledit nœud à mettre à jour étant alors appelé nœud mis à jour ; tout nœud dont la clé publique est compromise étant considéré comme inexistant lors de tout calcul de clé secrète de nœud ; S210-24) le smart contract envoie un message de mise à jour de nœud au moins à chaque autre membre du groupe actif, c’est-à-dire chaque membre du groupe, actif, autre que le membre partant et le membre se reconnectant, indiquant le nœud mis à jour; S210-26) de proche en proche, chaque autre membre calcule la clé secrète de nœud du nœud considéré, pour chaque nœud mis à jour faisant également partie de sa chaîne de rattachement (de la chaîne de rattachement du membre se reconnectant), dans le sens allant du nœud terminal de l’arbre auquel il est directement rattaché vers le nœud racine (Ns). Différents modes de calcul peuvent être utilisés pour calculer de nouvelles clés secrètes de nœud en mettant en œuvre le protocole de Diffie-Helman. Dans certains modes de mise en œuvre, au moins une clé secrète de nœud d’un nœud donné est calculée : - en calculant un élément cryptographique dit secret partagé de noeud en fonction de la clé secrète d’un premier fils et de la clé publique d’un deuxième fils du nœud donné ; et - en calculant la clé secrète du nœud donné à partir dudit secret partagé de noeud, par exemple comme étant égale à une partie du secret de nœud. Grâce à la première étape ci-dessus, le procédé selon la présente divulgation permet plus généralement le calcul d’un secret partagé de groupe, à savoir en l’occurrence le secret partagé de nœud du nœud racine. Les procédures décrites dans la présente divulgation permettent aux membres du groupe de maintenir au fil du temps un secret de groupe partagé, qui est recalculé en fonction notamment des départs et ajouts de membres. Dans ce qui suit pour simplifier, le ‘secret partagé de nœud’ est appelé dans certains cas plus simplement ‘secret de nœud’. Dans le premier aspect de l’invention présentée ci-dessus, le groupe est suivi à l’aide d’un arbre binaire. L’arbre binaire permet d’assurer le suivi des membres du groupe de manière relativement simple, et permet notamment de limiter le nombre de recalculs de clés qui sont nécessaires lors du retrait d’un membre. Une solution alternative de l’invention va maintenant être présentée. Selon un deuxième aspect de l’invention, un deuxième procédé de gestion d’un groupe est proposé, dans lequel le groupe est suivi à l’aide d’une liste chaînée. Par rapport au suivi par arbre binaire, ce mode de suivi avantageusement simplifie la mise en œuvre du procédé de gestion de groupe. Inversement, avantageusement la gestion des membres du groupe à l’aide d’un arbre binaire selon le premier aspect de l’invention, par rapport à une gestion des membres selon son deuxième aspect permet de réduire la quantité de gas consommée par l’envoi de transactions vers la blockchain pour la gestion du groupe (et donc le coût de gestion). Le deuxième procédé comme le premier procédé combine le recours à un smart contract et le partage de clés par protocole de Diffie-Hellman pour permettre le partage d’un secret partagé au sein d’un groupe. Le deuxième procédé est un procédé de gestion d’un groupe comprenant une pluralité de membres, chaque membre détenant ou étant en mesure de détenir une clé secrète de groupe, le procédé faisant appel à un crypto-système asymétrique (Enc,Dec) vérifiant la propriété, pour deux paires de clés asymétriques (PK1,SK1) et (PK2,SK2) : Enc(PK1,SK2) = Enc(SK1,PK2), où Enc est la fonction de chiffrement du crypto-système, et à un registre dans lequel un smart contract est déployé ; une liste étant utilisée pour ordonner les membres du groupe ; le procédé comprenant une procédure d’ajout de membre pour intégrer au groupe un candidat souhaitant rejoindre le groupe, à un instant donné où le groupe est constitué par un ensemble de membres, dits membres avant-ajout, chaque membre avant-ajout dispose de ou est en mesure de calculer une clé secrète avant-ajout du groupe avant-ajout ; et une clé publique avant-ajout du groupe avant-ajout est enregistrée dans le registre ; dans laquelle la procédure d’ajout de membre comprend les opérations suivantes : S310) une demande d’admission dans le groupe du candidat est transmise au smart contract , la demande d’admission comprenant un authentifiant et une clé publique personnelle du candidat, le candidat détenant en outre une clé privée personnelle à partir de laquelle sa clé publique personnelle a été calculée au moyen du crypto-système ; S320) le smart contract enregistre dans le registre l’admission dans le groupe d’un nouveau membre du groupe ayant l’authentifiant du candidat et la clé publique du candidat ; S330) à partir de la clé publique avant-ajout du groupe avant-ajout et de sa clé privée personnelle le candidat calcule une nouvelle valeur de clé secrète du groupe puis une nouvelle valeur de clé publique du groupe pour le groupe ; S340) le candidat publie dans le registre la nouvelle valeur de clé publique du groupe (PKgroup n+1) calculée à l’étape S330 ; S350) le smart contract envoie un message de mise à jour de clé de groupe au moins à chaque membre actif avant-ajout du groupe ; et S360) à réception du message de mise à jour de clé de groupe, à partir de la clé secrète avant-ajout du groupe avant-ajout et de la clé publique personnelle du candidat, chaque membre avant-ajout actif calcule la nouvelle valeur de clé secrète du groupe. Par construction, la liste des membres du groupe est ordonnée dans l’ordre chronologique de leurs dates d’admission ou plutôt de leurs dates de dernière admission dans le groupe. Les positions ou index dans le groupe des membres du groupe peuvent être indexées par un index suivi par le smart contract . Dans certains modes de mise en œuvre du procédé de gestion d’un groupe, au plus tard peu après une reconnexion d’un membre du groupe ayant été inactif, ou sur demande de celui-ci lors de la reconnexion de celui-ci, lorsque la procédure d’ajout de membre a été exécutée, le smart contract envoie un message de mise à jour de clé de groupe après ajout d’un membre audit membre ayant été inactif ; et le procédé de gestion de groupe comprend en outre un procédé de reconnexion dudit membre ayant été inactif après ajout d’un membre, dans lequel : S400) lorsque ledit membre ayant été inactif se reconnecte au groupe, il consulte les messages reçus du smart contract ; S410) lorsque le membre se reconnectant a reçu du smart contract un message de mise à jour de clé de groupe après ajout d’un membre, à partir de la clé secrète avant-ajout du groupe avant-ajout et de la clé publique personnelle du candidat, ledit membre ayant été inactif calcule la nouvelle valeur de clé secrète du groupe. Dans certains modes de mise en œuvre, le procédé comprenant en outre une procédure de retrait d’un membre du groupe, dit membre partant, autre que le membre ayant rejoint le groupe en dernier, pour retirer du groupe le membre partant, ladite procédure de retrait de membre comprenant : S500) une demande de retrait du membre partant est envoyée au smart contract ; S510) le smart contract identifie un membre, dit membre d’initialisation, qui est un membre actif du groupe ayant rejoint le groupe avant le membre partant ; S520) le smart contract envoie un message de nouvel ajout au groupe à chaque membre actif du groupe ayant rejoint le groupe après le membre d’initialisation, dit membre à réintégrer, à l’exception du membre partant, invitant celui-ci à se joindre à nouveau au groupe ; S530) à réception du message de nouvel ajout au groupe, pour chaque membre à réintégrer (Up), les étapes S330 à S360 de la procédure d’ajout de membre sont effectuées, en considérant le membre à réintégrer comme étant le candidat. Au cas où le membre partant est le dernier membre qui a rejoint le groupe, dans certains modes de mise en œuvre, le smart contract envoie un message à chaque membre du groupe, l’informant que la clé secrète antérieure du groupe doit être utilisée comme nouvelle clé de groupe. Dans certains modes de mise en œuvre, au moins une nouvelle clé secrète de groupe est calculée : - en calculant un élément cryptographique dit secret partagé de groupe en fonction de la clé secrète d’un membre du groupe et d’une clé publique du groupe, ou encore en fonction en fonction de la clé publique d’un membre du groupe et d’une clé secrète du groupe ; et - en calculant la nouvelle clé secrète du groupe à partir dudit secret partagé de groupe, par exemple comme étant égale à une partie du secret partagé de groupe. Lorsque le secret partagé de groupe est un vecteur, par exemple un vecteur de coordonnées d’un point d’une courbe, notamment une courbe elliptique, la clé secrète de groupe peut inclure ou être une composante de ce vecteur. Dans le premier comme dans le deuxième aspect de l’invention, dans certains modes de mise en œuvre, lorsqu’une nouvelle clé publique de groupe est enregistrée dans le registre, le smart contract assigne un statut ‘Aveugle’ à tous les membres restants autres que le membre, dit membre de mise à jour de groupe, ayant déclenché cet enregistrement ; lorsqu’un membre autre que le membre déclencheur calcule la clé secrète de groupe, il en informe le smart contract ; sur cette base, celui-ci assigne un statut ‘En-ligne’ audit membre autre ; et le procédé comporte au moins une procédure mise en œuvre à l’aide du smart contract, autre qu’une procédure d’ajout ou de retrait de membre, dans laquelle au moins une action du smart contract est réalisée en fonction du statut du membre. Par exemple, le procédé de gestion peut prévoir qu’un membre n’est pas autorisé à consulter ses messages antérieurs via le smart contract s’il est en statut Aveugle. Inversement, lorsqu’ultérieurement ce membre récupérera le statut En-ligne, il sera alors autorisé à effectuer toute action qu’il était autorisé à effectuer pendant sa période d’inactivité, même si pendant une certaine période le membre a été en mode ‘Aveugle’. Dans certains modes de mise en œuvre, une procédure spécifique est prévue pour la récupération de messages échangés pendant la période intermédiaire (en statut ‘Aveugle’). Dans ces modes de mise en œuvre le procédé de gestion comporte en outre une procédure d’obtention rétroactive par un membre en reconnexion suite à une période d’inactivité d’au moins une clé secrète de groupe à obtenir, qui avait été une clé courante du groupe pendant ladite période d’inactivité, ladite procédure d’obtention rétroactive comportant les étapes suivantes : S600) à partir d’informations publiées dans le registre et/ou en interrogeant le smart contract , le membre en reconnexion détermine un authentifiant d’un membre détenteur de clé auprès duquel il peut obtenir ladite au moins une clé secrète à obtenir ; S610) le membre en reconnexion demande au membre détenteur de clé de lui fournir ladite au moins une clé secrète à obtenir ; S620) le membre détenteur de clé vérifie que le membre en reconnexion était membre du groupe à un moment où ladite au moins une clé secrète demandée était la clé secrète courante du groupe, et que le membre en reconnexion fait toujours partie du groupe. S630) si le résultat de la vérification est positif, le membre détenteur de clé considéré ouvre un canal de communication auxiliaire sécurisé avec le membre en reconnexion, par exemple en suivant le protocole indiqué par la demande de brevet français n°1763394 ; et S640) par le canal de communication auxiliaire sécurisé ainsi ouvert, le membre détenteur de clé considéré fournit au membre en reconnexion ladite au moins une clé secrète à obtenir demandée. Dans le premier ou le deuxième aspect de l’invention, avantageusement la procédure de retrait peut être mise en œuvre quel que soit l’ordre dans lequel les membres devant exécuter à nouveau la procédure d’ajout de membre exécutent cette procédure d’ajout de membre. De plus, cette procédure permet le fonctionnement continu du groupe, qui peut avoir lieu même si une partie des membres ayant à exécuter à nouveau la procédure d’ajout de membre ne l’ont pas encore exécutée (leur terminal étant éteint, par exemple). Dans le premier ou le deuxième aspect de l’invention, dans certains modes de mise en œuvre, le procédé de gestion de groupe comprend en outre une étape au cours de laquelle au moins un membre actif du groupe calcule une clé symétrique de groupe à partir d’une clé secrète de groupe. Cette étape permet aux membres du groupe de disposer d’une clé symétrique partagée par tous les membres du groupe. Une telle clé permet la mise en œuvre de certains protocoles, notamment des protocoles de communication, et cela de manière plus légère qu’une clé asymétrique comme la clé secrète de groupe. Ces protocoles peuvent être notamment des protocoles de chiffrement de messages tels qu’AES. La clé symétrique peut être calculée de différentes manières. Ainsi dans certains modes de mise en œuvre, pour calculer ladite clé symétrique de groupe, ledit au moins un membre actif du groupe : - calcule un élément cryptographique dit secret partagé de groupe en fonction de sa clé secrète et d’une clé publique du groupe, ou encore en fonction de la clé publique d’un membre du groupe et d’une clé secrète du groupe ; et - calcule la clé symétrique du groupe à partir dudit secret partagé de groupe, par exemple comme étant égale à une partie du secret de groupe. Par extension, selon un troisième aspect, l’invention concerne également un procédé de communication chiffrée au sein d’un groupe, comprenant les étapes suivantes : A. on constitue le groupe en mettant en œuvre l’un quelconque des procédés de gestion de groupe présentés précédemment ; B. au moins un membre du groupe calcule une clé symétrique de groupe à partir de la clé secrète de groupe ; et C. ce membre reçoit un message et déchiffre celui-ci à l’aide de la clé symétrique de groupe, ou chiffre un message à l’aide de la clé symétrique de groupe et envoie celui-ci. Ainsi, du fait que chaque membre du groupe est en mesure de calculer la clé secrète de groupe et de construire la clé symétrique qui s’en déduit, chaque membre du groupe est en mesure de lire les messages échangés au sein du groupe, en déchiffrant ceux-ci à l’aide de la clé symétrique de groupe. Dans certains modes de mise en œuvre, à l’étape S50, le membre construit une clé secrète de groupe (la clé secrète du nœud racine) ; puis il calcule une paire de clés asymétrique de groupe à partir d’une 1 ère partie du secret de groupe, et une clef symétrique de groupe à partir d’une 2 ème partie du secret de groupe. Le chiffrement ou le déchiffrement d’information est fait à l’aide de la clé symétrique de groupe. Lorsque le crypto-système est fondé sur une courbe elliptique, l’une des composantes (sur x ou respectivement sur y) peut être utilisée pour construire la clé symétrique, et l’autre composante est utilisée pour calculer la paire de clés asymétrique. BRÈVE DESCRIPTION DES FIGURES D’autres avantages, buts et caractéristiques particulières de la présente invention ressortiront de la description non limitative qui suit d’au moins un mode de réalisation particulier des dispositifs et procédés objets de la présente invention, en regard des dessins annexés, dans lesquels : La FIG. 1 est une vue schématique d’un groupe de personnes mettant en œuvre un procédé de partage de secret de groupe selon la présente divulgation ; la FIG. 2 est une représentation schématique d’un arbre utilisé pour ordonner les membres d’un groupe, lors de la mise en œuvre d’un procédé selon le premier aspect de la présente divulgation ; la FIG. 3 est une représentation schématique d’un arbre utilisé pour ordonner les membres du groupe, lors de l’exécution d’une procédure d’ajout de membre durant la mise en œuvre d’un procédé selon le premier aspect de la présente divulgation ; la FIG. 4 est une représentation schématique d’un arbre utilisé pour ordonner les membres du groupe, lors de l’exécution d’une procédure de retrait de membre durant la mise en œuvre d’un procédé selon le premier aspect de la présente divulgation ; la FIG. 5 est une représentation schématique d’un arbre utilisé pour ordonner les membres d’un groupe, lors de l’exécution d’une procédure d’ajout de membre durant la mise en œuvre d’un procédé selon le deuxième aspect de la présente divulgation ; la FIG. 6 est une représentation schématique d’un arbre utilisé pour ordonner les membres d’un groupe, lors de l’exécution d’une procédure de retrait de membre durant la mise en œuvre d’un procédé selon le deuxième aspect de la présente divulgation ; la FIG. 7 est un logigramme présentant les étapes d’une procédure d’ajout de membre, dans un procédé de gestion de groupe selon le premier aspect de la présente divulgation ; la FIG. 8 est un logigramme présentant les étapes d’une procédure de retrait de membre, dans un procédé de gestion de groupe selon le premier aspect la présente divulgation ; la FIG. 9 est un logigramme présentant les étapes d’une procédure de reconnexion d’un membre qui se reconnecte après le retrait d’un membre du groupe, dans un procédé de gestion de groupe selon le premier aspect la présente divulgation ; la FIG. 10 est un logigramme présentant les étapes d’une procédure d’ajout de membre, dans un procédé de gestion de groupe selon le deuxième aspect la présente divulgation ; la FIG. 11 est un logigramme présentant les étapes d’une procédure de retrait de membre, dans un procédé de gestion de groupe selon le deuxième aspect la présente divulgation ; la FIG. 12 est un logigramme présentant les étapes d’une procédure d’obtention rétroactive de clé secrète, dans un procédé de gestion de groupe selon la présente divulgation ; et la FIG. 13 est un logigramme présentant les étapes d’un procédé de communication chiffrée au sein d’un groupe, faisant appel à un procédé de gestion de groupe selon la présente divulgation. DESCRIPTION DÉTAILLÉE DE L’INVENTION Des exemples non limitatifs de procédés de gestion de groupe et de procédés de communication correspondants selon la présente divulgation vont maintenant être présentés. CARACTERISTIQUES GENERALES DU PROCEDE Les procédés de gestion de groupe selon la présente divulgation concernent notamment des groupes constitués pour pouvoir échanger des messages, comme celui illustré par la FIG. 1 . Cette figure montre un ensemble de personnes {U1, U2, U3,… Un}, chaque personne étant notée Ui (i=1…n). Ces personnes constituent le groupe G à l’instant considéré. Une personne Un+1, non-membre du groupe G, cherche à rejoindre celui-ci. Chacune de ces personnes, qui peut être un être humain ou une machine, dispose de (ou comporte) un terminal Ti (i=1…n). Chaque terminal est un appareil électronique capable d’envoyer et de recevoir des messages aux autres personnes via un réseau R, internet par exemple, représenté sous forme d’un nuage sur la FIG. 1 . Chaque terminal peut être par exemple un téléphone portable, un ordinateur, etc. La personne Un+1 dispose également d’un terminal de ce type, Tn+1. Chaque terminal comporte au moins un processeur capable d’exécuter des applications informatiques et une mémoire. La mémoire contient au moins une application de communication, qui est utilisée pour l’échange de messages avec les terminaux des autres membres du groupe. Bien que dans certains modes de mise en œuvre, les terminaux puissent être configurés pour être en permanence en mesure d’échanger des messages, le plus souvent chaque terminal peut être soit dans un mode ‘actif’, ou ‘allumé’, dans lequel il est en mesure d’échanger des messages avec le réseau, ou dans un mode ‘inactif’, ou ‘éteint’, dans lequel il ne peut pas échanger des messages. Le terme ‘message’ inclut tout échange d’informations, notamment des informations de mise à jour du terminal. Le groupe G est constitué pour pouvoir échanger des messages de manière confidentielle. Dans ce but, un élément cryptographique appelé secret partagé de groupe NPK Group p est partagé entre membres du groupe. Ce secret partagé de groupe est recalculé lors d’opérations de ‘mise à jour du groupe’ lorsque cela est nécessaire conformément aux procédures des procédés de gestion de groupe selon la présente divulgation ; à chaque mise à jour du groupe, son indice p est incrémenté. Le secret partagé de groupe varie donc au cours du temps, adoptant d’abord une valeur initiale NPK Group 1 , puis une valeur NPK Group 2 , jusqu’à une valeur NPK Group p lors à l’issue du p-ième calcul du secret partagé de groupe. Un crypto-système asymétrique est choisi pour le groupe pour permettre le partage du secret entre les membres du groupe en mettant en œuvre les procédés selon la présente divulgation. Ce crypto-système peut être un crypto-système de courbe elliptique, utilisant par exemple les paramètres (p, a, b, G, n et h). Ces paramètres sont publics. De manière alternative, le crypto-système du groupe peut être également un crypto-système RSA ; un crypto-système comprenant des codes correcteurs ; un crypto-système post-quantique, notamment à base de lattices ; etc. Un registre, en l’occurrence une blockchain B, est utilisé pour assurer l’enregistrement et la communication de certaines informations entre les terminaux Ti, conformément à la présente divulgation. Ce registre peut être une blockchain publique (tout le monde peut y accéder) ou privée (il faut être authentifié et autorisé pour y accéder). Le registre est mis en œuvre à l’aide de serveurs, chaque serveur étant un ordinateur. Les procédés de gestion de groupe selon la présente divulgation vont maintenant être présentés. PREMIER ASPECT A titre d’exemple, un mode de mise en œuvre de procédés suivant le premier aspect de la présente divulgation va maintenant être présenté en relation avec les Figs. 2 à 4. Dans ce mode de mise en œuvre, un arbre binaire A est utilisé pour la gestion du groupe. Sur la FIG. 2 est représenté à titre d’exemple un arbre A qui représente de manière schématique un groupe G. Comme on le voit sur cette figure, à l’instant considéré le groupe G comporte 3 membres : U1, Alice ; U2, Bob ; et U3, Charles. L’arbre A varie au cours du temps en fonction des admissions et des départs de membres, chaque admission ou départ entraînant au moins une mise à jour du groupe. Chaque mise à jour du groupe comporte une mise à jour de l’arbre et des variables cryptographiques associées. Dans l’arbre A, chaque nœud est noté Nj,k, où j est le niveau du nœud dans l’arbre, et k l’indice du nœud au niveau j considéré de l’arbre. Le nœud unique existant au niveau supérieur s de l’arbre, noté Ns,1 ou plus simplement Ns, constitue le nœud racine de l’arbre. L’arbre A étant un arbre binaire, chaque nœud comporte zéro, un ou deux fils. Les nœuds terminaux sont appelés ‘feuilles’ ; à chaque feuille de l’arbre est associé un membre du groupe. Dans l’arbre A, un secret partagé de nœud NPKj,k,p et une paire de clés asymétrique de nœud comportant une clé secrète SKj,k,p et une clé publique PKj,k,p sont associés à chaque nœud Nj,k ; p étant l’indice courant (c’est-à-dire, à l’instant considéré) du secret de groupe. La clé publique PKj,k,p peut être calculée à partir de la clé secrète SKj,k,n à l’aide du crypto-système choisi pour le groupe, de manière connue en soi. La clé secrète SKs,1,p associée au nœud racine Ns est la clé secrète de groupe SK group p . Dans l’exemple de mise en œuvre présenté ici, le crypto-système choisi pour le groupe est un crypto-système de courbe elliptique, utilisant les paramètres (p, a, b, G, n et h). La clé secrète de nœud SKj,k,p est dérivée du secret de nœud NPKj,k,p par une fonction de dérivation. Toute fonction de dérivation appropriée peut être choisie ; et notamment, toute fonction de dérivation qui génère la clé secrète de nœud SKj,k,p en fonction d’au moins une partie de l’information contenue dans le secret de nœud NPKj,k,p. La fonction de dérivation peut être simplement la fonction identité (la clé secrète de nœud est alors égale au secret de nœud). La fonction de dérivation doit naturellement être détenue par toute personne qui a à calculer une nouvelle valeur de la clé secrète de nœud. Dans le mode de réalisation présente ici, pour un nœud Nj,k (‘nœud père’) ayant deux fils, la nouvelle valeur du secret de nœud et la nouvelle valeur SKj,k,p+1 de la clé secrète du nœud Nj,k sont calculées de la manière suivante lors d’une mise à jour du groupe d’indice p+1 : On fait l’hypothèse qu’au moment de cette mise à jour, les deux fils du nœud Nj,k sont les nœuds Nj-1,k1-1 et Nj-1,k1. La nouvelle valeur pour le secret de nœud NPKj,k,p+1 est calculée par une fonction de chiffrement combinant la clé publique de l’un des fils et la clé secrète de l’autre fils. Cette fonction est toute fonction de chiffrement Enc d’un crypto-système asymétrique (Enc,Dec) qui vérifie la propriété, pour deux paires de clés asymétriques (PK1,SK1) et (PK2,SK2) : Enc(PK1,SK2) = Enc(SK1,PK2), Dans le cas présent, le secret de nœud peut donc être calculé indifféremment par l’une ou l’autre des formules suivantes : NPKj,k,p+1 = Enc (SKj-1,k1,p ; PKj-1,k1,p) = SKj-1,k1,p ● PKj-1,k1,p = Enc (PKj-1,k1,p ; SKj-1,k1,p) = PKj-1,k1,p ● SKj-1,k1,p Cette propriété permet qu’une personne dont la chaîne de rattachement contient un des nœuds fils Nj-1,k1-1 ou Nj-1,k1, et qui pour cette raison détient la clé secrète de ce nœud fils calcule une nouvelle valeur (d’indice p+1) du secret partagé de nœud pour le nœud père Nj,k. Conventionnellement, la clé secrète SKj,k,p+1 pour le nœud Nj,k, est déduite du secret partagé de nœud comme étant égale à la composante sur x de NPKj-1,k1,p : SKj,k,p+1 = NPKj,k,p(x). La clé publique correspondante du nœud N2,1 est obtenue à partir de la clé secrète SK2,1,2 par la formule : PK2,1,2 = SK2,1,2 ● G. Dans cette équation : - l’opérateur ‘●’ indique l’opération de multiplication dans l’espace des courbes elliptiques, qui peut être mise en œuvre par une addition répétée le nombre de fois indiquées par le scalaire. Par conséquent la clé publique PK2,1,2 indiquée par l’opération de multiplication ci-dessus est égale à (((G + G) + G) + … + G), l’addition est répétée SK2,1,2 fois, l’opération d’addition ‘+’ étant définie dans l’espace des courbes elliptiques ; et - G est le point générateur sur la courbe elliptique considérée, qui permet de générer tous les points de la courbe elliptique dans l’espace discrétisé. La composante en y de NPK2,1,2 est alors choisie comme clé symétrique EncK2 pour les échanges de messages dans le groupe G2 : EncK2 = NPK2,1,2(y). La procédure ci-dessus permet de calculer les éléments cryptographiques d’un nœud père Nj,k, à partir de la clé secrète de l’un des nœuds fils Nj-1,k1-1 ou Nj-1,k1, la clé publique de l’autre nœud fils étant disponible sur le registre, pour un nœud quelconque Nj,k ayant deux fils. D’autres fonctions peuvent être choisies pour dériver une clé secrète du nœud père à partir de la clé secrète de l’un des fils du noeud père et de la clé publique de l’autre nœud fils. De manière générale, toute fonction utilisable (ou utilisée) pour la mise en œuvre du protole de Diffie-Helman peut être utilisée pour réaliser cette fonction. Si inversement un nœud père Nj,k a un seul fils Nj-1,k1, la clé secrète SKj,j,p+1 du nœud Nj,k est calculée lors d’une mise à jour en fonction de la seule clé secrète de son fils SKj-1,k1,p+1, par exemple en étant égale à celle-ci : SKj,k,p+1 = SKj-1,k1,p+1. Avantageusement cette procédure peut être répétée par un membre du groupe de proche en proche pour calculer successivement les éléments cryptographiques, et notamment les clés secrètes, de tous les nœuds de sa chaîne de rattachement, dans le sens allant du nœud terminal associé au membre jusqu’au nœud racine. Dans les paires de clés asymétriques associées aux différents nœuds, les clés publiques sont enregistrées dans le registre et donc sont librement accessibles (du moins pour les membres ayant accès au registre). Inversement, comme cela va être détaillé ci-dessous, pour chaque nœud, seul(s) le(s) membre(s) dont la chaîne de rattachement contient le nœud disposent de ou ont les moyens de reconstituer la clé secrète de nœud du nœud. Ajout de membres Les modalités d’admission de nouveaux membres dans le groupe G suivant le procédé de gestion va maintenant être présentée dans le cadre des premières phases de la constitution du groupe G. De manière générale, l’admission d’un nouveau membre dans le groupe entraîne l’exécution d’une procédure d’ajout de membre, et optionnellement l’exécution d’une ou plusieurs procédures de reconnexion. La procédure d’ajout de membre entraîne une mise à jour du groupe et donc le recalcul du secret de groupe. La procédure de reconnexion permet donc le cas échéant à des membres du groupe inactifs au moment où la procédure d’ajout de membre a été exécutée de pouvoir obtenir le nouveau secret de groupe et donc de joindre à nouveau le groupe. Au cours d’une phase d’initialisation (p=1), le 1 er membre U1 du groupe, Alice, crée le groupe G en déployant un smart contract SC dans le registre B. Alice devient donc l’administrateur du groupe. A l’aide du crypto-système, Alice génère son couple de clés asymétrique personnel, noté SKAlice/PKAlice. Alice enregistre sa clé publique PKAlice dans le registre et est enregistrée par le smart contract comme ayant le statut ‘En-ligne’. Cet enregistrement peut être réalisé de différentes manières. Si le registre est une blockchain de type Bitcoin, une clé publique éphémère peut être enregistrée dans la blockchain en utilisant le script OP_s du protocole Bitcoin. Une telle utilisation de ce script peut être mise en œuvre en s’inspirant de la demande de brevet français n°1763393. Le contenu de la Blockchain étant accessible aux membres du groupe, chacun de ceux-ci accède aux clés publiques ainsi déposées à partir de la connaissance de son adresse de compte qui prouve l’appartenance de la clé. Si le registre est une blockchain de type Ethereum, la clé publique éphémère peut être enregistrée dans la blockchain en utilisant un smart contract . Un tel mode de mise en œuvre peut être réalisé en s’inspirant de la demande de brevet français n°1763394. La clé secrète d’Alice constitue le secret de groupe d’indice p=1 : SK group 1 = SKAlice. Dans une deuxième phase, Bob rejoint le groupe en tant que deuxième membre U2, ce qui entraîne une mise à jour du groupe (p=2). A l’aide du crypto-système Bob génère son couple de clés asymétrique personnel, noté SKBob/PKBob. Les clés publiques PKAlice et PKBob sont respectivement dérivées des clés secrètes SKAlice et SKBob, par les formules suivantes : PK Alice = SK Alice ● G et PK Bob = SK Bob ● G où G est le point générateur du crypto-système de courbe elliptique représenté par les paramètres (p, a, b, G, n et h). Bob détient par ailleurs un authentifiant accuU2 qui lui permet de s’authentifier auprès du smart contract SC. La procédure d’ajout de membre est exécutée pour permettre l’admission de Bob : A l’étape S10, Bob transmet au smart contract SC sa demande d’admission dans le groupe en joignant son authentifiant accuU2 et sa clé publique PK Bob à sa demande. A l’étape S20, le smart contract enregistre dans le registre l’admission dans le groupe G d’un nouveau membre ayant l’authentifiant accuU2 et la clé publique PKBob . Au vu des informations contenues dans le registre, Bob détermine alors (étape S30) que sa chaîne de rattachement dans l’arbre A contient uniquement le nœud racine N2,1. A l’étape S40, Bob calcule la clé secrète de nœud pour ce nœud à partir de sa clé privée personnelle SKBob et de la clé publique d’Alice PKAlice : Bob calcule le secret de nœud, NPK2,1,2 : NPK2,1,2 = SK Bob ● PK Alice Il en déduit alors la clé secrète SK2,1,2 pour le nœud N2,1 , qui est la composante sur x de NPK2,1,2 : SK2,1,2 = SK group 2 = NPK2,1,2(x). Il calcule alors la clé publique PK2,1,2 à partir de la clé secrète SK2,1,2 : PK2,1,2 = SK2,1,2 ● G. Il en déduit alors la clé symétrique courante EncK2 pour les échanges de messages dans le groupe G, qui est la composante sur y de NPK2,1,2 : EncK2 = NPK2,1,2(y). A l’étape S50, Bob publie dans le registre la clé publique de groupe PK2,1,2 qu’il vient de calculer. Bob a le statut ‘En-ligne’, alors qu’Alice est placée en statut ‘Aveugle’. A l’étape S60 le smart contract envoie à Alice un message de mise à jour de clé de groupe. A l’étape S70, à réception de ce message, Alice détermine la ou les clés secrètes de nœud qu’elle doit recalculer : ce sont les clés secrètes des nœuds communs à sa chaîne de rattachement et à la suite du rattachement de Bob, c’est-à-dire le nœud N2,1. Alice calcule donc alors à son tour la clé secrète du nœud N2,1 en suivant la procédure présentée précédemment. Grâce à la propriété de commutativité des crypto-systèmes à courbe elliptique, elle obtient la même valeur pour la clé secrète SK2,1,2 que celle calculée par Bob. Elle en informe le smart contract et est placée à nouveau en statut ‘En-ligne’. Elle calcule également la clé symétrique de communication de groupe, EncK2, par la formule : EncK2 = NPK2,1,2(y). Alice et Bob échangent alors des messages en utilisant la clé symétrique de communication EncK2 comme clé de chiffrement des messages qu’ils échangent. Ces messages peuvent être chiffrés par tout algorithme de chiffrement symétrique connu comme par exemple AES. Dans une troisième phase, Charles rejoint le groupe en tant que troisième membre U3. Il est ajouté au niveau 1 au nœud N1,3. Un nœud N2,2 et un nouveau nœud racine N3,1 (ou N3) sont créés afin que Charles puisse avoir une chaîne de rattachement s’étendant jusqu’au nœud racine. Le nœud N2,1 est le premier fils du nœud racine N3, et le nœud N2,2 le deuxième fils de celui-ci. La chaîne de rattachement de Charles comprend les nœuds N2,2 et N3. La procédure d’ajout de membre présentée précédemment est alors exécutée pour permettre l’admission de Charles dans le groupe G. La procédure d’ajout de membre dans le groupe G va maintenant être présentée de manière plus générale dans l’exemple illustré par la FIG. 3 . Cette procédure va être illustrée à un instant où le groupe est le groupe G présenté précédemment, à un indice de mise à jour p. A l’instant considéré, le groupe G comporte six membres Ui, i=1…6 appelés Alice, Bob, Charles, Dave, Esther et Fabien, intégrés à l’arbre A. Un candidat U7, Greg, veut rejoindre le groupe. Pour lui permettre de devenir membre du groupe, la procédure d’ajout de membre est exécutée pour Greg. Les membres sont ajoutés à l’arbre A en respectant les règles de constitution de l’arbre A. Tout ensemble de règles approprié peut être choisi pour la constitution de l’arbre. Cet ensemble de règles est choisi de manière à permettre à chaque membre du groupe à tout moment, à partir du registre, de connaître la structure de l’arbre. Cet ensemble de règles peut être public : chaque membre du groupe, à tout moment, à partir du registre, peut connaître la structure de l’arbre. De manière alternative, il peut être privé. Il est alors connu au moins du smart contract : c’est alors le smart contract qui informe les membres de leur chaîne de rattachement et le cas échéant des autres informations qui leur sont nécessaires relatives à la structure de l’arbre. L’admission d’un nouveau membre, comme cela va être détaillé, entraîne dans certains cas l’ajout d’un niveau supplémentaire dans l’arbre, et/ou l’ajout d’un ou plusieurs nouveau(x) nœud(s), et dans tous les cas l’ajout d’une nouvelle feuille correspondant au nouveau membre. A l’instant considéré, l’arbre A6 comporte les 6 membres U1-U6, et 14 nœuds correspondants référencés N1,1 ; N1,2 ; N1,13 ; N1,14 ; N2,1 ; N2,2 ; N2,7 ; N3,1 ; N3,4 ; N4,1 ; N4,2 ; N5. Dans le cas présent, les règles de constitution du groupe incluent une règle de non-remplacement dans l’arbre des membres partants et par conséquent, l’arbre n’est pas complet. Ainsi certains nœuds, comme les nœuds N3,2 et N4,2 ont un seul fils ou même sont manquants, suite au fait que les membres du groupe qui étaient rattachés à ces nœud ont quitté le groupe. Les règles de constitution de l’arbre imposent de plus que chacun des membres (U1-U6) du groupe soit nécessairement rattaché à un nœud de niveau 1 (Cependant dans d’autres modes de réalisation des membres peuvent être rattachés à des nœuds de niveau supérieur. Par exemple, le nouveau membre pourrait être rattaché au nœud N4,1). Du fait de cette règle, le nouveau membre U7 est ajouté dans l’arbre au niveau 1, dans la position d’indice immédiatement supérieur à la position du dernier membre admis, U6, encore présent dans le groupe. Comme l’arbre A lors de la mise à jour courant (d’indice p) ne contenait pas de nœud N2,8, le nœud N2,8 est créé. Le membre U7 est donc ajouté à un nœud N1,15. Grâce à la création du nœud N2,8, il possède une chaîne de rattachement complète constituée des nœuds N2,8 ; N3,4 ; N4,2 et N5. Chacun des membres U1-U6 dispose d’une paire de clés asymétrique comprenant une clé secrète ESKi et une clé publique EPKi dérivée de la clé secrète ESKi à l’aide du crypto-système asymétrique, soit respectivement des paires de clés SK Alice /PK Alice , SK Bob /PK Bob , SK Charles /PK Charles , SK Dave /PK Dave , SK Esther /PK Esther , SK Fabien /PK Fabien . Greg dispose également d’une telle paire de clés SK Greg /PK Greg . A l’instant où Greg initie la procédure d’ajout de membre pour être admis dans le groupe G (comme à tout instant), chacun des membres actifs du groupe dispose de la clé secrète de nœud SKj,k,p de chacun des nœuds Nj,k de sa chaîne de rattachement. De plus, pour chaque nœud Nj,k de l’arbre A, une clé publique de nœud PKj,k,p est enregistrée dans le registre. L’ajout du nouveau membre U7, Greg, au groupe, entraîne la réalisation des opérations suivantes : A l’étape S10 Greg transmet au smart contract sa demande d’admission dans le groupe, en joignant à celle-ci son authentifiant acc U7 et sa clé publique personnelle PK Greg . Dans ce mode de réalisation il transmet cette demande directement au smart contract . Dans d’autres modes de réalisation il pourrait transmettre sa demande à un administrateur du groupe et c’est celui-ci, après avoir effectué des vérifications appropriées, qui transmettrait la demande d’admission au smart contract . A l’étape S20 le smart contract enregistre dans le registre l’admission dans le groupe G du nouveau membre U7 ayant pour authentifiant acc Greg et pour clé publique PK Greg . A l’étape S30 Greg détermine la liste des nœuds de sa chaîne de rattachement dans l’arbre, à savoir la liste N2,8 ; N3,4 ; N4,2 ; N5. A l’étape S40, de proche en proche, Greg calcule la clé secrète de nœud puis la clé publique de nœud pour chaque nœud de sa chaîne de rattachement, depuis le nœud de l’arbre auquel il est directement rattaché jusqu’au nœud racine N5. Comme cela a été vu précédemment, dans le mode de réalisation présenté ici ce calcul est indirect : pour calculer la clé secrète d’indice p+1 d’un nœud Nj,k ayant deux fils, Greg calcule d’abord le secret de nœud NPKj,k,p+1, puis dérive de celui-ci la clé secrète de nœud SKj,k,p+1, puis la clé publique de nœud PKj,k,p+1. Si inversement un nœud de la chaîne de rattachement n’a qu’un fils (comme le nœud N2,8), dans ce cas le secret de nœud, les clés publique et secrète de nœud attribués à ce nœud sont égaux aux éléments cryptographiques correspondants du fils. On a ainsi notamment SK2,8,p+1 = SK Greg . A l’étape S50, Greg publie dans le registre les clés publiques des nœuds N2,8 ; N3,4 ; N4,2 et N5 calculées à l’étape S50. Toutes les clés publiques de l’arbre A sont donc ainsi mises à jour. Cependant, pour permettre à l’ensemble des membres du groupe d’échanger des messages, leurs clés doivent alors être mises à jour. Dans ce but, à l’étape S60 le smart contract envoie un message de mise à jour de clé de groupe à chaque membre avant-ajout du groupe. A l’étape S70, à réception du message de mise à jour de clé de groupe, de proche en proche, chaque membre avant-ajout actif du groupe, c’est-à-dire chacun des membres actifs parmi les membres U1-U6 calcule la clé secrète de nœud pour chaque nœud de sa chaîne de rattachement qui fait également partie de la chaîne de rattachement de Greg, dans le sens allant du nœud de l’arbre auquel il est directement rattaché vers le nœud racine N5 (sens montant sur la FIG. 3 ). Il effectue pour cela des calculs similaires à ceux exécutés par Greg à l’étape S40. Chaque membre actif du groupe calcule alors la clé symétrique de communication de groupe EncKp+1, à l’étape S80. Par suite, chaque membre actif du groupe est dès lors en mesure d’envoyer et/ou de recevoir des messages sous chiffrement symétrique à l’aide de cette clé avec les autres membres actifs du groupe. Procédure de reconnexion des membres inactifs Si un membre du groupe est inactif au moment où la procédure d’ajout de membre est exécutée, il ne peut réaliser l’étape S70 à ce moment-là. Par conséquent, au moment où il se reconnecte (typiquement en allumant son terminal Ti), du fait que les clés secrète et privée de groupe ont été recalculées, il ne dispose pas de ces clés et ne peut échanger de messages avec les autres membres du groupe. Pour remédier à cette situation, il exécute la procédure de reconnexion suivante. Lorsque le membre du groupe (et donc, lorsque chaque membre du groupe) se reconnecte, il consulte ses messages. S’il a reçu un message d’ajout de membre, il exécute alors les étapes S70 et S80, ce qui lui permet d’obtenir les clés secrètes à jour pour l’ensemble des nœuds de sa chaîne de rattachement, ainsi que la clé symétrique de groupe EncKp+1, qui lui permet alors d’échanger des messages avec les autres membres du groupe. Retrait d’un membre Lorsqu’un membre du groupe (dit ‘membre partant’) quitte le groupe G (à un indice de mise à jour p), une procédure de retrait de membre est exécutée pour assurer qu’après le départ du membre, celui-ci ne dispose plus de la clé symétrique secrète EncKp utilisée pour le chiffrement des messages dans le groupe et par suite, ne peut plus avoir accès aux messages échangés par le groupe. Plus généralement la procédure de retrait vise à renouveler la clé secrète de groupe SK group p , pour que le membre partant ne puisse plus avoir accès à des informations confidentielles relatives au groupe. Pour renouveler cette clé secrète, il va être nécessaire de recalculer la clé de secrète de nœud pour chacun des nœuds de la chaîne de rattachement du membre partant. Pour ce faire, la procédure de retrait comprend la réalisation des opérations suivantes lorsque le retrait du membre partant est décidé : On prend comme exemple le cas où Charles (membre U3 du groupe), quitte le groupe G dont l’arbre A est représenté sur la FIG. 4 . La chaîne de rattachement CR3 de Charles comporte les nœuds N2,2 ; N3,1 ; N4,1 ; N5. Les étapes de la procédure de retrait de membre sont représentées sur la FIG. 8 . La FIG. 4 représente l’arbre A au moment de l’exécution de la procédure de retrait suite au départ de Charles. A l’étape S100, Charles, directement ou éventuellement par l’intermédiaire d’Alice l’administratrice du groupe, envoie au smart contract une demande de retrait. A l’étape S110, le smart contract envoie un message de mise à jour de clés à chaque membre restant du groupe, indiquant comme clé(s) à renouveler et comme clé compromise la clé secrète de chacun des nœuds de la chaîne de rattachement du membre partant Charles (U3). Dès la réception de ce message, chaque membre du groupe considère la clé publique de chacun des nœuds de la chaîne de rattachement CR3 de Charles comme compromise. A l’étape S120, chaque membre restant actif évalue le nœud, dit premier nœud commun, qui est le nœud de sa chaîne de rattachement qui est le plus éloigné du nœud racine et qui appartient aussi à la chaîne de clés à renouveler. On suppose que le premier membre restant considéré qui effectue cette procédure est Bob (U2). La chaîne de rattachement CR2 de Bob comporte les nœuds N2,1 ; N3,1 ; N4,1 ; N5. Le premier nœud commun est donc le nœud N3,1. A cet instant, la clé publique du premier nœud commun, N3,1, n’a pas été recalculée depuis le message de mise à jour de clés : elle est donc une clé compromise. Bob en déduit qu’il doit exécuter l’étape S120-2, composée des étapes S120-22, S120-24 et S120-26 : Il doit recalculer les clés publiques du nœud N3,1 ainsi que de tous les nœuds supérieurs dans sa chaîne de rattachement CR2 (c’est-à-dire les nœuds N4,1 et N5). Ainsi à l’étape S120-2, pour chacun des nœuds (dits ‘nœuds mis à jour) N3,1 ; N4,1 et N5, Bob (le membre restant considéré) calcule le secret partagé de nœud, et en déduit la clé publique et la clé secrète du nœud, et publie la clé publique dans le registre. Lors du calcul pour le nœud N3,1, comme la clé N2,2 est compromise, le nœud N2,2 est considéré comme inexistant lors du calcul du secret partagé de nœud NPK3,1,p+1. En d’autres termes, le nœud N3,1 est considéré pour ce calcul comme un nœud ayant un seul fils (le nœud N2,1). La clé secrète du nœud N3,1 est donc calculée en fonction seulement de la clé secrète que détient Bob du nœud N2,1. Aucune information provenant de la clé publique compromise du nœud N2,2 n’est donc utilisée. Les clés secrètes des nœuds N4,1 et N5 sont ensuite calculées. On a donc : SK4,1,p+1 = SK3,1,p+1 = SK2,1,p+1 La clé de nœud NPK5 est calculée en fonction de SK4,1 et PK4,2 (la branche droite de l’arbre ne comportant pas de clé compromise). Les clés publiques PK3,1,p+1, PK4,1,p+1 et P5,p+1 sont publiées dans le registre. Comme des clés publiques PK3,1 ; PK4,1 et PK5 ont été recalculées, à l’étape S120-24 le smart contract envoie alors un message de mise à jour de clés à chaque autre membre du groupe (autre que le membre partant (Charles)) et autre que le membre restant considéré (Bob)), indiquant comme clés à renouveler la clé au moins de chacun des nœuds mis à jour faisant aussi partie de la chaîne de rattachement dudit autre membre considéré. Ce message est donc envoyé à Alice, Dave, Fabien et Greg (Esther étant absente), qui sont donc les ‘autres membres’. Par exemple, pour Fabien et Greg, le message peut simplement indiquer que la clé publique PK5 a été recalculée. A réception du message émis à l’étape S120-26, chaque autre membre actif calcule la clé secrète de nœud pour chaque nœud de sa chaîne de rattachement qui est également un nœud mis à jour, dans le sens allant du nœud de l’arbre auquel il est directement rattaché vers le nœud racine. On suppose que Dave est le deuxième membre du groupe qui réagit à la réception du message de mise à jour de clés envoyé à l’étape S110. Dave réagit aux messages émis aux étapes S110 et S120-26 en effectuant les étapes suivantes : Pour Dave, le premier nœud commun (c’est-à-dire le nœud le plus bas de sa chaîne de rattachement dont une clé est indiquée dans le message émis à l’étape S110 comme clé à renouveler et comme clé compromise) est le nœud N2,2. A l’étape S120, Dave (en tant que membre restant considéré), évalue ce premier nœud commun N2,2. La clé publique du nœud N2,2 n’a pas été renouvelée depuis le message émis à l’étape S110. Dave doit donc exécuter l’étape S120-2. Les nœuds dits ‘nœuds mis à jour’ sont les nœuds N2,2 ; N3,1 ; N4,1 ; N5. Le nœud N1,3 ayant été supprimé (du fait du départ de Charles), les clés publique et secrète du nœud NPK2,2,p+1 sont égales respectivement à la clé publique et la clé secrète de Dave PK Dave et SK Dave . A l’étape S120-22, Dave calcule donc de proche en proche, les secrets partagés de nœud et les clés secrète et publique de nœud successivement pour les nœuds N3,1 ; N4,1 ; N5. A l’étape S120-24, le smart contract envoie un message de mise à jour de clés au moins à chaque autre membre actif du groupe, indiquant comme clés à renouveler la clé secrète de chacun desdits nœuds mis à jour, donc les clés des nœuds N2,2 ; N3,1 ; N4,1 ; N5. A l’étape S120-26, chacun des autres membres s’il y a lieu met à jour ses clés le long de sa chaîne de rattachement. Ainsi en particulier, Bob doit à nouveau recalculer les clés secrètes et publiques pour les nœuds de sa chaîne de rattachement dont les clés secrètes et publiques ont été recalculées : il recalcule donc les clés pour les nœuds N3,1 ; N4,1 et N5. Les autres membres actifs du groupe, Alice, Fabien et Greg recalculent alors également les clés secrètes et publiques pour les nœuds de leurs chaînes de rattachement respectives dont les clés secrètes et publiques ont été recalculées. Dans le cas de Fabien ou de Greg, ce calcul consiste simplement à recalculer le secret partagé de nœud, puis les clés secrète et publique, pour le nœud N5. Alice quant à elle a reçu le message émis à l’étape S110, indiquant comme clés à renouveler et comme clé compromise la clé secrète de chacun des nœuds N2,2 ; N3,1 ; N4,1 ; N5. Elle a reçu lors des étapes S120-24 initiées par Bob et Dave des messages de mise à jour de nœuds indiquant comme nœuds mis à jour respectivement les nœuds N3,1 ; N4,1 et N5, puis les noeuds N2,2 ; N3,1 ; N4,1 et N5. Pour Alice, le premier nœud commun (entre sa chaîne de rattachement et celle du membre partant Bob) est le nœud N3,1. Alice détermine que la clé publique de ce nœud a été recalculée depuis le message émis à l’étape S110. Alice exécute donc l’étape S120-1. A l’étape S120-1, pour chaque nœud de sa chaîne de rattachement, à partir du premier nœud commun N3,1 et jusqu’au nœud racine N5, Alice (en tant que membre restant considéré) calcule le secret partagé du nœud considéré, et en déduit la clé publique et la clé secrète de nœud du nœud considéré. Elle recalcule ainsi les éléments cryptographiques pour les nœuds N3,1 ; N4,1 ; N5. Grâce à la clé secrète du nœud N5 elle calcule la valeur à jour de la clé symétrique de communication de groupe EncK group . Ces opérations mettent Alice en mesure d’échanger des messages avec le reste du groupe. La procédure de reconnexion d’un membre qui était inactif au moment du retrait du membre partant (Charles) est illustrée par la FIG. 9 , dans le cas de la reconnexion d’Esther. Ultérieurement, Esther active son terminal afin de se reconnecter au groupe. Esther reçoit alors les messages émis à l’étape S110 et aux différentes étapes S120-24. Dans le contexte du départ du membre U3, Charles, le premier nœud commun est le nœud N5. A l’étape S200, lorsqu’Esther (en tant que ‘membre se reconnectant’) active sa connexion au groupe, elle consulte les messages reçus du smart contract . A l’étape S210, puisqu’elle a reçu du smart contract le message de retrait de Charles, de proche en proche, Esther évalue les nœud(s) de sa chaîne de rattachement qui appartiennent aussi à la chaîne de rattachement du membre partant, c’est-à-dire en l’occurrence le nœud N5. A l’étape S210, Esther évalue l’état de ce premier nœud commun N5 : elle détermine que la clé publique de ce nœud a été renouvelée depuis le message émis à l’étape S110. Esther exécute alors l’étape S210-1 : elle calcule le secret partagé de groupe pour le nœud N5, et en déduit la clé secrète puis la clé publique pour le nœud N5. Elle en déduit enfin la clé symétrique de communication du groupe EncCK group . Dans le cas inversement où pour un ou plusieurs nœuds évalués, Esther constaterait que la clé publique de ce nœud n’a pas été renouvelée depuis le message émis à l’étape S110, Esther réaliserait les étapes S210-22, S210-24 et S210-26 indiquées précédemment, qui sont analogues aux étapes de l’étape S120-2. Selon une variante, si la procédure de retrait d’un membre est exécutée pendant une période pendant laquelle un des membres du groupe est inactif, la procédure de reconnexion suivante est suivie lors de la reconnexion de ce membre : La procédure d’ajout de membre au groupe est réalisée pour le membre en question comme s’il rejoignait le groupe pour la première fois. Des dispositions adéquates sont cependant prises de préférence pour que le membre en question conserve l’historique de ses interactions avec le groupe. Accès aux messages échangés pendant une période d’inactivité Lorsqu’un membre est inactif lors de l’ajout d’un nouveau membre au groupe ou du retrait d’un membre du groupe, du fait du renouvellement de la clé secrète de groupe, le membre inactif ne peut avoir accès aux messages qui sont échangés au sein du groupe à partir du changement de clé secrète de groupe faisant suite au départ ou à l’ajout d’un membre. Lorsque le membre se reconnecte, comme cela a été expliqué précédemment il calcule la nouvelle clé secrète du groupe et donc à la clé de communication de groupe qui en est dérivée : cela lui donne dès lors accès aux nouveaux messages échangés au sein du groupe. Cependant, cela ne lui donne pas accès aux messages qui ont été échangés entre l’ajout ou le retrait du membre du groupe et le moment de sa reconnexion au groupe. Pour permettre à ce membre, dit membre en reconnexion, d’avoir accès à ces messages, la procédure suivante, dite procédure d’accès, peut être exécutée. On prend comme exemple le cas de la reconnexion du membre U5, Esther, qui était déconnectée au moment où la procédure de retrait du membre U3, Charles, a été exécutée. Comme cela a été indiqué, à l’étape S120 chacun des membres restants actifs du groupe a effectué sa procédure de mise à jour. Ultérieurement, au moment de sa reconnexion, le membre U5, Esther, a réalisé la procédure de reconnexion décrite ci-dessus pour obtenir la nouvelle clé secrète du nœud racine et la nouvelle clé de communication de groupe. En complément, la procédure d’accès décrite ci-dessous va permettre à Esther d’avoir accès aux messages échangés de la procédure de retrait du membre jusqu’à ce qu’elle ait exécuté la procédure de reconnexion. Cette procédure d’accès comporte les étapes suivantes, illustrées par la FIG. 12 : A l’étape S600, à partir des informations publiées dans le registre concernant des ajouts ou retraits de membres et/ou des publications de clés publiques, et/ou en interrogeant le smart contract , Esther (en tant que ‘membre en reconnexion’) détermine le(s) authentifiant(s) d’un ou de membre(s) (‘membres détenteurs de clés’) auprès duquel ou desquels elle peut obtenir la ou les clé(s) secrète(s) temporaire(s) qui a/ont été utilisée(s) pendant sa période d’inactivité après le retrait du membre partant. Elle se procure alors la ou les clés secrètes de groupe qui lui manquent en contactant le(s) membre(s) détenteur(s) de clé identifié(s) via un canal de communication sécurisé. Lorsqu’elle contacte un membre détenteur de clé, elle procède de la manière suivante : A l’étape S610, elle (en tant que membre en reconnexion) demande au membre détenteur de clé de lui fournir une ou plusieurs clés secrètes dont il dispose et que le membre en reconnexion souhaiterait obtenir. A l’étape S620, pour répondre à cette demande, le membre détenteur de clé vérifie la légitimité de la demande du membre en reconnexion. A partir des informations publiées dans le registre concernant des ajouts ou retraits de membres et/ou des publications de clés publiques, et/ou en interrogeant le smart contract , il vérifie notamment : que le membre en reconnexion était habilité à avoir accès à la ou les clé(s) secrète(s) demandée(s), du fait qu’il était bien membre du groupe à un moment où cette/ces clé(s) secrète(s) demandée(s) étai(en)t la/les clé(s) secrète(s) courante(s) du groupe ; et que le membre en reconnexion fait toujours partie du groupe. A l’étape S630, si le membre détenteur de clé considéré a conclu à l’issue de l’étape S620 que la demande du membre en reconnexion est légitime, il ouvre un canal de communication auxiliaire sécurisé avec le membre en reconnexion. Tout procédé de sécurisation approprié peut être choisi pour ce canal de communication. Ce canal de communication sécurisé peut être ouvert par exemple en effectuant un échange de clés suivant le protocole de Diffie-Hellmann, en suivant le protocole indiqué par la demande de brevet français n°1763394. A l’étape S640, par le canal de communication auxiliaire sécurisé ainsi ouvert, le membre détenteur de clés considéré fournit alors au membre en reconnexion la ou les clés secrètes demandées. Celui-ci, à réception de celle(s)-ci, est alors à même de prendre connaissance des messages échangés pendant la période pendant laquelle cette ou clés étaient la/les clés courantes du groupe. DEUXIEME ASPECT A titre d’exemple, un mode de mise en œuvre de procédés suivant le deuxième aspect de la présente divulgation va maintenant être présenté en relation notamment avec les Figs. 5 et 6. Dans ce mode de mise en œuvre, les membres Ui du groupe sont gérés non pas à l’aide d’un arbre binaire, mais à l’aide d’une liste chaînée, c’est-à-dire une suite d’éléments consécutifs. Les caractéristiques générales du procédé décrites précédemment peuvent également être mises en œuvre dans le cas de la gestion du groupe par une liste chaînée. Comme précédemment, la clé secrète de groupe que le procédé de gestion permet à tous les membres du groupe de détenir de manière partagée est utilisée par chacun pour calculer une clé symétrique de communication pour le groupe, EncKp (à l’indice p du groupe), qui est calculée à partir de la clé secrète de groupe SK group p . La clé EncKp est utilisée par chacun des membres du groupe pour chiffrer et déchiffrer des messages échangés avec les autres membres du groupe. Dans ce mode de réalisation, une liste chaînée L est utilisée pour la gestion du groupe. Sur la FIG. 5 est représentée à titre d’exemple une liste L qui représente de manière schématique un groupe G. Comme on le voit sur cette figure, à l’instant considéré le groupe G comporte 4 membres : U1, Alice ; U2, Bob ; U3, Charles et U4, Dave. La liste L varie au cours du temps en fonction des admissions et des départs de membres, chaque admission ou départ entraînant au moins une mise à jour du groupe. Chaque mise à jour du groupe comporte une mise à jour de la liste L et des variables cryptographiques associées. Dans la liste L, une paire de clés asymétrique de groupe comportant une clé secrète SK group p et une clé publique PK group p est générée et associée au groupe G lors de la p ième mise à jour ; p est appelé l’indice courant (c’est-à-dire, à l’instant considéré) de cette paire de clés asymétrique de groupe. La clé publique de groupe PK group p peut être calculée à partir de la clé secrète SK group p à l’aide du crypto-système choisi pour le groupe, de manière connue en soi. Chaque clé publique de groupe PK group p est enregistrée dans le registre et donc est librement accessible (du moins pour les membres ayant accès au registre). Dans l’exemple de mise en œuvre présenté ici, le crypto-système choisi pour le groupe est un crypto-système de courbe elliptique, utilisant les paramètres (p, a, b, G, n et h). C’est donc un cryptosystème de même type que celui présenté dans le premier mode de mise en œuvre. Par conséquent, sauf indication contraire les opérations de calcul de clés sont réalisées pour le deuxième mode de mise en œuvre comme pour le premier mode de mise en œuvre. Notamment, dans ce mode de mise en œuvre le calcul de nouvelles clés secrète et publique de groupe se fait de manière indirecte : Dans un premier temps, un nouveau secret partagé de groupe (d’indice p+1) NPK group p+1 est calculé par une fonction de chiffrement combinant : - la clé publique d’un nouveau membre du groupe et la clé secrète de groupe d’indice précédent (p) ; ou - la clé secrète du nouveau membre du groupe et la clé publique de groupe d’indice précédent (p). La fonction de chiffrement Enc du crypto-système asymétrique (Enc,Dec) doit vérifier la même propriété que celle définie dans le premier mode de mise en œuvre. La nouvelle clé secrète de groupe SK group p +1 est dérivée du secret partagé de groupe NPK group p+1 par toute fonction de dérivation adaptée. La nouvelle clé secrète de groupe SK group p+1 peut ainsi être déduite du secret partagé de groupe comme étant égale à la composante sur x de NPK group p+1 : SK group p+1 = NPK group p+1 (x) De plus, la nouvelle clé publique de groupe PK group p+1 est obtenue à partir de la clé secrète SK group p+1 par la formule : PK group p+1 = SK group p+1 ● G. La fonction de dérivation doit naturellement être détenue par toute personne qui a à calculer une nouvelle valeur de la clé secrète de groupe. La clé symétrique de groupe servant à permettre l’échange de messages entre membres du groupe est alors calculée comme étant égale à la deuxième composante (la composante en y) du secret partagé de groupe. Elle est donc fournie par l’équation : encK group p+1 = NPK group p+1 (y). Ajout de membre Les modalités d’admission de nouveaux membres dans le groupe G suivant le procédé de gestion vont maintenant être présentées à titre d’exemple au moment représenté sur la FIG. 5 , où une candidate, Esther, rejoint le groupe G. Les étapes de la procédure sont illustrées par la FIG. 10 . Dans cette situation initiale, dite ‘avant-ajout’, chacun des membres du groupe (Alice, Bob, Charles, Dave) détient la clé secrète de groupe SK group 4 (on suppose qu’il n’y a pas eu de retrait de membre depuis la création du groupe, donc l’indice du groupe est p=4). La clé publique avant-ajout (PK group 4 ) du groupe avant-ajout est enregistrée dans le registre. La procédure d’ajout pour ajouter Esther dans le groupe comprend les opérations suivantes : Préalablement, Esther s’est dotée d’une paire de clés asymétrique comprenant une clé secrète personnelle (SK Esther ) à partir de laquelle sa clé publique personnelle (PK Esther ) a été calculée à l’aide du crypto-système du groupe. Par ailleurs, à l’instant où la procédure d’ajout de membre est exécutée, Alice, Bob et Dave sont actifs mais inversement, Charles est inactif. A l’étape S310, Esther soumet sa demande d’admission à l’administratrice du groupe, Alice. Alice vérifie qu’Esther remplit les conditions d’admission dans le groupe. En l’occurrence, elle conclut que ces conditions sont remplies et transmet la demande d’admission au smart contract , en joignant l’authentifiant (acc Esther ) et la clé publique personnelle (PK Esther ) d’Esther. A l’étape S320, le smart contract enregistre Esther dans le registre comme nouveau membre du groupe, en enregistrant notamment son authentifiant acc Esther et sa clé publique PK Esther . A l’étape S330 à partir de la clé publique avant-ajout (PK group 4 ) du groupe avant-ajout et de sa clé privée personnelle (SK Esther ) la candidate, Esther, calcule une nouvelle valeur de clé secrète du groupe (SK group 5 ) puis une nouvelle valeur de clé publique du groupe (PK group 5 ) pour le groupe G. A l’étape S340, Esther publie dans le registre la nouvelle valeur de clé publique du groupe (PK group 5 ) calculée à l’étape S330. A l’étape S350, le smart contract envoie un message de mise à jour de clé de groupe, dans ce mode de réalisation, à tous les membres actifs avant-ajout du groupe, à savoir Alice, Bob et Dave. A l’étape S360, à réception de ce message, à partir de la clé secrète avant-ajout (SK group 4 ) du groupe avant-ajout et de la clé publique personnelle PK Esther d’Esther, chacun d’eux calcule la nouvelle valeur de clé secrète du groupe SK group 5 en appliquant la formule donnée ci-dessus, et ainsi : SK group 5 = SK group 4 ● PK Esther . A l’étape S370, chacun d’eux calcule alors de plus la clé symétrique de communication du groupe EncK5, ce qui lui permet de continuer à échanger des messages avec le groupe, comprenant maintenant Esther. Ainsi par construction, la liste des membres du groupe est la liste ordonnée dans l’ordre chronologique de leurs dates d’admission ou plutôt de leurs dates de dernière admission dans le groupe. Dans certains modes de mise en œuvre, les positions dans le groupe des membres du groupe sont indexées par un index et sont suivies par le smart contract . Procédure de reconnexion des membres inactifs suite à l’ajout d’un membre Un peu plus tard, Charles (comme exemple de membre ayant été inactif) se reconnecte au groupe. Le smart contract détecte cette reconnexion (ou bien Charles envoie au smart contract un message signalant sa reconnexion) et envoie à Charles un message de mise à jour de clé de groupe. (Selon une variante, à l’étape S350 le message de mise à jour de clé de groupe est envoyé à la totalité des membres avant-ajout du groupe, qu’ils soient actifs ou pas). Charles exécute la procédure de reconnexion en effectuant les opérations suivantes : A l’étape S400, Charles consulte les messages reçus du smart contract . Il constate donc que le smart contract lui a envoyé un message de mise à jour de clé de groupe. A l’étape S410, en raison de ce message, à partir de la clé secrète avant-ajout (SK group 4 ) du groupe avant-ajout, qu’il détient, et de la clé publique personnelle (PK Esther ) d’Esther, Charles à son tour calcule la nouvelle valeur de clé secrète du groupe (SK group 5 ). Il calcule alors la clé symétrique de communication du groupe EncK5, ce qui lui permet à nouveau d’échanger des messages avec le groupe. Retrait d’un membre Lorsqu’un membre du groupe (dit ‘membre partant’) quitte le groupe G (à un indice de mise à jour p), une procédure de retrait de membre est exécutée pour assurer qu’après le départ du membre, celui-ci ne dispose plus de la clé symétrique secrète EncK grou p p utilisée pour le chiffrement des messages dans le groupe et par suite, ne peut plus avoir accès aux messages échangés par le groupe. Plus généralement la procédure de retrait vise à renouveler la clé secrète de groupe SK group p , pour que le membre partant ne puisse plus avoir accès à des informations confidentielles relatives au groupe. La procédure de retrait suivante est donc exécutée lorsque le retrait d’un membre partant est décidé : On prend comme exemple le cas où Charles (membre U3 du groupe), quitte le groupe G dont l’arbre A est représenté sur la FIG. 6 . La FIG. 6 représente l’arbre A au moment de l’exécution de la procédure de retrait suite au départ de Charles. Les étapes de la procédure sont illustrées par la FIG. 11 . A l’étape S500, Charles, ou éventuellement Alice l’administratrice du groupe, envoie au smart contract une demande de retrait du membre partant, Charles. A l’étape S510, le smart contract identifie un membre Uini, dit membre d’initialisation, qui est un membre actif du groupe ayant rejoint le groupe avant le membre partant, Charles. Dans l’exemple présenté ici, Bob est identifié comme membre d’initialisation Uini. A l’étape S520, le smart contract envoie un message de nouvel ajout au groupe à chaque membre du groupe ayant rejoint le groupe après le membre d’initialisation (Bob), sauf à Charles naturellement, invitant celui-ci à se joindre à nouveau au groupe. Chacun des membres à qui ces messages sont envoyés est appelé ‘membre à réintégrer’ ; les principales étapes de la procédure d’ajout de membre vont devoir être exécutées pour le membre à réintégrer pour permettre la mise à jour de la clé secrète du groupe. Par conséquent à l’étape S530, pour chaque membre à réintégrer (Up), les étapes S330 à S360 de la procédure d’ajout de membre sont effectuées, en considérant le membre à réintégrer comme étant le candidat. Une fois que ces étapes ont été effectuées, chaque membre à réintégrer calcule alors à partir de la nouvelle clé secrète de groupe la clé symétrique de communication du groupe, EncK group p+1 . En recalculant ainsi la clé secrète du groupe successivement, à partir du membre d’initialisation, pour chacun des membres à réintégrer, une nouvelle valeur de clé secrète pour le groupe est progressivement calculée. Cette valeur est partagée entre tous les membres actifs du groupe, mais n’est pas connue du membre qui s’est retiré. Procédure de reconnexion des membres inactifs suite au retrait d’un membre Comme on peut le voir sur la FIG. 6 , au moment de la procédure de retrait, Dave est inactif. Un peu plus tard, Dave (comme exemple de membre ayant été inactif) se reconnecte au groupe. Le smart contract détecte cette reconnexion (ou bien Dave envoie au smart contract un message signalant sa reconnexion) et envoie à Dave un message de nouvel ajout au groupe (Selon une variante, à l’étape S420 le message de nouvel ajout au groupe peut être envoyé à la totalité des membres du groupe (hormis au membre qui se retire)). Dave exécute la procédure de reconnexion en effectuant les opérations suivantes : , Dave consulte les messages reçus du smart contract . Il constate donc que le smart contract lui a envoyé un message de nouvel ajout au groupe. Par conséquent à l’étape suivante, les étapes S330 à S360 de la procédure d’ajout de membre sont effectuées, en considérant Charles (en tant que membre à réintégrer) comme étant le candidat. Une fois que ces étapes ont été effectuées, Charles calcule alors à partir de la nouvelle clé secrète de groupe la clé symétrique de communication du groupe, EncK group p+1 . Par ailleurs, si Dave souhaite avoir accès à des messages qui ont été échangés au sein du groupe pendant sa période d’inactivité, il peut exécuter la procédure d’obtention de clés secrète décrite précédemment pour le premier mode de mise en œuvre. Cela lui permet alors d’obtenir les clés secrètes de groupe qui étaient les clés secrètes courantes du groupe pendant sa période d’inactivité. A partir de ces clés secrètes, il peut calculer les clés de communication du groupe pendant cette même période, et ainsi il peut déchiffrer les messages chiffrés échangés pendant cette période. Un exemple de mise en œuvre des procédés de gestion de groupe selon la présente divulgation est illustré par la FIG. 13 . Cette figure présente un procédé de communication chiffrée au sein d’un groupe, comprenant les étapes suivantes : A. on constitue le groupe en mettant en œuvre l’un des procédés de gestion de groupe présentés précédemment. B. Au moins un membre du groupe calcule une clé symétrique de groupe à partir de la clé secrète de groupe. C. Ensuite, ce membre reçoit un message et déchiffre celui-ci à l’aide de la clé symétrique de groupe, ou chiffre un message à l’aide de la clé symétrique de groupe et envoie celui-ci. Procédé de gestion d’un groupe comprenant une pluralité de membres (U 1 … U n ), chaque membre (U i ) détenant ou étant en mesure de détenir une clé secrète (SKj,k,p) de groupe, le procédé faisant appel à un crypto-système asymétrique (Enc,Dec) vérifiant la propriété, pour deux paires de clés asymétriques (PK1,SK1) et (PK2,SK2) : Enc(PK1,SK2) = Enc(SK1,PK2), où Enc est la fonction de chiffrement du crypto-système, et à un registre (B) dans lequel un smart contract (SC) est déployé ; un arbre binaire (A) étant utilisé pour ordonner les membres du groupe ; chaque membre (Ui) étant associé à un nœud terminal de l’arbre, ce nœud étant rattaché à un nœud racine de l’arbre, directement ou via une suite d’au moins un nœud (Nj,k), le nœud racine et lorsqu’elle existe ladite suite d’au moins un nœud constituant la chaîne de rattachement du membre (Ui) considéré ; chaque membre du groupe disposant d’une paire de clés asymétrique, dont la clé secrète et la clé publique sont considérées comme la clé secrète de nœud et la clé publique de nœud pour le nœud terminal associé au membre ; la clé publique du nœud racine étant appelée clé publique du groupe ; le procédé comprenant une procédure d’ajout de membre pour intégrer au groupe un candidat souhaitant rejoindre le groupe, à un instant donné où le groupe (G) est constitué par un ensemble de membres (Up), dits membres avant-ajout, formant un arbre avant-ajout (An), chaque membre avant-ajout (Uav) dispose de ou est en mesure de calculer une clé secrète avant-ajout de nœud (SKj,k,n) pour tout nœud (Nj,k,n) de sa chaîne de rattachement ; et pour chaque nœud de l’arbre avant-ajout (An), une clé publique avant-ajout (PKj,k,n) de nœud est enregistrée dans le registre ; la procédure d’ajout de membre comprenant les opérations suivantes : S10) une demande d’admission dans le groupe du candidat (U n+1 ) est transmise au smart contract , la demande d’admission comprenant un authentifiant (acc User ) et une clé publique personnelle (PKUn+1) du candidat, le candidat détenant en outre une clé privée personnelle (SKUn+1) à partir de laquelle sa clé publique personnelle (PKUn+1) a été calculée au moyen du crypto-système ; S20) le smart contract enregistre dans le registre l’admission dans le groupe (G) d’un nouveau membre ayant l’authentifiant (acc Un+1 ) du candidat et la clé publique du candidat (PKUn+1) ; S30) le candidat détermine ou obtient du smart contract une liste du ou des nœuds de sa chaîne de rattachement dans l’arbre ; S40) de proche en proche, pour chaque nœud de sa chaîne de rattachement, depuis le nœud de l’arbre auquel il est directement rattaché jusqu’au nœud racine (N1), le candidat calcule la clé secrète de nœud (SKj+1,k1,n+1) puis la clé publique de nœud (PKj+1,k1,n+1) ; S50) le candidat publie dans le registre la ou les clé(s) publique(s) de nœud (PKj,k,n) calculée(s) à l’étape S40 ; S60) le smart contract envoie un message d’ajout de membre au moins à chaque membre actif avant-ajout du groupe ; et S70) à réception du message d’ajout de membre, de proche en proche, pour chaque nœud de sa chaîne de rattachement qui fait également partie de la chaîne de rattachement du candidat, dans le sens allant du nœud de l’arbre auquel il est directement rattaché vers le nœud racine (Ns), chaque membre actif avant-ajout (Up) calcule la clé secrète de nœud (SKj+1,k1,n+1) ; la clé secrète de nœud (NPKj,k,p+1) d’un nœud donné (Nj,k) étant calculée par une personne dont la chaîne de rattachement contient un premier fils du nœud donné: - si ledit nœud donné a un deuxième fils et que ladite personne a accès à une clé publique non compromise du deuxième fils, en fonction de la clé secrète (SKj,k2-1,n) du premier fils actif et de la clé publique (PKj,k2,n) dudit deuxième fils dudit nœud donné ; ou dans tout autre cas, - en fonction de la clé secrète (SKj-1,k1,p) du premier fils dudit nœud donné. Procédé de gestion d’un groupe selon la revendication 1, le procédé comprenant en outre une procédure de retrait d’un membre du groupe, dit membre partant (Up), autre que le membre ayant rejoint le groupe en dernier, pour retirer du groupe le membre partant, ladite procédure de retrait de membre comprenant : S100) une demande de retrait du membre partant (Up) est envoyée au smart contract ; S110) le smart contract envoie un message de mise à jour de clés au moins à chaque membre actif restant du groupe, indiquant comme clé(s) à renouveler et comme clé compromise la clé secrète de chacun dudit ou desdits nœuds de la chaîne de rattachement du membre partant ; S120) chaque membre restant actif (U1,U2,U6,U7), dit membre restant considéré (U2), évalue le nœud, dit premier nœud commun, qui est le nœud de sa chaîne de rattachement (CR2) qui est le plus éloigné du nœud racine et qui appartient aussi à la chaîne de clés à renouveler ; S120-1) si la clé publique du premier nœud commun a été renouvelée depuis le message de mise à jour de clés, de proche en proche, le membre restant considéré calcule la clé secrète et la clé publique de nœud du nœud considéré, à partir du premier nœud commun et jusqu’au nœud racine ; inversement, S120-2) si la clé publique du premier nœud commun n’a pas été renouvelée depuis le message de mise à jour de clés : S120-22) pour chaque nœud, dit nœud à mettre à jour, situé sur la chaîne de rattachement allant du premier nœud commun au nœud racine, le membre restant considéré calcule la clé secrète et la clé publique de nœud du nœud à mettre à jour, et publie cette dernière dans le registre, ledit nœud à mettre à jour étant alors appelé nœud mis à jour ; tout nœud dont la clé publique est compromise étant considéré comme inexistant lors de tout calcul de clé secrète de nœud ; S120-24) le smart contract envoie un message de mise à jour de nœud au moins à chaque autre membre actif du groupe, c’est-à-dire au moins à chaque membre du groupe, actif, autre que le membre partant et le membre restant considéré, indiquant le nœud mis à jour ; S120-26) de proche en proche, chaque autre membre calcule la clé secrète de nœud du nœud considéré, pour chaque nœud mis à jour faisant également partie de sa chaîne de rattachement, dans le sens allant du nœud terminal de l’arbre auquel il est rattaché vers le nœud racine (Ns). Procédé de gestion d’un groupe selon la revendication 2, comprenant en outre un procédé de reconnexion d’un membre du groupe après retrait d’un membre partant, dans lequel : S200) lorsqu’un membre du groupe, dit membre se reconnectant (Ur), active sa connexion au groupe après une période d’inactivité, le membre se reconnectant (Ur) consulte les messages reçus du smart contract ; S210) lorsque le membre se reconnectant (Ur) a reçu du smart contract un message de retrait de membre, le membre se reconnectant évalue le nœud, dit premier nœud commun, qui est le nœud de sa chaîne de rattachement qui est le plus éloigné du nœud racine et qui appartient aussi à la chaîne de clés à renouveler : S210-1) si la clé publique du nœud évalué a été renouvelée depuis le message de mise à jour de clés, de proche en proche, le membre se reconnectant calcule la clé secrète et la clé publique de nœud du nœud considéré, à partir du premier nœud commun et jusqu’au nœud racine ; ou inversement, S210-2) si la clé publique du nœud évalué n’a pas été renouvelée depuis le message de retrait de membre : S210-22) pour chaque nœud, dit nœud à mettre à jour, situé sur la chaîne de rattachement allant du premier nœud commun au nœud racine, le membre se reconnectant calcule la clé secrète et la clé publique de nœud du nœud à mettre à jour et publie cette dernière dans le registre, ledit nœud à mettre à jour étant alors appelé nœud mis à jour ; tout nœud dont la clé publique est compromise étant considéré comme inexistant lors de tout calcul de clé secrète de nœud ; S210-24) le smart contract envoie un message de mise à jour de nœud au moins à chaque autre membre du groupe actif, c’est-à-dire chaque membre du groupe, actif, autre que le membre partant et le membre se reconnectant, indiquant le nœud mis à jour ; S210-26) de proche en proche, chaque autre membre calcule la clé secrète de nœud du nœud considéré, pour chaque nœud mis à jour faisant également partie de sa chaîne de rattachement, dans le sens allant du nœud terminal de l’arbre auquel il est directement rattaché vers le nœud racine (Ns). Procédé de gestion selon l’une quelconque des revendications 1 à 3, dans lequel au moins une clé secrète de nœud (NPKj,k,p+1) d’un nœud donné (Nj,k) est calculée : - en calculant un élément cryptographique dit secret partagé de noeud (NPKj,k,p) en fonction de la clé secrète (SKj,k2-1,n) d’un premier fils et de la clé publique (PKj,k2,n) d’un deuxième fils du nœud donné ; et - en calculant la clé secrète (SKj,k,p+1) du nœud donné (Nj,k) à partir dudit secret partagé de noeud (NPKj,k,p), par exemple comme étant égale à une partie du secret de nœud. Procédé de gestion d’un groupe comprenant une pluralité de membres (U 1 … U n ) , chaque membre (U i ) détenant ou étant en mesure de détenir une clé secrète (sk Nj,k ) de groupe, le procédé faisant appel à un crypto-système asymétrique (Enc,Dec) vérifiant la propriété, pour deux paires de clés asymétriques (PK1,SK1) et (PK2,SK2) : Enc(PK1,SK2) = Enc(SK1,PK2), où Enc est la fonction de chiffrement du crypto-système, et à un registre (B) dans lequel un smart contract (SC) est déployé ; une liste (Ln) étant utilisée pour ordonner les membres du groupe ; le procédé comprenant une procédure d’ajout de membre pour intégrer au groupe un candidat souhaitant rejoindre le groupe, à un instant donné où le groupe (G) est constitué par un ensemble de membres (Up), dits membres avant-ajout, chaque membre avant-ajout (Uav) dispose de ou est en mesure de calculer une clé secrète avant-ajout (SKgroup n) du groupe avant-ajout ; et une clé publique avant-ajout (PKgroup n) du groupe avant-ajout est enregistrée dans le registre ; dans laquelle la procédure d’ajout de membre comprend les opérations suivantes : S310) une demande d’admission dans le groupe du candidat (U n+1 ) est transmise au smart contract , la demande d’admission comprenant un authentifiant (acc User ) et une clé publique personnelle (PKUn+1) du candidat, le candidat détenant en outre une clé privée personnelle (SKUn+1) à partir de laquelle sa clé publique personnelle (PKUn+1) a été calculée au moyen du crypto-système ; S320) le smart contract enregistre dans le registre l’admission dans le groupe (G) d’un nouveau membre du groupe ayant l’authentifiant (acc Un+1 ) du candidat et la clé publique du candidat (PKUn+1); S330) à partir de la clé publique avant-ajout (PKgroup n) du groupe avant-ajout et de sa clé privée personnelle (SKUn+1) le candidat calcule une nouvelle clé secrète du groupe (SKgroup n+1) puis une nouvelle clé publique du groupe (PKgroup n+1) pour le groupe ; S340) le candidat publie dans le registre la nouvelle valeur de clé publique du groupe (PKgroup n+1) calculée à l’étape S330 ; S350) le smart contract envoie un message de mise à jour de clé de groupe au moins à chaque membre actif avant-ajout du groupe ; et S360) à réception du message de mise à jour de clé de groupe, à partir de la clé secrète avant-ajout (SKgroup n) du groupe avant-ajout et de la clé publique personnelle (PKUn+1) du candidat, chaque membre avant-ajout (Up) actif calcule la nouvelle clé secrète du groupe (SKgroup n+1). Procédé de gestion d’un groupe selon la revendication 5, dans lequel : au plus tard peu après une reconnexion d’un membre du groupe ayant été inactif, ou sur demande de celui-ci lors de la reconnexion de celui-ci, lorsque la procédure d’ajout de membre a été exécutée, le smart contract envoie un message de mise à jour de clé de groupe après ajout d’un membre audit membre ayant été inactif ; et le procédé de gestion de groupe comprend en outre un procédé de reconnexion dudit membre ayant été inactif après ajout d’un membre, dans lequel : S400) lorsque ledit membre ayant été inactif se reconnecte au groupe, il consulte les messages reçus du smart contract ; S410) lorsque le membre se reconnectant (Ur) a reçu du smart contract un message de mise à jour de clé de groupe après ajout d’un membre, à partir de la clé secrète avant-ajout (SKgroup n) du groupe avant-ajout et de la clé publique personnelle (PKUn+1) du candidat, ledit membre ayant été inactif calcule la nouvelle clé secrète du groupe (SKgroup n+1). Procédé de gestion d’un groupe selon la revendication 5 ou 6, le procédé comprenant en outre une procédure de retrait d’un membre du groupe, dit membre partant (Up), autre que le membre ayant rejoint le groupe en dernier, pour retirer du groupe le membre partant, ladite procédure de retrait de membre comprenant : S500) une demande de retrait du membre partant (Up) est envoyée au smart contract ; S510) le smart contract identifie un membre (U ini ), dit membre d’initialisation, qui est un membre actif du groupe ayant rejoint le groupe avant le membre partant ; S520) le smart contract envoie un message de nouvel ajout au groupe à chaque membre actif du groupe ayant rejoint le groupe après le membre d’initialisation, dit membre à réintégrer, à l’exception du membre partant, invitant celui-ci à se joindre à nouveau au groupe ; S530) à réception du message de nouvel ajout au groupe, pour chaque membre à réintégrer (Up), les étapes S330 à S360 de la procédure d’ajout de membre sont effectuées, en considérant le membre à réintégrer comme étant le candidat. Procédé de gestion selon l’une quelconque des revendications 5 à 7, dans lequel au moins une nouvelle clé secrète (SK group p +1 ) de groupe est calculée : - en calculant un élément cryptographique dit secret partagé de groupe (NPK group p ) en fonction de la clé secrète (SKi,p) d’un membre du groupe et d’une clé publique (PK group p ) du groupe, ou encore en fonction en fonction de la clé publique (PKi,p) d’un membre du groupe et d’une clé secrète (SK group p ) du groupe ; et - en calculant la nouvelle clé secrète (SKj,k,p+1) du groupe à partir dudit secret partagé de groupe (NPK group p ), par exemple comme étant égale à une partie du secret de groupe. Procédé de gestion selon l’une quelconque des revendications 1 à 8, dans laquelle : lorsqu’une nouvelle clé publique de groupe est enregistrée dans le registre, le smart contract assigne un statut ‘Aveugle’ à tous les membres restants autres que le membre, dit membre de mise à jour de groupe, ayant déclenché cet enregistrement ; lorsqu’un membre autre que le membre déclencheur calcule la clé secrète de groupe, il en informe le smart contract ; sur cette base, celui-ci assigne un statut ‘En-ligne’ audit membre autre ; et le procédé comporte au moins une procédure mise en œuvre à l’aide du smart contract , autre qu’une procédure d’ajout ou de retrait de membre, dans laquelle au moins une action du smart contract est réalisée en fonction du statut du membre. Procédé de gestion selon l’une quelconque des revendications 1 à 9, comportant en outre une procédure d’obtention rétroactive par un membre en reconnexion suite à une période d’inactivité d’au moins une clé secrète de groupe à obtenir, qui avait été une clé courante du groupe pendant ladite période d’inactivité, ladite procédure d’obtention rétroactive comportant les étapes suivantes : S600) à partir d’informations publiées dans le registre et/ou en interrogeant le smart contract , le membre en reconnexion détermine un authentifiant d’un membre détenteur de clé auprès duquel il peut obtenir ladite au moins une clé secrète à obtenir ; S610) le membre en reconnexion demande au membre détenteur de clé de lui fournir ladite au moins une clé secrète à obtenir ; S620) le membre détenteur de clé vérifie que le membre en reconnexion était membre du groupe à un moment où ladite au moins une clé secrète demandée était la clé secrète courante du groupe, et que le membre en reconnexion fait toujours partie du groupe. S630) si le résultat de la vérification est positif, le membre détenteur de clé considéré ouvre un canal de communication auxiliaire sécurisé avec le membre en reconnexion, par exemple en suivant le protocole indiqué par la demande de brevet français n°1763394 ; et S640) par le canal de communication auxiliaire sécurisé ainsi ouvert, le membre détenteur de clé considéré fournit au membre en reconnexion ladite au moins une clé secrète à obtenir demandée. Procédé de gestion de groupe selon l’une quelconque des revendications 1 à 10, comprenant en outre une étape (S80 ; S370), au cours de laquelle au moins un membre actif du groupe calcule une clé symétrique de groupe à partir d’une clé secrète de groupe. Procédé de gestion selon la revendication 11, dans lequel pour calculer ladite clé symétrique de groupe, ledit au moins un membre actif du groupe : - calcule un élément cryptographique dit secret partagé de groupe (NPK group p ) en fonction de sa clé secrète (SKi,p) et d’une clé publique (PK group p ) du groupe, ou encore en fonction de la clé publique (PKi,p) d’un membre du groupe et d’une clé secrète (SK group p ) du groupe ; et - calcule la clé symétrique (EncK group p +1 ) du groupe à partir dudit secret partagé de groupe (NPK group p ), par exemple comme étant égale à une partie du secret de groupe. Procédé de communication chiffrée au sein d’un groupe, comprenant les étapes suivantes : A. on constitue le groupe en mettant en œuvre le procédé de gestion de groupe selon l’une quelconque des revendications 1 à 12 ; B. au moins un membre du groupe calcule une clé symétrique de groupe (EncK group p ) à partir de la clé secrète de groupe (SK group p ) ; et C. ce membre reçoit un message et déchiffre celui-ci à l’aide de la clé symétrique de groupe, ou chiffre un message à l’aide de la clé symétrique de groupe et envoie celui-ci.