Search

EP-4664819-B1 - METHOD FOR MANAGING A GROUP SHARING A SECRET KEY

EP4664819B1EP 4664819 B1EP4664819 B1EP 4664819B1EP-4664819-B1

Inventors

  • PAULIN, Dylan
  • HENNEBERT, CHRISTINE
  • JAYET, Quentin

Dates

Publication Date
20260513
Application Date
20250605

Claims (13)

  1. A method for managing a group comprising a plurality of members (U 1 ...U n ), each member (U i ) holding or being capable of holding a group secret key (SKj,k,p), the method using an asymmetric cryptosystem (Enc,Dec) verifying the property, for two asymmetric key pairs (PK1,SK1) and (PK2,SK2): Enc PK 1 , SK 2 = Enc SK 1 , PK 2 , where Enc is the encryption function of the cryptosystem, and a registry (B) wherein a smart contract (SC) is deployed; a binary tree (A) being used to organize the group members; 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 when it exists said sequence of at least one node forming the attachment chain of the considered member (Ui); each group member 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; the public key of the root node being referred to as group public key; the method comprising a procedure for adding a member to include a candidate seeking to join the group in the group, at a given time when the group (G) is formed by a set of members (Up), referred to as pre-addition members, forming a pre-addition tree (An), each pre-addition member (Uav) has or is capable of computing a pre-addition node secret key (SKj,k,n) for any node (Nj,k,n) of their attachment chain; and for each node of the pre-addition tree (an), a pre-addition node public key (PKj,k,n) is registered in the registry; the procedure for adding a member comprising the following operations: S10) a request for entry of the candidate (U n+1 ) into the group is sent to the smart contract, the request for entry comprising an authenticator (acc User ) and a personal public key (PKUn+1) of the candidate, the candidate further holding a personal private key (SKUn+1) from which their personal public key (PKUn+1) has been computed by means of the cryptosystem; S20) the smart contract registers in the registry the entry into the group (G) of a new member having the candidate's authenticator (acc Un+1 ) and the candidate's public key (PKUn+1); S30) the candidate determines or obtains from the smart contract a list of the node(s) of their attachment chain in the tree; S40) in a neighbor-to-neighbor manner, for each node of their attachment chain, from the node of the tree to which they are directly attached to the root node (N1), the candidate computes the node secret key (SKj+1,k1,n+1) followed by the node public key (PKj+1,k1,n+1); S50) the candidate publishes in the registry the node public key(s) (PKj,k,n) computed in step S40; S60) the smart contract sends a member addition message at least to each active pre-addition group member; and S70) on receipt of the member addition message, in a neighbor-to-neighbor manner, for each node of their attachment chain that is also part of the candidate's attachment chain, in the direction from the node of the tree to which they are directly attached to the root node (Ns), each active pre-addition member (Up) computes the node secret key (SKj+1,k1,n+1); the node secret key (NPKj,k,p+1) of a given node (Nj,k) being computed by a party whose attachment chain contains a first child of the given node: - if said given node has a second child and said party has access to a non-compromised public key of the second child, according to the secret key (SKj,k2-1,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, - according to the secret key (SKj-1,k1,p) of the first child of said given node.
  2. The 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 departing member (Up), other than the member who last joined the group, to remove the departing member from the group, said procedure for removing a member comprising: S100) a request to remove the departing member (Up) is sent to the smart contract; S110) the smart contract sends a key update message at least to each remaining active group member, indicating as key(s) to be refreshed and as compromised key the secret key of each of said node(s) of the attachment chain of the departing member; S120) each remaining active member (U1,U2,U6,U7), referred to as considered remaining member (U2), evaluates the node, referred to as first common node, which is the node of their attachment chain (CR2) furthest from the root node and which also belongs to the key chain to be refreshed; S120-1) if the public key of the first common node has been refreshed since the key update message, in a neighbor-to-neighbor manner, the considered remaining member computes the secret key and the public node key of the considered node, from the first common node to the root node; conversely, S120-2) if the public key of the first common node has not been refreshed since the key update message: S120-22) for each node, referred to as node to be updated, located on the attachment chain from the first common node to the root node, the considered remaining member computes the secret key and the public node key of the node to be updated, and publishes the latter in the registry, said node to be updated then being referred to as updated node; any node for which the public key is compromised being considered as non-existent during any node secret computation; S120-24) the smart contract sends a node update message at least to each other active group member, i.e. at least to each active group member, other than the departing member and the considered remaining member, indicating the updated node; S120-26) in a neighbor-to-neighbor manner, each other member computes the node secret of the considered node, for each updated node also belonging to their attachment chain, in the direction from the terminal node of the tree to which they are attached to the root node (Ns).
  3. The method for managing a group according to claim 2, further comprising a method for reconnecting a group member after removing a departing member, wherein: S200) when a group member, referred to as reconnecting member (Ur), activates their 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 removal message from the smart contract, the reconnecting member evaluates the node, referred to as first common node, which is the node of their attachment chain furthest from the root node and which also belongs to the key chain to be refreshed: S210-1) if the public key of the evaluated node has been refreshed since the key update message, in a neighbor-to-neighbor manner, the reconnecting member computes the secret key and the public node key of the considered node, from the first common node to the root node; or conversely, S210-2) if the public key of the evaluated node has not been refreshed since the member removal message: S210-22) for each node, referred to as node to be updated, located on the attachment chain from the first common node to the root node, the reconnecting member computes the secret key and the public node key of the node to be updated and publishes the latter in the registry, said node to be updated then being referred to as updated node; any node for which the public key is compromised being considered as non-existent during any node secret computation; S210-24) the smart contract sends a node update message at least to each other active group member, i.e. each active group member, other than the departing member and the reconnecting member, indicating the updated node; S210-26) in a neighbor-to-neighbor manner, each other member computes the node secret of the considered node, for each updated node also belonging to their attachment chain, in the direction from the terminal node of the tree to which they are directly attached to the root node (Ns).
  4. The management method according to any one of claims 1 to 3, wherein at least one node secret key (NPKj,k,p+1) of a given node (Nj,k) is computed: - by computing a cryptographic element referred to as node shared secret (NPKj,k,p) according to the secret key (SKj,k2-1,n) of a first child and the public key (PKj,k2,n) of a second child of the given node; and - by computing the secret key (SKj,k,p+1) of the given node from said node shared 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 (U 1 ...U n ), each member (U i ) holding or being capable of holding a group secret key (sk Nj,k ), the method using an asymmetric cryptosystem (Enc,Dec) verifying the property, for two asymmetric key pairs (PK1,SK1) and (PK2,SK2): Enc PK 1 , SK 2 = Enc SK 1 , PK 2 , where Enc is the encryption function of the cryptosystem, and a registry (B) wherein a smart contract (SC) is deployed; a list (Ln) being used to organize the group members; the method comprising a procedure for adding a member to include a candidate seeking to join the group in the group, at a given time when the group (G) is formed by a set of members (Up), referred to as pre-addition members, each pre-addition member (Uav) has or is capable of computing 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 procedure for adding a member comprises the following operations: S310) a request for entry of the candidate (U n+1 ) into the group is sent to the smart contract, the request for entry comprising an authenticator (acc User ) and a personal public key (PKUn+1) of the candidate, the candidate further holding a personal private key (SKUn+1) from which their personal public key (PKUn+1) has been computed by means of the cryptosystem; S320) the smart contract registers in the registry the entry into the group (G) of a new group member having the candidate's authenticator (acc Un+1 ) and the candidate's public key (PKUn+1); S330) based on the pre-addition public key (PKgroup n) of the pre-addition group and their personal private key (SKUn+1), the candidate computes a new group secret key (SKgroup n+1) followed by a new group public key (PKgroup n+1) for the group; S340) the candidate publishes in the registry the new public key value of the group (PKgroup n+1) computed in step S330; S350) the smart contract sends a group key update message at least to each active pre-addition group member; and S360) on receipt of the group key update message, based on the pre-addition secret key (SKgroup n) of the pre-addition group and the candidate's personal public key (PKUn+1), each active pre-addition member computes the new group secret key (SKgroup n+1).
  6. The method for managing a group according to claim 5, wherein: no later than some time after a reconnection of a group member who has been inactive, or at the request of the latter during their reconnection, when the procedure for adding a member has been executed, the smart contract sends a group key update message after adding a member to said member who has been inactive; and the method for managing a group further comprises a method for reconnecting said member who has been inactive after adding a member, wherein: S400) when said member who has been inactive reconnects to the group, they consult the messages received from the smart contract; S410) when the reconnecting member (Ur) has received a group key update message from the smart contract after addition of a member, based on the pre-addition secret key (SKgroup n) of the pre-addition group and the candidate's personal public key (PKUn+1), said member who has been inactive computes the new group secret key (SKgroup n+1).
  7. The method for managing a group according to claim 5 or 6, the method further comprising a procedure for removing a member from the group, referred to as departing member (Up), other than the member who last joined the group, to remove the departing member from the group, said procedure for removing a member comprising: S500) a request to remove the departing member (Up) is sent to the smart contract; S510) the smart contract identifies a member (U ini ), referred to as initialization member, who is an active group member who joined the group before the departing member; S520) the smart contract sends a new group addition message to each active group member who joined the group after the initialization member, referred to as member to be reintegrated, with the exception of the departing member, inviting the latter to rejoin the group; S530) on receipt of the new group addition message, for each member to be reintegrated (Up), steps S330 to S360 of the procedure for adding a member are performed, considering the member to be reintegrated as the candidate.
  8. The management method according to any one of claims 5 to 7, wherein at least one new group secret key (SK group p+1 ) is computed: - by computing a cryptographic element referred to as group shared secret (NPK group p ) according to the secret key of a group member and a group public key (PK group p ), or according to the public key (PKi,p) of a group member and a group secret key (SK group p ); and - by computing the new group secret key (SKj,k,p+1) from said group shared secret (NPK group p ), for example as being equal to a part of the group shared secret.
  9. The management method according to any one of claims 1 to 8, wherein: when a new public group key is registered in the registry, the smart contract assigns a 'Blind' status to all remaining members other than the member, referred to as group update member, who triggered this registration; when a member other than the triggering member computes the group secret key, they inform the smart contract; on this basis, the smart contract assigns an '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, wherein at least one action of the smart contract is carried out according to the member status.
  10. The management method according to any one of claims 1 to 9, further including a procedure for a reconnecting member following a period of inactivity retroactively obtaining at least one group secret key to be obtained, which had been a current group key during said period of inactivity, said retroactive obtaining procedure including the following steps: S600) based on information published in the registry and/or by querying the smart contract, the reconnecting member determines an authenticator of a key holder member from whom they can obtain said at least one secret key to be obtained; S610) the reconnecting member requests the key holder member to provide said member with at least one secret key to be obtained; S620) the key holder member verifies that the reconnecting member was a group member at a time when said at least one requested secret key was the current group secret key, and that the reconnecting member still belongs to the group. S630) if the result of the verification is positive, the considered key holder member 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) via the secured auxiliary communication channel thus opened, the considered key holder member provides said reconnecting member with at least one requested secret key to be obtained.
  11. The method for managing a group according to any one of claims 1 to 10, further comprising a step (S80; S370), wherein at least one active group member computes a group symmetric key from a group secret key.
  12. The management method according to claim 11, wherein to compute said group symmetric key, said at least one active group member: - computes a cryptographic element referred to as group shared secret (NPK group p ) according to their secret key (SKi,p) and a group public key (PK group p ), or according to the public key (PKi,p) of a group member and a group secret key (SK group p ); and - computes the group symmetric key (EncK group p+1 ) from said group shared secret (NPK group p ), for example as being equal to a part of the group secret.
  13. A method for encrypted communication within a group, comprising the following steps: A. the group is formed by implementing the method for managing a group according to any one of claims 1 to 12; B. at least one group member computes a group symmetric key (EncK group p ) from the group secret key (SK group p ); and C. this member receives a message and deciphers it using the group symmetric key, or encrypts a message using the group symmetric key and sends it.

Description

TECHNICAL FIELD OF THE INVENTION 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 group members, access control to sensitive areas (using a unique identifier), etc. To ensure that such operations are carried out securely, a group secret, which can also be called a secret key, can be shared by the members of the group. Therefore, the invention more specifically relates to a group management method allowing the sharing of a group secret within the group. STATE OF THE ART Communicating information between people, for example using an instant messaging application, requires taking into account a number of constraints. 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. Developing 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. To achieve 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 between the members of the group. This shared 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. That being said, maintaining a common and unique secret for each group allows its members to exchange encrypted messages known only to them. Ensuring that this secret is updated with each new member's departure or arrival in the group, while guaranteeing the continuity of confidential exchanges for other group members, 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,Continuous access to the group's encryption key for all group members. 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 members' identification data. To enable a shared cryptographic secret among group members, data must be encrypted for confidential exchange within the group. This requires a way to share public intermediate information that allows the shared secret to be calculated privately. If the communication devices of group members are connected within the same network, they can exchange messages to create 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. In most existing messaging applications, a server is used for the exchange of public information within a group. 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, etc. 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, by French patent applications no. 1763393 and no. 1763394 . The processes disclosed by these patents use the Diffie-Hellman protocol for exchanging 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. The generation of such a session key relies on each of the two people involved in the Diffie-Hellman protocol possessing an asymmetric key pair. Thus, by implementing this protocol, a person with their own asymmetric key pair can initiate the calculation of a shared secret with another person who also possesses their own asymmetric key pair. 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). The asymmetric cryptography algorithm used is usually a modular arithmetic algorithm: The cryptosystem can be a Rivest-Shamir-Adleman cryptosystem ( RSA), or based on elliptic curves ( Elliptic Curve Cryptography, ECC). The Diffie-Hellman protocol involves the following steps: A1) each of the two people registers the public key of their asymmetric key pair in the registry; A2) Each of the two