Method for managing a group sharing a secret key

Abstract

The invention relates to a method for managing a group comprising a plurality of members (U1…Un), each member (Ui) holding or being able to hold a group secret key (SKj,k,p). The method uses an asymmetric cryptosystem and a ledger (B) in which a smart contract (SC) is deployed. A data structure such as a binary tree or a linked list (A) is used to order the group members. The method includes a member addition procedure for integrating a candidate wishing to join the group, during which, through operations similar to the Diffie-Hellman protocol and with the aid of the smart contract, the new member is added to the group, and a new group secret key is calculated and shared by each of the group members, including the new member. Figure 1 illustrates this in the abstract.

Description

Title of the invention: Method for managing a group sharing a secret key. TECHNICAL FIELD OF THE INVENTION

[0001] The field of the invention is the secure execution of operations by one or more members of a group. These operations include, in particular, the exchange of messages between members of the group, access control to sensitive areas (using a unique identifier), etc.

[0002] To ensure that such operations are carried out in a secure manner, a group secret, which can also be called a secret key, can be shared by the members of the group.

[0003] Therefore, the invention more specifically relates to a group management method allowing the sharing of a group secret within the group. PRIOR TECHNOLOGY

[0004] The communication of information between people, for example by means of an instant messaging application, requires taking into account a number of constraints.

[0005] Such an application may need to provide a guarantee of confidentiality within each group, and protect the identification data of members, in order to comply with the various applicable regulations, such as the General Data Protection Regulation in the European Union.

[0006] The implementation of such an application is particularly complex in a context where members communicate via their personal devices, for example smartphones, forming a decentralized network of asynchronous communications.

[0007] To implement such an application with a high level of communication security, a known solution is to manage each group of members who need to exchange messages securely in such a way that a common secret is shared among the members of the group.

[0008] This common secret will then be used (in particular) to calculate an encryption key, for example symmetric, to allow the exchange of information between members of the group in a secure manner.

[0009] That being said, maintaining a common and unique secret for each group, allowing its members to exchange encrypted messages known only to them, in such a way that this secret is updated each time a new member leaves or arrives in the group, while ensuring the continuity of confidential exchanges for the other members of the group, requires ensuring several properties: - The continuous updating of the group's encryption key upon the arrival of a new member, - Upgrading the group's encryption key when a member leaves, - Access at any time (continue access) to the group's encryption key for all group members.

[0010] Additional security requirements may apply, including: - That secrets are calculated and stored at the level of each user device legitimately entitled to know them, - To avoid single points of failure in the system, where an attack could compromise the availability and / or confidentiality of the solution, - To avoid 'man-in-the-middle' attacks while preserving the identification data of members.

[0011] To allow a common cryptographic secret to be shared between the For members of a group, it is necessary to encrypt data in order to exchange it confidentially within the group. This requires a way to share public intermediate information that allows the calculation of the shared secret privately. If the communication devices of the group members are connected within the same network, they can exchange messages that enable the creation of the shared secret. For example, over the internet, public information (such as public keys) can be transmitted if the IP addresses of each group member are known to all other members.

[0012] In most existing messaging applications, a server is used for the exchange of public information within a group.

[0013] However, such a centralized server constitutes a single potential point of failure, particularly exposed as a consequence to various cyber attacks such as denial-of-service attacks, "man in the middle" attacks, malware attacks, etc.

[0014] To avoid such a weakness, an alternative solution is to use blockchain to enable information sharing between two people. Such communication methods are disclosed, for example, in French patent applications no. 1763393 and no. 1763394.

[0015] The processes disclosed by these patents use the Diffie-Hellman protocol for the exchange of information between two parties. This protocol is a procedure that allows the generation of a secret shared between two people, known only to those two people.

[0016] The generation of such a session key relies on the possession of an asymmetric key pair by each of the two persons involved in the protocol of Diffie-Hellman. Thus, by implementing this protocol, a person with their own unique asymmetric key pair is able to initiate the calculation of a secret shared with another person who also has their own unique asymmetric key pair.

[0017] For the implementation of this Diffie-Hellman protocol, each of the two people must have an asymmetric key pair, comprising a private key and the corresponding public key (this asymmetric key pair is therefore calculated using an asymmetric cryptosystem).

[0018] The asymmetric cryptography algorithm used is generally a modular arithmetic algorithm: The cryptosystem can be a Rivest-Shamir-Adleman cryptosystem (RSA), or based on elliptic curves (Elliptic Curve Cryptography, ECC).

[0019] The Diffie-Hellman protocol comprises the following steps:

[0020] A1) each of the two persons records the public key of their key pair asymmetrical in the register;

[0021] A2) each of the two persons reads the other's public key from the register; and

[0022] A3) each of the two people constructs the shared secret.

[0023] The Diffie-Hellman protocol thus makes it possible to generate a secret shared between two people. It is described in more detail in French patent applications no. 1763393 and no. 1763394 cited above.

[0024] However, the communication methods are limited to exchange between two people.

[0025] Other methods have been developed based on the Diffie-Hellman protocol to enable the secure exchange of information within a group of more than two people. Among these methods, the best known use ring and tree representations of the group.

[0026] In these latter methods, the generation of a secret shared by the group requires several successive executions of the Diffie-Hellman protocol. The main difference between these different methods is the organization and order of execution of these protocols.

[0027] However, these latter methods do not offer a sufficient level of security against "man in the middle" attacks.

[0028] There is therefore a need for communication methods enabling the secure exchange of information between members of a group, these methods being robust against "man in the middle" attacks, and not requiring the use of a central server. Description of the invention

[0029] The present invention aims to remedy all or part of the disadvantages of the prior art mentioned above.

[0030] To enable the implementation of messaging applications between members of a group, or more generally applications enabling the exchange of information between members of a group, according to this disclosure, a group management method enabling the sharing of a group secret (more precisely a group secret key) within the group is proposed.

[0031] Indeed, advantageously holding a common group secret key within a group makes it possible to determine an encryption key, for example symmetric: this then allows the exchange of information in a secure manner between the members of the group.

[0032] According to a first aspect of the invention, a first method for managing a group is proposed, in which the group is tracked using a binary tree.

[0033] The method is a method for managing a group comprising a plurality of members, each member holding or being able to hold a group secret key, the method using an asymmetric cryptosystem (Enc,Dec) verifying ownership, for two pairs of asymmetric keys (PKI,SKI) and (PK2,SK2):

[0034] Enc(PKl,SK2) = Enc(SKl,PK2), where Enc is the encryption function of the cryptosystem, and to a register in which a smart contract is deployed;

[0035] a binary tree being used to order the members of the group;

[0036] each member being associated with a terminal node of the tree, this node being attached to a root node of the tree, directly or via a sequence of at least one node, the root node and where it exists said sequence of at least one node constituting the chain of attachment of the member considered;

[0037] each member of the group having an asymmetric key pair, of which the secret key and the public key are considered as the node secret key and the node public key for the terminal node associated with the member;

[0038] the public key of the root node being called the public key of the group;

[0039] the method comprising a procedure for adding a member to integrate into the group a candidate wishing to join the group,

[0040] at a given moment where

[0041] the group consists of a set of members, called pre-addition members, forming a pre-addition tree,

[0042] each pre-addition member has or is able to compute a pre-addition node secret key for any node in its attachment chain; and

[0043] for each node of the pre-addition tree, a pre-addition node public key is recorded in the registry;

[0044] the member addition procedure comprising the following operations:

[0045] S10) an application for admission to the candidate's group is transmitted to the smart contract, the application for admission including an authenticator and a personal public key of the candidate, the candidate also holding a personal private key from which his personal public key was calculated using the cryptosystem;

[0046] S20) the smart contract records in the register the admission into the group of a new member having the candidate's authenticator and the candidate's public key;

[0047] S30) the candidate determines or obtains from the smart contract a list of the node(s) of its chain of attachment in the tree;

[0048] S40) step by step, for each node of its chain of attachment, from the node of the tree to which it is directly attached up to the root node (NI), the candidate calculates the node secret key and then the node public key;

[0049] S50) the candidate publishes in the registry the public key(s) of node calculated at step S40;

[0050] S60) the smart contract sends a member addition message at least at each active member prior to group addition; and

[0051] S70) upon receipt of the member addition message, from one person to another, for each node of its attachment chain which is also part of the candidate's attachment chain, in the direction from the node of the tree to which it is directly attached towards the root node, each active member before addition calculates the node secret key;

[0052] the secret key of a given node being calculated by a person whose chain of attachment contains a first child of the given node:

[0053] - if said given node has a second child and said person has access to a key the uncompromised public key of the second child, based on the secret key of the first active child and the public key of said second child of said given node; or in any other case,

[0054] - depending on the secret key of the first child of said given node.

[0055] The method defined above can be implemented with different cryptosystems, provided that they satisfy the property stated above (Enc(PKl,SK2) = Enc(SKl,PK2)). It is thus possible to choose a cryptosystem based on elliptic curves, an RSA cryptosystem, or possibly certain post-quantum cryptosystems, particularly those based on lattices.

[0056] For the implementation of the method, in addition a rule for adding a new member to the tree (also called a tree construction rule) is chosen beforehand.

[0057] Depending on the rule chosen, the position in the tree to which a new group member is added can be calculated simply from the information The successive arrivals and departures of group members result from a choice. In the first case, at step S30, the candidate can determine their own membership chain. This is the case, for example, if, during the construction of the tree, a member's departure does not result in a new member taking their place; and if the candidates are placed in the tree in such a way that all group members are at the same level at any given time, and placed there in chronological order of their last admission to the group. In the second case, the position in the tree assigned to a new member can be determined by the smart contract; the smart contract then communicates its membership chain to the candidate upon their admission at step S30.

[0058] At step S10, as appropriate, the request for admission to the candidate's group can be transmitted to the smart contract either directly by the candidate (the group is then said to be an 'open group'), or by a person responsible for verifying that there is indeed a reason to admit the candidate into the group, for example a group administrator.

[0059] Advantageously, following the member addition operation, each of the group members - that is, both the pre-addition members and the new member (the candidate) - has or is able to calculate the node secret key for any node in its chain of attachment.

[0060] The group members are authenticated in the registry by their account address, which is an authenticator, denoted accUser. This authenticator is used permanently to identify the member during their interactions with the smart contract.

[0061] Thus, thanks in particular to the use of smart contracts, the method proposed above makes it possible to create a group sharing a group secret key with a high degree of security, since only public information (public keys) is transmitted for the creation of the group secret key. In particular, the proposed method advantageously does not require the use of a central server.

[0062] In this document, the following definitions and conventions are used.

[0063] A ledger, also called a 'ledger', refers to a structure in which data is securely recorded, in the field of Distributed Ledger Technology. A ledger is generally distributed. A ledger can be open (or 'permissionless'), meaning that anyone can view the data recorded in the ledger. A typical example of a ledger is a blockchain, for example, of the Bitcoin or Ethereum type.

[0064] A smart contract is code designed to interact with a register and is stored in that register at an address specific to the smart contract. During mining, validator nodes execute the smart contract; if there is consensus on the result, it is recorded in the register.

[0065] The expressions 'a new key is calculated' or 'a new value for the key is calculated' have the same meaning and can be used interchangeably.

[0066] The blockchain has the advantage of being decentralized and does not have a single point of failure. Furthermore, the blockchain is robust against most denial-of-service attacks thanks to the use of gas, against man-in-the-middle attacks thanks to the use of account addresses as authentication, and against malware by making the contents of the ledger transparent and accessible to all actors.

[0067] Thus advantageously, the process according to the present disclosure meets the protocol requirements (update, upgrade, continuons access) through a high-performance, efficient and secure process.

[0068] In addition, the process according to this disclosure also takes into account the security requirements and protection of personal data and identifying data of members, through an innovative decentralized architecture based on the smart contract executed on a blockchain.

[0069] Naturally, an asymmetric cryptography crypto-system is defined over a commutative field.

[0070] In certain embodiments, the method further includes a procedure for removing a member of the group, called the leaving member (Up), other than the member who joined the group last, in order to remove the leaving member from the group, said member removal procedure comprising:

[0071] S100) a withdrawal request for the departing member is sent to the smart contract;

[0072] S110) the smart contract sends a key update message at least to each remaining active member of the group, indicating as key(s) to be renewed and as compromised key the secret key of each of said node(s) of the chain of attachment of the departing member;

[0073] S120) each remaining active member, called remaining considered member (U2), evaluates the node, called first common node, which is the node in its chain of attachment that is furthest from the root node and that also belongs to the chain of keys to be renewed;

[0074] S120-1) if the public key of the first common node has been renewed since the key update message, then, step by step, the remaining member under consideration calculates the secret key and the public key of the node under consideration, from the first common node up to the root node; conversely,

[0075] S120-2) if the public key of the first common node has not been renewed since the key update message:

[0076] S120-22) for each node, called the node to be updated, located on the chain of attachments going from the first common node to the root node, the remaining member under consideration calculates the secret key and the public key of the node to be updated, and publishes the latter in the register, the said node to be updated then being called the node updated; any node whose public key is compromised is considered non-existent during any node secret key calculation;

[0077] S120-24) the smart contract sends a node update message at least to each other active member of the group, that is to say at least to each active member of the group, other than the departing member and the remaining member considered, indicating the updated node;

[0078] S120-26) step by step, each other member calculates the node secret key of the node in question, for each updated node that is also part of its chain of attachment, in the direction from the terminal node of the tree to which it is attached towards the root node.

[0079] Thus, each remaining active member of the group has, or at least is able to calculate, a group secret key for all nodes in its chain of attachment. Advantageously, the new group secret key(s) recalculated as part of this withdrawal procedure are not accessible to the departing member.

[0080] For members who are inactive at the time the member withdrawal procedure is executed, the following procedure may be provided.

[0081] In a variant of the implementation described above, the group management method further includes a method for reconnecting a group member after the withdrawal of a departing member, in which:

[0082] S200) when a member of the group, called a reconnecting member, activates their connection to the group after a period of inactivity, the member reconnecting checks the messages received from the smart contract;

[0083] S210) when the reconnecting member has received a message from the smart contract Upon member withdrawal, the reconnecting member evaluates the node, called the first common node, which is the node in its attachment chain that is furthest from the root node and that also belongs to the key chain to be renewed:

[0084] S210-1) if the public key of the evaluated node has been published or renewed since the Key update message, step by step, the reconnecting member calculates the secret key and the public key of the node in question, starting from the first common node and going up to the root node; or vice versa,

[0085] S210-2) if the public key of the evaluated node has not been published or renewed since Member withdrawal message:

[0086] S210-22) for each node, called the node to be updated, located on the chain of The reconnecting member calculates the secret and public keys of the node to be updated and publishes the latter in the registry; the node to be updated is then called node updated; any node whose public key is compromised is considered non-existent in any node secret key calculation;

[0087] S210-24) the smart contract sends a node update message at least to each other member of the active group, that is, each active member of the group, other than the departing member and the reconnecting member, indicating the updated node;

[0088] S210-26) step by step, each other member calculates the node secret key of the node in question, for each updated node that is also part of its attachment chain (of the attachment chain of the reconnecting member), in the direction from the terminal node of the tree to which it is directly attached towards the root node (Ns).

[0089] Different calculation methods can be used to calculate new node secret keys by implementing the Diffie-Hellman protocol.

[0090] In some implementation modes, at least one node secret key of a given node is calculated:

[0091] - by calculating a cryptographic element called a shared secret node as a function of the secret key of a first child and the public key of a second child of the given node; and

[0092] - by calculating the secret key of the given node from said shared node secret, by example as being equal to a part of the node secret.

[0093] Thanks to the first step above, the process according to this disclosure more generally allows the calculation of a shared group secret, namely, in this case, the shared node secret of the root node. The procedures described in this disclosure allow group members to maintain a shared group secret over time, which is recalculated based, in particular, on the departures and additions of members.

[0094] In what follows, for simplicity, the 'shared node secret' is in some cases referred to more simply as 'node secret'.

[0095] In the first aspect of the invention described above, the group is tracked using a binary tree. The binary tree makes it possible to track the members of the group in a relatively simple manner, and in particular makes it possible to limit the number of key recalculations that are necessary when a member is removed.

[0096] An alternative solution to the invention will now be presented.

[0097] According to a second aspect of the invention, a second method for managing a group is proposed, in which the group is tracked using a linked list. Compared to tracking by a binary tree, this tracking method advantageously simplifies the implementation of the group management method. Conversely, advantageously, managing the group members using a binary tree according to the first aspect of The invention, compared to member management according to its second aspect, makes it possible to reduce the amount of gas consumed by sending transactions to the blockchain for group management (and therefore the management cost).

[0098] The second method, like the first method, combines the use of a smart contract and the sharing of keys by Diffie-Hellman protocol to allow the sharing of a shared secret within a group.

[0099] The second method is a method for managing a group comprising a plurality of members, each member holding or being able to hold a group secret key, the method using an asymmetric cryptosystem (Enc,Dec) verifying ownership, for two pairs of asymmetric keys (PKI,SKI) and (PK2,SK2):

[0100] Enc(PKl,SK2) = Enc(SKl,PK2), where Enc is the encryption function of the cryptosystem, and to a register in which a smart contract is deployed;

[0101] a list being used to order the members of the group;

[0102] the method comprising a procedure for adding a member to integrate into the group a candidate wishing to join the group,

[0103] at a given moment where

[0104] the group consists of a set of members, called pre-addition members,

[0105] each pre-addition member has or is able to compute a pre-addition secret key of the pre-addition group; and

[0106] a pre-addition public key of the pre-addition group is registered in the registry;

[0107] wherein the member addition procedure comprises the following operations:

[0108] S310) a request for admission to the candidate's group is transmitted to the smart contract, the application for admission including an authenticator and a personal public key of the candidate, the candidate also holding a personal private key from which his personal public key was calculated using the cryptosystem;

[0109] S320) the smart contract records in the register the admission into the group of a new group member with the candidate's authenticator and the candidate's public key;

[0110] S330) from the pre-addition public key of the pre-addition group and its private key personally the candidate calculates a new secret key value for the group and then a new public key value for the group;

[0111] S340) the candidate publishes in the register the new public key value of the group (PKgroup n+1) calculated at step S330;

[0112] S350) the smart contract sends a group key update message at least to each active member before adding the group; and

[0113] S360) upon receipt of the group key update message, from the key using the pre-add group secret and the candidate's personal public key, each active pre-add member calculates the new value of the group secret key.

[0114] By construction, the list of group members is ordered in chronological order of their admission dates or rather their dates of last admission to the group.

[0115] The positions or indexes in the group of group members can be indexed by an index followed by the smart contract.

[0116] In certain implementations of the group management method, at the latest shortly after a reconnection of a group member who had been inactive, or at the request of that member upon reconnection, once the member addition procedure has been executed, the smart contract sends a group key update message after the addition of a member to said inactive member; and the group management method further includes a method for reconnecting said inactive member after the addition of a member, in which:

[0117] S400) when said member, having been inactive, reconnects to the group, he consults the messages received from the smart contract;

[0118] S410) when the reconnecting member has received a message from the smart contract group key update after adding a member, from the pre-added group secret key and the candidate's personal public key, said member having been inactive, calculates the new value of the group secret key.

[0119] In certain embodiments, the method further includes a procedure for removing a member of the group, referred to as the departing member, other than the member who joined the group last, in order to remove the departing member from the group, said member removal procedure comprising:

[0120] S500) a withdrawal request for the departing member is sent to the smart contract;

[0121] S510) the smart contract identifies a member, called the initialization member, which is an active member of the group that joined the group before the departing member;

[0122] S520) The smart contract sends a new addition message to the group at each active member of the group who joined the group after the initial member, said member to be reintegrated, with the exception of the departing member, inviting the latter to rejoin the group;

[0123] S530) upon receipt of the message of new addition to the group, for each member to reintegrate (Up), steps S330 to S360 of the member addition procedure are carried out, considering the member to be reintegrated as the candidate.

[0124] In the event that the departing member is the last member to have joined the group, in certain implementation modes, the smart contract sends a message to each a member of the group, informing them that the group's previous secret key should be used as the new group key.

[0125] In some implementation modes, at least one new group secret key is calculated:

[0126] - by calculating a cryptographic element called a shared group secret as a function of a group member's secret key and a group's public key, or alternatively, based on a group member's public key and a group's secret key; and

[0127] - by calculating the new group secret key from said shared secret of group, for example as being equal to a part of the group's shared secret.

[0128] When the shared group secret is a vector, for example a coordinate vector of a point on a curve, in particular an elliptic curve, the group secret key may include or be a component of that vector.

[0129] In both the first and second aspects of the invention, in certain embodiments, when a new group public key is recorded in the register, the smart contract assigns a 'Blind' status to all remaining members other than the member, called the group update member, that triggered this recording; when a member other than the trigger member calculates the group secret key, it informs the smart contract; on this basis, the latter assigns a 'Online' status to said other member; and the method includes at least one procedure implemented using the smart contract, other than a procedure for adding or removing a member, in which at least one action of the smart contract is performed depending on the status of the member.

[0130] For example, the management process may provide that a member is not allowed to consult his previous messages via the smart contract if he is in Blind status.

[0131] Conversely, when this member later regains Online status, he will then be allowed to perform any action that he was allowed to perform during his period of inactivity, even if for a certain period the member was in 'Blind' mode.

[0132] In certain implementation modes, a specific procedure is provided for the recovery of messages exchanged during the intermediate period (in 'Blind' status).

[0133] In these implementation modes, the management process further includes a procedure for retroactively obtaining, by a member reconnecting after a period of inactivity, at least one group secret key, which had been a current key of the group during said period of inactivity, said retroactive obtaining procedure comprising the following steps:

[0134] S600) from information published in the register and / or by querying the smart contracted the reconnecting member determines an authenticator of a key-holding member from whom he can obtain said at least one secret key to obtain;

[0135] S610) The reconnecting member requests the key-holding member to provide said at least one secret key to obtain;

[0136] S620) the key-holding member verifies that the reconnecting member was member of the group at a time when said at least one secret key requested was the current secret key of the group, and that the reconnecting member is still part of the group.

[0137] S630) if the result of the verification is positive, the key-holding member considered opens a secure auxiliary communication channel with the reconnecting member, for example by following the protocol indicated by French patent application no. 1763394; and

[0138] S640) via the secure auxiliary communication channel thus opened, the member The key holder in question provides the reconnecting member with at least one secret key to obtain as requested.

[0139] In either the first or second aspect of the invention, advantageously the removal procedure can be implemented regardless of the order in which the members who must re-execute the member addition procedure perform this procedure. Furthermore, this procedure allows for the continuous operation of the group, which can occur even if some of the members who must re-execute the member addition procedure have not yet done so (for example, if their terminal is turned off).

[0140] In the first or second aspect of the invention, in certain embodiments, the group management method further includes a step in which at least one active member of the group calculates a symmetric group key from a secret group key.

[0141] This step allows the group members to have a symmetric key shared by all group members. Such a key allows the implementation of certain protocols, particularly communication protocols, in a more lightweight way than an asymmetric key such as the group secret key.

[0142] These protocols may include message encryption protocols such as AES.

[0143] The symmetric key can be calculated in different ways.

[0144] Thus, in certain implementation modes, to calculate said symmetric group key, said at least one active member of the group:

[0145] - calculates a cryptographic element called a shared group secret based on its a secret key and a group public key, or alternatively, a group member's public key and a group secret key; and

[0146] - calculates the symmetric key of the group from said shared group secret, by example as being equal to a part of the group secret.

[0147] By extension, according to a third aspect, the invention also relates to a method of encrypted communication within a group, comprising the following steps:

[0148] A. The group is formed by implementing any one of the group management processes presented above;

[0149] B. at least one member of the group calculates a symmetric group key from the group secret key; and

[0150] C. this member receives a message and decrypts it using the group symmetric key, or encrypts a message using the group symmetric key and sends it.

[0151] Thus, because each member of the group is able to calculate the group secret key and construct the symmetric key that is derived from it, each member of the group is able to read the messages exchanged within the group, decrypting them using the group symmetric key.

[0152] In some implementation modes, at step S50, the member constructs a group secret key (the secret key of the root node); then it calculates a pair of asymmetric group keys from a first part of the group secret, and a symmetric group key from a second part of the group secret.

[0153] The encryption or decryption of information is done using the symmetric group key.

[0154] When the crypto-system is based on an elliptic curve, one of the components (on x or respectively on y) can be used to construct the symmetric key, and the other component is used to compute the asymmetric key pair. BRIEF DESCRIPTION OF THE FIGURES

[0155] Other advantages, purposes and particular features of the present invention will become apparent from the following non-limiting description of at least one particular embodiment of the devices and methods of the present invention, with reference to the accompanying drawings, in which: • Fig. 1 is a schematic view of a group of people implementing a group secret sharing process as described in this disclosure; [Fig.2] is a schematic representation of a tree used to order the members of a group, when implementing a process according to the first aspect of this disclosure; [Fig.3] is a schematic representation of a tree used to order the members of the group, when executing a member addition procedure during the implementation of a process according to the first aspect of this disclosure; [Fig.4] is a schematic representation of a tree used to order group members, when performing a member removal procedure during the implementation of a process according to the first aspect of this disclosure; [Fig.5] is a schematic representation of a tree used to order the members of a group, when executing a member addition procedure during the implementation of a process according to the second aspect of this disclosure; [Fig.6] is a schematic representation of a tree used to order the members of a group, when performing a member removal procedure during the implementation of a process according to the second aspect of this disclosure; [Fig.7] is a flowchart showing the steps of a member addition procedure, in a group management process according to the first aspect of this disclosure; [Fig.8] is a flowchart showing the steps of a member withdrawal procedure, in a group management process according to the first aspect of this disclosure; [Fig.9] is a flowchart showing the steps of a reconnection procedure for a member who reconnects after a member has been removed from the group, in a group management process according to the first aspect of this disclosure; [Fig.10] is a flowchart showing the steps of a member addition procedure, in a group management process according to the second aspect of this disclosure; [Fig.1 1] is a flowchart showing the steps of a member withdrawal procedure, in a group management process according to the second aspect of this disclosure; Figure 12 is a flowchart showing the steps of a procedure for retroactively obtaining a secret key, in a group management process as disclosed herein; and • [Fig. 13] is a flowchart showing the steps of an encrypted communication process within a group, using a group management process as disclosed herein. DETAILED DESCRIPTION OF THE INVENTION

[0156] Non-limiting examples of group management processes and corresponding communication processes according to this disclosure will now be presented. GENERAL CHARACTERISTICS OF THE PROCESS

[0157] The group management processes described in this disclosure relate in particular to groups formed to be able to exchange messages, such as the one illustrated in [Fig. 1].

[0158] This figure shows a set of people {U1, U2, U3,... Un], each person being denoted U1 (i=1.. .n). These people constitute group G at the given time. A person Un+1, not a member of group G, seeks to join it. Each of these people, who may be a human or a machine, has (or includes) a terminal Ti (i=1.. .n). Each terminal is an electronic device capable of sending and receiving messages to other people via a network R, the internet for example, represented as a cloud in [Fig. 1]. Each terminal may be, for example, a mobile phone, a computer, etc. The person Un+1 also has such a terminal, Tn+1.

[0159] Each terminal includes at least one processor capable of running computer applications and a memory. The memory contains at least one communication application, which is used for exchanging messages with the terminals of other members of the group.

[0160] Although in some implementations the terminals can be configured to be permanently capable of exchanging messages, most often each terminal can be either in an 'active' or 'on' mode, in which it is able to exchange messages with the network, or in an 'inactive' or 'off' mode, in which it cannot exchange messages. The term 'message' includes any exchange of information, including terminal update information.

[0161] Group G is formed to enable the confidential exchange of messages. For this purpose, a cryptographic element called the shared group secret NPKGroupp is shared among group members. This shared group secret is recalculated during 'group update' operations when necessary, in accordance with the group management procedures as disclosed herein; with each group update, its index p is incremented. The shared group secret therefore varies over time, initially adopting an initial value NPKGroup i, then an NPKGroup 2 value, up to an NPKGroup plors value at the end of the p-th calculation of the shared group secret.

[0162] An asymmetric cryptosystem is chosen for the group to enable the sharing of the secret among the members of the group by implementing the processes according to this disclosure.

[0163] This cryptosystem may be an elliptic curve cryptosystem, using, for example, the parameters (p, a, b, G, n, and h). These parameters are public. Alternatively, the group's cryptosystem may also be an RSA cryptosystem; a cryptosystem including error-correcting codes; a post-quantum cryptosystem, particularly one based on lattices; etc.

[0164] A ledger, in this case a blockchain B, is used to ensure the recording and communication of certain information between the terminals Ti, in accordance with this disclosure. This ledger can be a public blockchain (accessible to everyone) or a private blockchain (access requires authentication and authorization).

[0165] The registry is implemented using servers, each server being a computer.

[0166] The group management processes according to this disclosure will now be presented. FIRST ASPECT

[0167] By way of example, an implementation method of processes according to the first aspect of this disclosure will now be presented in relation to Figs. 2 to 4.

[0168] In this implementation mode, a binary tree A is used for group management.

[0169] Figure 2 shows, as an example, a tree A which schematically represents a group G. As can be seen in this figure, at the time considered, the group G has 3 members: U1, Alice; U2, Bob; and U3, Charles.

[0170] Tree A varies over time according to the admission and departure of members, each admission or departure resulting in at least one update of the group. Each update of the group includes an update of the tree and the associated cryptographic variables.

[0171] In the tree A, each node is denoted Nj,k, where j is the level of the node in the tree, and k is the index of the node at the considered level j of the tree. The single node existing at the highest level s of the tree, denoted Ns,l or more simply Ns, constitutes the root node of the tree.

[0172] Since tree A is a binary tree, each node has zero, one, or two children. The terminal nodes are called 'leaves'; each leaf of the tree is associated with a member of the group.

[0173] In tree A, a shared node secret NPKj,k,p and an asymmetric node key pair comprising a secret key SKj,k,p and a public key PKj,k,p are associated with each node Nj,k; p being the current index (i.e., at the time considered) of the group secret.

[0174] The public key PKj,k,p can be calculated from the secret key SKj,k,n using the cryptosystem chosen for the group, in a manner known per se. The secret key SKs,l,p associated with the root node Ns is the group secret key SKgroupp.

[0175] In the implementation example presented here, the cryptosystem chosen for the group is an elliptic curve cryptosystem, using the parameters (p, a, b, G, n and h).

[0176] The secret key of node SKj,k,p is derived from the secret of node NPKj,k,p by a derivation function. Any suitable derivation function may be chosen; and in particular, any derivation function that generates the secret key of node SKj,k,p as a function of at least some part of the information contained in the secret of node NPKj,k,p.

[0177] The derivation function can simply be the identity function (the secret key of the node is then equal to the secret of the node).

[0178] The derivation function must naturally be held by anyone who has to calculate a new value of the secret key of the node.

[0179] In the embodiment presented here, for a node Nj,k ('parent node') having two children, the new value of the node secret and the new value SKj,k,p+l of the secret key of the node Nj,k are calculated as follows during an update of the index group p+1:

[0180] We assume that at the time of this update, the two children of the node Nj,k are the nodes Nj-l,kl-l and Nj-l,kl.

[0181] The new value for the node secret NPKj,k,p+l is calculated by a cipher function combining the public key of one of the children and the secret key of the other child. This function is any Enc cipher function of an asymmetric (Enc,Dec) cryptosystem that satisfies the property, for two pairs of asymmetric keys (PKI,SKI) and (PK2,SK2):

[0182] Enc(PKl,SK2) = Enc(SKl,PK2),

[0183] In the present case, the node secret can therefore be calculated indifferently by either of the following formulas:

[0184] NPKj,k,p+l = Enc (SKj-l,kl,p; PKj-l,kl,p) = SKj-l,kl,p • PKj-l,kl,p = Enc (PKj-l,kl,p; SKj-l,kl,p) = PKj-l,kl,p • SKj-l,kl,p

[0185] This property allows a person whose attachment chain contains one of the child nodes Nj-l,kl-l or Nj-l,kl, and who for this reason holds the secret key of this child node calculates a new value (of index p+1) of the shared secret of node for the parent node Nj,k.

[0186] Conventionally, the secret key SKj,k,p+l for the node Nj,k, is deduced from the node's shared secret as being equal to the x-component of NPKj-l,kl,p:

[0187] SKj,k,p+l = NPKj,k,p(x).

[0188] The corresponding public key of node N2,1 is obtained from the secret key SK2,1,2 by the formula: PK2,1,2 = SK2,1,2 • G.

[0189] In this equation:

[0190] - the operator indicates the multiplication operation in the space of curves elliptic curves, which can be implemented by repeated addition the number of times indicated by the scalar. Therefore, the public key PK2,1,2 indicated by the multiplication operation above is equal to (((G + G) + G) + ... + G), the addition is repeated SK2,1,2 times, the addition operation '+' being defined in the space of elliptic curves; and

[0191] - G is the generating point on the considered elliptic curve, which allows generating all points of the elliptic curve in the discretized space.

[0192] The y component of NPK2,1,2 is then chosen as the symmetric key EncK2 for message exchanges in the group G2: EncK2 = NPK2,l,2(y).

[0193] The above procedure allows the cryptographic elements of a parent node Nj,k to be calculated from the secret key of one of the child nodes Nj-l,kl-l or Nj-l,kl, the public key of the other child node being available on the register, for any node Nj,k having two children.

[0194] Other functions can be chosen to derive a secret key of the parent node from the secret key of one of the child nodes and the public key of the other child node. In general, any function usable (or used) for the implementation of the Diffie-Hellman protocol can be used to perform this function.

[0195] Conversely, if a parent node Nj,ka has only one child Nj-l,kl, the secret key SKj,j,p+l of the node Nj,k is calculated during an update based on the only secret key of its child SKj-l,kl,p+l, for example by being equal to this: SKj,k,p+l = SKj-l,kl,p+l.

[0196] Advantageously this procedure can be repeated by a member of the group step by step to successively calculate the cryptographic elements, and in particular the secret keys, of all the nodes of its chain of attachment, in the direction going from the terminal node associated with the member to the root node.

[0197] In the asymmetric key pairs associated with the different nodes, the public keys are stored in the registry and are therefore freely accessible (at least for members with access to the registry). Conversely, as will be detailed below, for each node, only the member(s) whose chain of attachment contains the node have or have the means to reconstruct the node's secret key. Adding members

[0198] The procedures for admitting new members into Group G according to the management process will now be presented within the framework of the first phases of the constitution of Group G.

[0199] Generally, admitting a new member to the group triggers a member addition procedure, and optionally, one or more reconnection procedures. The member addition procedure updates the group and thus recalculates the group secret. The reconnection procedure therefore allows, where applicable, group members who were inactive when the member addition procedure was executed to obtain the new group secret and thus rejoin the group.

[0200] During an initialization phase (p=l), the first member U1 of the group, Alice, creates the group G by deploying a smart contract SC in the register B. Alice therefore becomes the administrator of the group.

[0201] Using the cryptosystem, Alice generates her personal asymmetric key pair, denoted SKAlice / PKAlice. Alice registers her public key PKAlice in the ledger and is registered by the smart contract as having the status 'Online'.

[0202] This recording can be made in different ways.

[0203] If the ledger is a Bitcoin-type blockchain, an ephemeral public key can be recorded in the blockchain using the OP_s script of the Bitcoin protocol. Such use of this script can be implemented by drawing inspiration from French patent application no. 1763393. Since the content of the blockchain is accessible to members of the group, each of them accesses the public keys thus deposited based on knowledge of their account address, which proves ownership of the key.

[0204] If the ledger is an Ethereum-type blockchain, the ephemeral public key can be stored in the blockchain using a smart contract. Such an implementation can be achieved by drawing inspiration from French patent application no. 1763394.

[0205] Alice's secret key constitutes the group secret of index p=l:

[0206] SK^pi= SKAlice.

[0207] In a second phase, Bob joins the group as the second U2 member, resulting in an update of the group (p=2).

[0208] Using the crypto-system, Bob generates his personal asymmetric key pair, denoted SKBob / PKBob.

[0209] The public keys PKAlice and PKBob are respectively derived from the secret keys SKAlice and SKBob, by the following formulas:

[0210] PKAlice = SKAlice • G and PKBob = SKBob • G

[0211] where G is the generating point of the elliptic curve crypto-system represented by the parameters (p, a, b, G, n and h).

[0212] Bob also has an accuU2 authenticator which allows him to authenticate himself with the SC smart contract.

[0213] The member addition procedure is executed to allow Bob's admission:

[0214] At step S10, Bob transmits his request for admission to the group to the smart contract SC by attaching his authenticator accuU2 and his public key PKBob to his request.

[0215] At step S20, the smart contract records in the register the admission into group G of a new member having the authenticator accuU2 and the public key PKBob

[0216] In view of the information contained in the register, Bob then determines (step S30) that his attachment chain in the tree A contains only the root node N2,l.

[0217] At step S40, Bob calculates the node secret key for this node from his personal private key SKBob and Alice's public key PKAlice: Bob calculates the node secret, NPK2,1,2: NPK2,1,2 = SKBob • PKAiice - He then deduces the secret key SK2,1,2 for node N2,l, which is the component on x of NPK2,1,2 : SK2,1,2 = SKgroup2 = NPK2,l,2(x). - He then calculates the public key PK2,1,2 from the secret key SK2,1,2: PK2,1,2 = SK2,1,2 • G. - He then deduces the current symmetric key EncK2 for message exchanges in group G, which is the component on y of NPK2,1,2: EncK2 = NPK2,l,2(y).

[0218] At step S50, Bob publishes the group public key PK2,1,2 that he has just calculated in the registry. Bob has the status 'Online', while Alice is placed in the status 'Blind'.

[0219] At step S60 the smart contract sends Alice a group key update message.

[0220] At step S70, upon receiving this message, Alice determines the secret key(s) of the node that she must recalculate: these are the secret keys of the nodes common to her chain of attachment and to the continuation of Bob's attachment, that is to say the node N2,l.

[0221] Alice then calculates the secret key of node N2,1 in turn, following the procedure described earlier. Thanks to the commutativity property of elliptic curve cryptosystems, she obtains the same value for the secret key SK2,1,2 as that calculated by Bob. She informs the smart contract and is placed back in 'Online' status.

[0222] It also calculates the symmetric group communication key, EncK2, by the formula: EncK2 = NPK2,l,2(y).

[0223] Alice and Bob then exchange messages using the EncK2 symmetric communication key as the encryption key for the messages they exchange.

[0224] These messages can be encrypted by any known symmetric encryption algorithm such as AES.

[0225] In a third phase, Charles joins the group as the third member of U3.

[0226] It is added at level 1 to node NI,3. A node N2,2 and a new root node N3,l (or N3) are created so that Charles can have a chain of attachments extending to the root node. Node N2,l is the first child of root node N3, and node N2,2 is its second child.

[0227] Charles's attachment chain includes nodes N2,2 and N3.

[0228] The member addition procedure described above is then executed for to allow Charles to be admitted into group G.

[0229] The procedure for adding a member to group G will now be presented more generally in the example illustrated by [Fig.3].

[0230] This procedure will be illustrated at a point in time when the group is the group G presented previously, at an update index p.

[0231] At the moment considered, the group G comprises six members Ui, i=l.. .6 called Alice, Bob, Charles, Dave, Esther and Fabien, integrated into the tree A.

[0232] A U7 candidate, Greg, wants to join the group.

[0233] To enable him to become a member of the group, the member addition procedure is executed for Greg.

[0234] Members are added to tree A according to the rules for constructing tree A. Any appropriate set of rules can be chosen for constructing the tree. This set of rules is chosen so that each member of the group can, at any time, access the register to know the tree's structure. This set of rules can be public: each member of the group can, at any time, access the register to know the tree's structure. Alternatively, it can be private. In this case, it is known at least to the smart contract: the smart contract then informs the members of their chain of attachment and, where applicable, any other information they need regarding the tree's structure.

[0235] The admission of a new member, as will be detailed, sometimes results in the addition of an extra level in the tree, and / or the addition of one or more new node(s), and in all cases the addition of a new leaf corresponding to the new member. At the time considered, tree A6 contains the 6

[0236]

[0237]

[0238]

[0239]

[0240]

[0241]

[0242] members U1-U6, and 14 corresponding nodes referenced Nl,l ; NI,2 ; NI,13 ; NI,14 ; N2,l ; N2,2 ; N2,7 ; N3,l ; N3,4 ; N4,l ; N4,2 ; N5. In this case, the group's formation rules include a rule against replacing departing members in the tree, and consequently, the tree is incomplete. Thus, some nodes, such as N3,2 and N4,2, have only one child or are even missing, because the group members attached to these nodes have left the group. The rules for constructing the tree also require that each of the members (U1-U6) of the group must necessarily be attached to a level 1 node (However, in other embodiments members can be attached to higher level nodes. For example, the new member could be attached to node N4,1). Due to this rule, the new member U7 is added to the tree at level 1, in the index position immediately higher than that of the last admitted member, U6, still present in the group. Since tree A at the time of the current update (index p) did not contain a node N2,8, node N2,8 is created. Member U7 is therefore added to a node NI,15. Thanks to the creation of node N2,8, it now has a complete chain of attachments consisting of nodes N2,8, N3,4, N4,2, and N5. Each member of the U1-U6 family has an asymmetric key pair consisting of an ESKi secret key and an EPKi public key derived from the ESKi secret key using the asymmetric cryptosystem, specifically the key pairs SKAiice / PKAiice, SKBob / PKBob, SKcharies / PKcharies, SKf)ave / PK£)ave, SKBstber / PKBstber, and SKBabien / PKBabien, respectively. Greg also has such a key pair, SKGreg / PKGreg. At the moment Greg initiates the procedure to add a member to be admitted to group G (as at any time), each active member of the group possesses the secret key of node SKj,k,p for each of the nodes Nj,k in their chain of attachment. Furthermore, for each node Nj,k in tree A, a public key of node PKj,k,p is recorded in the registry. The addition of new U7 member Greg to the group entails the following operations: In step S10, Greg sends his request to join the group to the smart contract, attaching his accU7 authenticator and his personal public key PKGreg. In this embodiment, he sends this request directly to the smart contract. In other embodiments, he could send his request to a group administrator, who would then, after performing appropriate checks, forward the request to the smart contract.

[0243] At step S20 the smart contract records in the register the admission into group G of the new member U7 having as authenticator accGreg and as public key PKGreg.

[0244] At step S30 Greg determines the list of nodes of his chain of attachment in the tree, namely the list N2,8; N3,4; N4,2; N5.

[0245] In step S40, step by step, Greg calculates the node secret key and then the node public key for each node in his chain, from the node in the tree to which it is directly attached up to the root node N5. As seen previously, in the embodiment presented here this calculation is indirect: to calculate the secret key at index p+1 of a node Nj,k with two children, Greg first calculates the node secret NPKj,k,p+l, then derives from it the node secret SKj,k,p+l, and then the node public key PKj,k,p+l. Conversely, if a node in the chain has only one child (like node N2,8), then the node secret, the public key, and the node secret assigned to this node are equal to the corresponding cryptographic elements of the child. Thus, in particular, SK2,8,p+l = SKGreg.

[0246] At step S50, Greg publishes in the registry the public keys of nodes N2,8; N3,4; N4,2 and N5 calculated at step S50. All the public keys of tree A are therefore updated.

[0247] However, in order to allow all members of the group to exchange messages, their keys must then be updated.

[0248] For this purpose, at step S60 the smart contract sends a group key update message to each member before adding the group.

[0249] At step S70, upon receiving the group key update message, each active pre-addition member of the group—that is, each active member among members U1-U6—calculates the node secret key for each node in its attachment chain that is also part of Greg's attachment chain, proceeding from the node in the tree to which it is directly attached towards the root node N5 (ascending direction in [Fig. 3]). It performs calculations similar to those executed by Greg at step S40.

[0250] Each active member of the group then calculates the symmetric group communication key EncKp+1, at step S80.

[0251] Consequently, each active member of the group is then able to send and / or receive messages under symmetric encryption using this key with the other active members of the group. Procedure for reconnecting inactive members

[0252] If a group member is inactive when the member addition procedure is executed, they cannot perform step S70 at that time. Therefore, at When he reconnects (typically by turning on his Ti terminal), because the group secret and private keys have been recalculated, he does not have these keys and cannot exchange messages with other group members.

[0253] To remedy this situation, it executes the following reconnection procedure. When the group member (and therefore, when each group member) reconnects, it checks its messages. If it has received a member addition message, it then executes steps S70 and S80, which allows it to obtain the updated secret keys for all nodes in its chain of attachment, as well as the group symmetric key EncKp+1, which then allows it to exchange messages with the other group members. Member withdrawal

[0254] When a member of the group (called the 'departing member') leaves the group G (at an update index p), a member removal procedure is executed to ensure that after the member's departure, they no longer possess the symmetric secret key EncKp used for encrypting messages in the group and, consequently, can no longer access the messages exchanged by the group. More generally, the removal procedure aims to renew the group secret key SKgroupp, so that the departing member can no longer access confidential information relating to the group.

[0255] To renew this secret key, it will be necessary to recalculate the node secret key for each of the nodes in the chain of attachment of the departing member.

[0256] To this end, the withdrawal procedure includes carrying out the following operations when the withdrawal of the departing member is decided:

[0257] We take as an example the case where Charles (member U3 of the group), leaves the group G whose tree A is represented in [Fig.4]. Charles's attachment chain CR3 has the nodes N2,2; N3,1; N4,1; N5.

[0258] The steps of the member removal procedure are shown in [Fig.8]. [Fig.4] shows tree A at the time of execution of the removal procedure following Charles' departure.

[0259] At step S100, Charles, either directly or possibly through Alice, the group administrator, sends a withdrawal request to the smart contract.

[0260] At SI step 10, the smart contract sends a key update message to each remaining member of the group, indicating as the key(s) to be renewed and as the compromised key the secret key of each of the nodes in the chain of attachment of the departing member Charles (U3). Upon receiving this message, each member of the group considers the public key of each of the nodes in the CR3 chain of attachment of Charles to be compromised.

[0261] At step S120, each remaining active member evaluates the node, called the first common node, which is the node in its chain of attachment that is furthest from the root node and that also belongs to the chain of keys to be renewed.

[0262] It is assumed that the first remaining member considered that performs this procedure is Bob (U2). Bob's CR2 attachment chain has nodes N2,1; N3,1; N4,1; N5.

[0263] The first common node is therefore the N3,1 node.

[0264] At this point, the public key of the first common node, N3,l, has not been recalculated since the key update message: it is therefore a compromised key. Bob deduces that he must execute step S120-2, composed of steps S120-22, S120-24 and S120-26: He must recalculate the public keys of node N3,l as well as all higher nodes in its CR2 chain (i.e. nodes N4,l and N5).

[0265] Thus, in step S120-2, for each of the nodes (called 'updated nodes') N3,l, N4,l, and N5, Bob (the remaining member considered) calculates the node's shared secret, deduces the node's public key and private key, and publishes the public key in the ledger. During the calculation for node N3,l, since the key N2,2 is compromised, node N2,2 is considered nonexistent when calculating the shared secret of node NPK3,l,p+l. In other words, node N3,l is considered for this calculation as a node with only one child (node ​​N2,l). The private key of node N3,l is therefore calculated based solely on the private key held by Bob for node N2,l. No information from the compromised public key of node N2,2 is used.

[0266] The secret keys of nodes N4, N1, and N5 are then calculated. Therefore:

[0267] SK4,l,p+l = SK3,l,p+l = SK2,l,p+l

[0268] The NPK5 node key is calculated based on SK4,1 and PK4,2 (the right branch of the tree does not have a compromised key).

[0269] The public keys PK3,l,p+l, PK4,l,p+l and P5,p+1 are published in the registry.

[0270] As public keys PK3,1; PK4,1 and PK5 were recalculated, at the step S120-24 The smart contract then sends a key update message to each other member of the group (other than the departing member (Charles) and other than the remaining member (Bob)), indicating as keys to be renewed at least the key of each of the updated nodes that are also part of the chain of said other member. This message is therefore sent to Alice, Dave, Fabien, and Greg (Esther being absent), who are thus the 'other members'. For example, for Fabien and Greg, the message may simply indicate that the PK5 public key has been recalculated.

[0271] Upon receiving the message sent in step S120-26, each other active member calculates the node secret key for each node in its chain, which is also an updated node, in the direction from the node of the tree to which it is directly attached towards the root node.

[0272] It is assumed that Dave is the second member of the group who reacts to receiving the key update message sent at stage S110.

[0273] Dave responds to the messages issued in steps SI 10 and S120-26 by performing the following steps:

[0274] For Dave, the first common node (i.e. the lowest node in his chain of attachment of which a key is indicated in the message issued at SI step 10 as a key to be renewed and as a compromised key) is node N2,2.

[0275] At step S120, Dave (as the remaining member considered) evaluates this first common node N2,2.

[0276] The public key of node N2,2 has not been renewed since the message sent at SI step 10.

[0277] Dave must therefore perform step S120-2.

[0278] The so-called 'updated nodes' are nodes N2,2; N3,l; N4,l; N5.

[0279] Since node NI,3 has been deleted (due to Charles' departure), the public keys and secret of the NPK2,2,p+l node are equal respectively to the public key and secret key of Dave PKDave and SKDave.

[0280] At step S120-22, Dave therefore calculates, step by step, the shared secrets of the node and the secret and public keys of the node successively for the nodes N3,l; N4,l; N5.

[0281] At step S120-24, the smart contract sends a key update message to at least each other active member of the group, indicating as keys to be renewed the secret key of each of the said updated nodes, therefore the keys of nodes N2,2; N3,l; N4,l; N5.

[0282] At step S120-26, each of the other members, if applicable, updates its keys along its chain of attachment.

[0283] Thus in particular, Bob must again recalculate the secret and public keys for the nodes of his chain of attachment whose secret and public keys have been recalculated: he therefore recalculates the keys for nodes N3,l; N4,l and N5.

[0284] The other active members of the group, Alice, Fabien and Greg, then also recalculate the secret and public keys for the nodes of their respective attachment chains whose secret and public keys have been recalculated.

[0285] In the case of Fabien or Greg, this calculation simply consists of recalculating the shared node secret, then the secret and public keys, for node N5.

[0286] Alice, for her part, received the message issued at step SI 10, indicating as keys to be renewed and as compromised key the secret key of each of the nodes N2,2; N3,l; N4,l; N5.

[0287] During steps S120-24 initiated by Bob and Dave, it received node update messages indicating that the updated nodes were respectively N3,l; N4,l and N5, then N2,2; N3,l; N4,l and N5.

[0288] For Alice, the first common node (between her linking chain and that of the departing member Bob) is the node N3,l. Alice determines that the public key of this node has been recalculated since the message sent in step SI 10. Alice therefore executes step S120-1.

[0289] At step S120-1, for each node in its chain, from the first common node N3,l to the root node N5, Alice (as the remaining member considered) calculates the shared secret of the node in question, and deduces from it the public key and the node secret key of the node in question. It thus recalculates the cryptographic elements for nodes N3,l; N4,l; N5. Using the secret key of node N5, it calculates the current value of the symmetric group communication key EncKg,.OUp

[0290] These operations enable Alice to exchange messages with the rest of the group.

[0291] The procedure for reconnecting a member who was inactive at the time of the withdrawal of the departing member (Charles) is illustrated by [Fig.9], in the case of the reconnection of Esther.

[0292] Later, Esther activates her terminal in order to reconnect to the group.

[0293] Esther then receives the messages sent at stage SI 10 and at the various stages S120-24. In the context of the departure of member U3, Charles, the first common node is node N5.

[0294] At step S200, when Esther (as 'reconnecting member') activates her connection to the group, she checks the messages received from the smart contract.

[0295] At step S210, since she has received the withdrawal message from the smart contract from Charles, step by step, Esther evaluates the node(s) of her attachment chain which also belong to the attachment chain of the departing member, that is to say in this case the node N5.

[0296] At step S210, Esther evaluates the state of this first common node N5: she determines that the public key of this node has been renewed since the message sent at step SI 10.

[0297] Esther then executes step S210-1: she calculates the shared group secret for node N5, and deduces the secret key and then the public key for node N5. She finally deduces the symmetric communication key of the EncCKgroup.

[0298] Conversely, if for one or more evaluated nodes, Esther finds that the public key of that node has not been renewed since the message sent in step SI 10, Esther would carry out the steps S210-22, S210-24 and S210-26 indicated previously, which are analogous to the steps of step S120-2.

[0299] According to one variant, if the procedure for removing a member is executed during a period in which one of the group members is inactive, the following reconnection procedure is followed when that member reconnects:

[0300] The procedure for adding a member to the group is carried out for the member in question as if they were joining the group for the first time. However, appropriate arrangements are preferably made to ensure that the member in question retains a history of their interactions with the group.

[0301] Access to messages exchanged during a period of inactivity

[0302] When a member is inactive during the addition of a new member to the group or the removal of a member from the group, due to the renewal of the group secret key, the inactive member cannot have access to the messages that are exchanged within the group from the change of the group secret key following the departure or addition of a member.

[0303] When the member reconnects, as explained previously, he calculates the new secret key of the group and therefore the group communication key which is derived from it: this then gives him access to the new messages exchanged within the group.

[0304] However, this does not give him access to messages that were exchanged between the addition or removal of the member from the group and the time of his reconnection to the group.

[0305] To allow this member, referred to as the reconnecting member, to have access to these messages, the following procedure, referred to as the access procedure, can be executed.

[0306] We take as an example the case of the reconnection of member U5, Esther, who was disconnected at the time when the removal procedure of member U3, Charles, was executed.

[0307] As indicated, at step S120 each of the remaining active members of the group carried out their update procedure.

[0308] Later, at the time of her reconnection, member U5, Esther, performed the reconnection procedure described above to obtain the new root node secret key and the new group communication key.

[0309] In addition, the access procedure described below will allow Esther to have access to the messages exchanged during the member removal procedure until she has executed the reconnection procedure.

[0310] This access procedure comprises the following steps, illustrated by [Fig. 12]:

[0311] At step S600, from the information published in the register concerning additions or removals of members and / or publications of public keys, and / or by querying the smart contract, Esther (as 'member reconnecting') determines the authenticator(s) of one or more members ('key-holding members') from whom she can obtain the temporary secret key(s) which has / were used during her period of inactivity following the withdrawal of the departing member.

[0312] It then obtains the missing group secret key(s) by contacting the identified key holder(s) member(s) via a secure communication channel.

[0313] When it contacts a key-holding member, it proceeds as follows:

[0314] At step S610, she (as a reconnecting member) asks the key-holding member to provide her with one or more secret keys that he has and that the reconnecting member would like to obtain.

[0315] At step S620, to respond to this request, the key-holding member verifies the legitimacy of the request from the reconnecting member.

[0316] Based on information published in the register concerning additions or removals of members and / or publications of public keys, and / or by querying the smart contract, it verifies in particular: - that the reconnecting member was authorized to access the requested secret key(s), because they were indeed a member of the group at a time when the requested secret key(s) was / were the current secret key(s) of the group; and - that the member reconnecting is still part of the group.

[0317] At step S630, if the key-holding member in question has concluded at the end of step S620 that the reconnection request is legitimate, it opens a secure auxiliary communication channel with the reconnecting member. Any appropriate security method may be chosen for this communication channel. This secure communication channel may be opened, for example, by performing a key exchange according to the Diffie-Hellmann protocol, following the protocol indicated by French patent application no. 1763394.

[0318] At step S640, via the secure auxiliary communication channel thus opened, the member holding the key in question then provides the reconnecting member with the requested secret key(s).

[0319] Upon receipt of this key(s), it is then able to take note of the messages exchanged during the period in which this key or these keys were the current key(s) of the group. SECOND ASPECT

[0320] By way of example, an implementation method of processes according to the second aspect of this disclosure will now be presented in relation in particular to Figs. 5 and 6.

[0321] In this implementation mode, the Ui members of the group are managed not using a binary tree, but using a linked list, that is to say a sequence of consecutive elements.

[0322] The general characteristics of the method described above can also be implemented in the case of group management by a linked list.

[0323] As before, the group secret key that the management process allows all members of the group to hold in a shared manner is used by each to calculate a symmetric communication key for the group, EncKp (at index p of the group), which is calculated from the group secret key SK^pp.

[0324] The EncK key is used by each member of the group to encrypt and decrypt messages exchanged with other members of the group.

[0325] In this embodiment, a linked list L is used for group management.

[0326] Figure 5 shows, as an example, a list L which schematically represents a group G. As can be seen in this figure, at the time considered, the group G has 4 members: U1, Alice; U2, Bob; U3, Charles and U4, Dave.

[0327] The list L varies over time according to the admission and departure of members, each admission or departure resulting in at least one update of the group. Each update of the group includes an update of the list L and the associated cryptographic variables.

[0328] In the list L, an asymmetric group key pair comprising a secret key SKgroupp and a public key PK^pp is generated and associated with the group G at the pth update; p is called the current index (i.e., at the time considered) of this asymmetric group key pair.

[0329] The group public key PK^pp can be calculated from the secret key SK^pp using the cryptosystem chosen for the group, in a manner known per se.

[0330] Each PK^uppest group public key is registered in the registry and is therefore freely accessible (at least for members with access to the registry).

[0331] In the implementation example presented here, the cryptosystem chosen for the group is an elliptic curve cryptosystem, using the parameters (p, a, b, G, n and h).

[0332] It is therefore a cryptosystem of the same type as that presented in the first implementation. Consequently, unless otherwise specified, the key calculation operations are performed for the second implementation in the same way as for the first implementation.

[0333] In particular, in this implementation mode, the calculation of new group secret and public keys is done indirectly:

[0334]

[0335]

[0336]

[0337]

[0338]

[0339]

[0340]

[0341]

[0342]

[0343]

[0344]

[0345]

[0346]

[0347]

[0348] Initially, a new shared group secret (index p+1) NPKg,.OUp p+i is calculated using a encryption function combining: - the public key of a new group member and the group secret key of the previous index (p); or - the secret key of the new group member and the public key of the previous index group (p). The Enc encryption function of the asymmetric cryptosystem (Enc,Dec) must verify the same property as that defined in the first implementation mode. The new group secret key SKg,.oup p +[ is derived from the shared group secret NPKgroupp+i by any suitable derivation function. The new group secret key SKg,.OUp p+i can thus be deduced from the shared group secret as being equal to the x-component of NPKgroupp+i: SKgroupp+1 NPKgroupp+iCx) Furthermore, the new group public key PK^upp+i is obtained from the secret key SKgroupp+i by the formula: PKgroupp+i = SKgj-QHp p+i • G. The derivation function must naturally be held by anyone who has to calculate a new value of the group secret key. The symmetric group key used to enable message exchange between group members is then calculated as being equal to the second component (the y component) of the shared group secret. It is therefore given by the equation: encKgroup p+i = NPKg^pp+^y). Adding a member The procedures for admitting new members into Group G according to the management process will now be presented as an example at the time shown in [Fig. 5], where a candidate, Esther, joins Group G. The steps of the procedure are illustrated in [Fig. 10]. In this initial situation, called 'before addition', each of the members of the group (Alice, Bob, Charles, Dave) holds the secret group key SKgroup 4 (we assume that there has been no removal of members since the creation of the group, so the index of the group is p=4). The pre-addition public key (PKg,.OUp 4) of the pre-addition group is recorded in the registry. The procedure for adding Esther to the group includes the following steps: Previously, Esther acquired an asymmetric key pair comprising a personal secret key (SKEsther) from which her personal public key (PKEsther) was calculated using the group's cryptosystem.

[0349] Moreover, at the moment the member addition procedure is executed, Alice, Bob and Dave are active but conversely, Charles is inactive.

[0350] At stage S310, Esther submits her application for admission to the group administrator, Alice.

[0351] Alice checks that Esther meets the admission requirements for the group. In this case, she concludes that these requirements are met and transmits the admission request to the smart contract, attaching Esther's authenticator (accEsther) and personal public key (PKEsther).

[0352] At step S320, the smart contract registers Esther in the registry as a new member of the group, notably registering her authenticator accEsther and her public key PKEsther.

[0353] At step S330, from the pre-addition public key (PKg,.OUp 4) of the pre-addition group and her personal private key (SKEsther), the candidate, Esther, calculates a new secret key value of the group (SKgroup 5) and then a new public key value of the group (PKgroup 5) for group G.

[0354] At step S340, Esther publishes in the registry the new public key value of the group (PKgroup5) calculated at step S330.

[0355] At step S350, the smart contract sends a group key update message, in this embodiment, to all active members prior to adding the group, namely Alice, Bob and Dave.

[0356] At step S360, upon receipt of this message, from the pre-addition secret key (SKgroup 4) of the pre-addition group and Esther's personal public key PKEsther, each of them calculates the new secret key value of the group SKgroUp 5 by applying the formula given above, and thus: SKgroup 5= SKgroup 4 • PKEsther.

[0357] At step S370, each of them then further calculates the symmetric communication key of the EncK5 group, which allows it to continue exchanging messages with the group, now including Esther.

[0358] Thus, by construction, the list of members of the group is the list ordered in chronological order of their dates of admission or rather of their dates of last admission into the group.

[0359] In some implementation modes, the positions in the group of the group members are indexed by an index and are tracked by the smart contract.

[0360] Procedure for reconnecting inactive members following the addition of a member

[0361] A little later, Charles (as an example of a member who had been inactive) reconnects to the group.

[0362] The smart contract detects this reconnection (or Charles sends the smart contract a message signaling his reconnection) and sends Charles a group key update message.

[0363] (According to one variant, at step S350 the group key update message is sent to all members before the group is added, whether they are active or not).

[0364] Charles executes the reconnection procedure by performing the following operations:

[0365] At step S400, Charles checks the messages received from the smart contract. He notes so the smart contract sent him a group key update message.

[0366] At step S410, because of this message, from the pre-addition secret key (SK^p 4) of the pre-addition group, which he holds, and Esther's personal public key (PKEsther), Charles in turn calculates the new secret key value of the group (SKgroup 5).

[0367] It then calculates the symmetric communication key of the EncK5 group, which allows it to exchange messages with the group again. Member withdrawal

[0368] When a member of the group (called the 'departing member') leaves the group G (at an update index p), a member removal procedure is executed to ensure that after the member's departure, they no longer possess the symmetric secret key EncKgrou pp used for encrypting messages in the group and, consequently, can no longer access the messages exchanged by the group. More generally, the removal procedure aims to renew the group secret key SKgroupp, so that the departing member can no longer access confidential information relating to the group.

[0369] The following withdrawal procedure is therefore executed when the withdrawal of a departing member is decided:

[0370] We take as an example the case where Charles (member U3 of the group), leaves the group G whose tree A is represented on the [Fig.6].

[0371] Figure 6 represents tree A at the time of execution of the withdrawal procedure following Charles' departure. The steps of the procedure are illustrated by Figure 11.

[0372] At step S500, Charles, or possibly Alice the group administrator, sends the smart contract a request to withdraw the departing member, Charles.

[0373] At step S510, the smart contract identifies a Uini member, called the initialization member, which is an active member of the group who joined the group before the departing member, Charles. In the example presented here, Bob is identified as the Uini initialization member.

[0374] At step S520, the smart contract sends a new addition message to each group member who joined the group after the initial member (Bob), except for Charles of course, inviting him to join the group again.

[0375] Each of the members to whom these messages are sent is referred to as a 'member to be reinstated'; the main steps of the member addition procedure will have to be executed for the member to be reinstated in order to allow the group secret key to be updated.

[0376] Therefore, at step S530, for each member to be reinstated (Up), steps S330 to S360 of the member addition procedure are carried out, considering the member to be reinstated as the candidate.

[0377] Once these steps have been carried out, each member to be reintegrated then calculates, from the new group secret key, the symmetric communication key of the group, EncK^p p+j.

[0378] By recalculating the group's secret key successively, starting from the initial member, for each member to be rejoined, a new secret key value for the group is progressively calculated. This value is shared among all active members of the group, but is not known to the member who withdrew.

[0379] Procedure for reconnecting inactive members following the withdrawal of a member

[0380] As can be seen in [Fig. 6], at the time of the withdrawal procedure, Dave is inactive.

[0381] A little later, Dave (as an example of a member who had been inactive) reconnects to the group.

[0382] The smart contract detects this reconnection (or Dave sends the smart contract a message signaling his reconnection) and sends Dave a message of new addition to the group (According to a variant, at step S420 the message of new addition to the group can be sent to all members of the group (except the member who withdraws)).

[0383] Dave performs the reconnection procedure by carrying out the following operations:

[0384] Dave checks the messages received from the smart contract. He therefore notes that the smart contract sent him a message about a new addition to the group.

[0385] Therefore, in the next step, steps S330 to S360 of the member addition procedure are carried out, considering Charles (as a member to be reinstated) as the candidate.

[0386] Once these steps have been carried out, Charles then calculates the symmetric communication key of the group, EncKgroup p+i, from the new group secret key.

[0387] Furthermore, if Dave wishes to access messages that were exchanged within the group during his period of inactivity, he can execute the secret key retrieval procedure described earlier for the first implementation mode. This will allow him This allows the group's secret keys to be obtained, which were the group's current secret keys during its period of inactivity. From these secret keys, the group's communication keys can be calculated during that same period, and thus the encrypted messages exchanged during that time can be decrypted.

[0388] An example of the implementation of group management processes according to this disclosure is illustrated by [Fig. 13].

[0389] This figure presents a method of encrypted communication within a group, comprising the following steps:

[0390] A. The group is formed by implementing one of the group management processes presented previously.

[0391] B. At least one member of the group calculates a symmetric group key from the group secret key.

[0392] C. Then, this member receives a message and decrypts it using the group symmetric key, or encrypts a message using the group symmetric key and sends it.

Claims

1. Demands Method for managing a group comprising a plurality of members (Ui... One), each member (U;) holding or being able to hold a group secret key (SKj,k,p), the method using an asymmetric cryptosystem (Enc,Dec) verifying ownership, for two pairs of asymmetric keys (PKI,SKI) and (PK2,SK2): Enc(PKl,SK2) = Enc(SKl,PK2), where Enc is the encryption function of the crypto-system, and to a register (B) in which a smart contract (SC) is deployed; a binary tree (A) being used to order the members of the group; each member (Ui) being associated with a terminal node of the tree, this node being attached to a root node of the tree, directly or via a sequence of at least one node (Nj,k), the root node and where it exists said sequence of at least one node constituting the chain of attachment of the member (Ui) considered; each member of the group having an asymmetric key pair, whose secret key and public key are considered the node secret key and node public key for the terminal node associated with the member; the public key of the root node being called the public key of the group; the process including a procedure for adding a member to the group to integrate a candidate wishing to join the group, at a given time where the group (G) consists of a set of members (Up), called pre-addition members, forming a pre-addition tree (An), each pre-addition member (Uav) has or is able to calculate a pre-addition secret key of node (SKj,k,n) for any node (Nj,k,n) in its chain of attachment; and For each node in the pre-addition tree (An), a pre-addition public key (PKj,k,n) for the node is recorded in the registry; the member addition procedure includes the following operations: S10) an admission request into the candidate's group (Un+i) is transmitted to the smart contract, the admission request including an authenticator (accUser) and a personal public key (PKUn+1)

2. of the candidate, the candidate also holding a personal private key (SKUn+1) from which his personal public key (PKUn+1) was calculated using the crypto-system; S20) the smart contract records in the register the admission into the group (G) of a new member having the authenticator (accUn+i) of the candidate and the public key of the candidate (PKUn+1); S30) the candidate determines or obtains from the smart contract a list of the node(s) of its chain of attachment in the tree; S40) step by step, for each node in its chain of attachment, from the node of the tree to which it is directly attached up to the root node (NI), the candidate calculates the secret key of the node (SKj+l,kl,n+l) then the public key of the node (PKj+l,kl,n +D; S50) the candidate publishes in the registry the public key(s) of node (PKj,k,n) calculated in step S40; S60) The smart contract sends a member addition message to at least each active member before the group is added; and S70) upon receipt of the member addition message, step by step, for each node in its attachment chain that is also part of the candidate's attachment chain, in the direction from the node of the tree to which it is directly attached towards the root node (Ns), each active member before addition (Up) calculates the node secret key (SKj+l,kl,n+l); The secret key of a given node (NPKj,k,p+l) is calculated by a person whose chain of attachment contains a first child of the given node: - if said given node has a second child and said person has access to an uncompromised public key of the second child, based on the secret key (SKj,k2-l,n) of the first active child and the public key (PKj,k2,n) of said second child of said given node; or in any other case, - depending on the secret key (SKj-l,kl,p) of the first child of said given node. A method for managing a group according to claim 1, the method further comprising a procedure for removing a member from the group, referred to as the departing member (Up), other than the member who joined the group last, in order to remove the departing member from the group, said member removal procedure comprising: S100) a withdrawal request for the departing member (Up) is sent to the smart contract; S110) the smart contract sends a key update message to at least each remaining active member of the group, indicating as key(s) to be renewed and as compromised key the secret key of each of said node(s) of the chain to which the departing member is attached; S120) each remaining active member (U1,U2,U6,U7), called remaining member considered (U2), evaluates the node, called first common node, which is the node of its attachment chain (CR2) which is furthest from the root node and which also belongs to the chain of keys to be renewed; S120-1) If the public key of the first common node has been renewed since the key update message, then, step by step, the remaining member under consideration calculates the secret key and the public key of the node under consideration, starting from the first common node and going up to the root node; conversely, S120-2) if the public key of the first common node has not been renewed since the key update message: S120-22) for each node, called the node to be updated, located on the chain of attachment going from the first common node to the root node, the remaining member considered calculates the secret key and the public key of the node to be updated, and publishes the latter in the register, the said node to be updated then being called the updated node; any node whose public key is compromised being considered as non-existent during any calculation of the secret key of the node; S120-24) the smart contract sends a node update message at least to each other active member of the group, i.e. at least to each active member of the group, other than the departing member and the remaining member under consideration, indicating the updated node; S120-26) step by step, each other member calculates the node secret key of the considered node, for each updated node that is also part of its chain of attachment, in the direction from the terminal node of the tree to which it is attached towards the root node (Ns).

3. A method for managing a group according to claim 2, further comprising a method for reconnecting a group member after the withdrawal of a departing member, wherein: S200) when a group member, called the reconnecting member (Ur), activates its connection to the group after a period of inactivity, the reconnecting member (Ur) consults the messages received from the smart contract; S210) when the reconnecting member (Ur) has received a member withdrawal message from the smart contract, the reconnecting member evaluates the node, called the first common node, which is the node in its chain of attachment that is furthest from the root node and that also belongs to the chain of keys to be renewed: S210-1) if the public key of the evaluated node has been renewed since the key update message, step by step, the reconnecting member calculates the secret key and the public key of the node in question, from the first common node up to the root node;or conversely, S210-2) if the public key of the evaluated node has not been renewed since the member withdrawal message: S210-22) for each node, called the node to be updated, located on the chain of attachment going from the first common node to the root node, the reconnecting member calculates the secret key and the public key of the node to be updated and publishes the latter in the registry, said node to be updated then being called the updated node; any node whose public key is compromised being considered non-existent during any calculation of the secret key of the node; S210-24) the smart contract sends a node update message at least to each other member of the active group, that is to say each active member of the group, other than the departing member and the reconnecting member, indicating the updated node;S210-26) step by step, each other member calculates the secret key of the node in question, for each updated node that is also part of its chain of attachment, in the direction going from the terminal node of the tree to which it is directly attached towards the root node (Ns).;

4. A management method according to any one of claims 1 to 3, wherein at least one node secret key (NPKj,k,p+l) of a given node (Nj,k) is calculated: - by calculating a cryptographic element called the shared node secret (NPKj,k,p) as a function of the secret key (SKj,k2-l,n) of a first child and the public key (PKj,k2,n) of a second child of the given node; and - by calculating the secret key (SKj,k,p+l) of the given node (Nj,k) from said shared node secret (NPKj,k,p), for example as being equal to a part of the node secret.

5. A method for managing a group comprising a plurality of members (Ui... One), each member (U;) holding or being able to hold a group secret key (skNjjk), the method employing an asymmetric cryptosystem (Enc,Dec) verifying ownership, for two pairs of asymmetric keys (PKI,SKI) and (PK2,SK2): Enc(PKl,SK2) = Enc(SKl,PK2), where Enc is the encryption function of the cryptosystem, and a register (B) in which a smart contract (SC) is deployed; a list (Ln) being used to order the members of the group; the process comprising a procedure for adding a member to the group to integrate a candidate wishing to join the group, at a given time when the group (G) is made up of a set of members (Up), called pre-addition members, each pre-addition member (Uav) has or is able to calculate a pre-addition secret key (SKgroup n) of the pre-addition group;and a pre-addition public key (PKgroup n) of the pre-addition group is registered in the registry; wherein the member addition procedure includes the following operations: S310) an admission request to the candidate's group (Un+i) is transmitted to the smart contract, the admission request including an authenticator (accUser) and a personal public key (PKUn+1) of the candidate, the candidate also holding a personal private key; (SKUn+1) from which his personal public key (PKUn+1) was calculated using the cryptosystem; S320) the smart contract records in the register the admission into the group (G) of a new member of the group having the authenticator (accUn+i) of the candidate and the public key of the candidate (PKUn+1); S330) from the pre-addition public key (PKgroup n) of the pre-addition group and its personal private key (SKUn+1) the candidate calculates a new secret key of the group (SKgroup n+1) then a new public key of the group (PKgroup n+1) for the group; S340) the candidate publishes in the registry the new public key value of the group (PKgroup n+1) calculated in step S330; S350) the smart contract sends a group key update message to at least each active pre-add member of the group; and S360) upon receipt of the group key update message, from the pre-add secret key (SKgroup n) of the pre-add group and the candidate's personal public key (PKUn+1), each active pre-add (Up) member calculates the new group secret key (SKgroup n+1).

6. A method for managing a group according to claim 5, wherein: at the latest shortly after a reconnection of a group member who had been inactive, or at the request of that member upon reconnection, once the member addition procedure has been executed, the smart contract sends a group key update message after the addition of a member to said inactive member; and the group management process further includes a process for reconnecting said inactive member after the addition of a member, in which: S400) when said member, having been inactive, reconnects to the group, he consults the messages received from the smart contract; S410) when the reconnecting member (Ur) has received from the smart contract a group key update message after adding a member, from the pre-addition secret key (SKgroup n) of the pre-addition group and the personal public key (PKUn+1) of the candidate, said member having been inactive calculates the new group secret key (SKgroup n+1).

7. A method for managing a group according to claim 5 or 6, the method further comprising a procedure for removing a member of the group, referred to as the departing member (Up), other than the member who joined the group last, to remove the departing member from the group, said member removal procedure comprising: S500) a request to remove the departing member (Up) is sent to the smart contract; S510) the smart contract identifies a member (Uini), referred to as the initial member, who is an active member of the group who joined the group before the departing member; S520) the smart contract sends a new addition message to each active member of the group who joined the group after the initial member, referred to as the member to be reinstated, with the exception of the departing member, inviting the latter to rejoin the group; S530) upon receipt of the new addition message, for each member to be reinstated (Up), steps S330 to S360 of the member addition procedure are carried out, considering the member to be reinstated as the candidate.

8. A management method according to any one of claims 5 to 7, wherein at least one new group secret key (SK^pp +i) is calculated: - by calculating a cryptographic element called a shared group secret (NPKgroupp) as a function of the secret key (SKi,p) of a group member and a public key (PK^pp) of the group, or alternatively as a function of the public key (PKi,p) of a group member and a secret key (SK^pp) of the group; and - by calculating the new group secret key (SKj,k,p+l) from said shared group secret (NPKg,.OUp p), for example as being equal to a part of the group secret.

9. A management method according to any one of claims 1 to 8, wherein: when a new group public key is registered in the registry, the smart contract assigns a 'Blind' status to all remaining members other than the member, referred to as the group update member, that triggered this registration; when a member other than the trigger member calculates the group secret key, it informs the smart contract; on this basis, the smart contract assigns an 'Online' status to said other member; and the process includes at least one procedure implemented using the smart contract, other than a procedure for adding or removing a member, in which at least one action of the smart contract is performed depending on the member's status.

10. A management method according to any one of claims 1 to 9, further comprising a procedure for retroactively obtaining by a reconnecting member, following a period of inactivity, at least one group secret to be obtained, which had been a current key of the group during said period of inactivity, said retroactive obtaining procedure comprising the following steps: S600) from information published in the register and / or by querying the smart contract, the reconnecting member determines an authenticator of a key-holding member from whom it can obtain said at least one secret to be obtained; S610) the reconnecting member requests the key-holding member to provide said at least one secret to be obtained;S620) The key-holding member verifies that the reconnecting member was a member of the group at a time when the requested at least one secret key was the current secret key of the group, and that the reconnecting member is still a member of the group. S630) If the result of the verification is positive, the key-holding member in question opens a secure auxiliary communication channel with the reconnecting member, for example by following the protocol indicated by French patent application no. 1763394; and S640) Through the secure auxiliary communication channel thus opened, the key-holding member in question provides the reconnecting member with the requested at least one secret key.

11. A group management method according to any one of claims 1 to 10, further comprising a step (S80; S370), during which at least one active member of the group calculates a symmetric group key from a secret group key.

12. A management method according to claim 11, wherein, in order to calculate said symmetric group key, said at least one active member of the group: - calculates a cryptographic element called the shared group secret (NPKgroupp) based on its secret key (SKi,p) and a public key (PKgroupp) of the group, or alternatively based on the public key (PKi,p) of a group member and a secret key (SKgroupp) of the group; and - calculates the symmetric key (EncKgroupp +1) of the group from said shared group secret (NPKgroupp), for example as being equal to a part of the group secret.

13. A method of encrypted communication within a group, comprising the following steps: A. the group is formed by implementing the group management method according to any one of claims 1 to 12; B. at least one member of the group calculates a group symmetric key (EncKgroupp) from the group secret key (SKgrOupp); and C. this member receives a message and decrypts it using the group symmetric key, or encrypts a message using the group symmetric key and sends it.