Method for Hiding the ID of a Communication Device in Continuous Group Key Agreement

Abstract

A method is provided for hiding the ID of a communication device in a continuous group key agreement. A group member making a request regarding a change in the group state provides a signed challenge value to the server, and the signed challenge value is signed using the group signature key. The server checks the signed challenge value to determine whether the group member owns the group signature key and thus is a member of the group. Since the group signature key is used, the server cannot determine the ID of the group member making the request.

Description

Technical Field

[0001] The present invention relates to a method for hiding the IDs of two or more communication devices within a group that communicates using continuous group key agreement. The present invention also relates to a communication device and a program that execute a method for protecting the IDs of two or more communication devices within a group that communicates using continuous group key agreement.

Background Art

[0002] Secure group messaging protocols enable a group of users to communicate in a secure and asynchronous manner. In recent years, continuous group key agreement protocols have made it possible for long-lived groups of parties to agree on a group secret and generate a continuous stream of new key material. Generally, secure group messaging protocols aim to enable group members to communicate in an end-to-end encrypted manner, such that adversaries, including the server used to forward messages, cannot read the messages transmitted between group members.

[0003] Secure group messaging protocols can often protect the content of messages transmitted between group members, which is encrypted using a symmetric key known only to the group members. However, adversaries may collect metadata such as the IDs of the sender and other group members. Metadata can be determined from any unencrypted exchanged content or information inferred from the exchanged content. Knowledge of the metadata alone can have harmful effects. For example, it may reveal the IDs of journalists or activists who are sending messages using a group.

[0004] Protecting metadata (e.g., group member IDs and social relationships) is generally difficult because the knowledge of those IDs is often required by the server to ensure proper functioning of a secure group messaging protocol.

Summary of the Invention

Means for Solving the Problems

[0005] A method for hiding the IDs of two or more communication devices within a group that communicates using continuous group key agreement, where the two or more communication devices can communicate with each other within the group via a server, and the protocol for continuous group key agreement generates one or more proposals for updating the group state by one or more of the communication devices in the group, stores the one or more proposals on the server, and commits zero or more of the functions of the one or more proposals stored on the server by the committing communication device of the group. The committing communication device updates the group state stored in the committing communication device based on the committed functions of zero or more proposals, and as a result of committing the functions of zero or more proposals, the commitment regarding the functions of zero or more proposals is stored on the server. By committing the functions of zero or more proposals, a new epoch for the group is started, including committing, and one or more downloading communication devices that are members of the group other than the committing communication device download the commitment and update the group state in each of the one or more downloading communication devices based on the commitment, and each of the one or more downloading communication devices determines a group secret for the new epoch based on the downloaded commitment, enabling the one or more downloading communication devices and the committing communication device within the group to generate a common secret key for the epoch. The method for hiding the IDs of two or more communication devices includes the requesting communication device sending a signed challenge value to the server in relation to a request for an operation, where the signed challenge value is generated by signing the challenge value with the group signature key, and the requested operation includes one of storing one or more proposals on the server, storing a commitment regarding the functions of zero or more proposals on the server, and downloading the commitment. Sending, and the server uses the group verification key stored on the server and the challenge value to check the signed challenge value, and the signed challenge value isWhen it is indicated that the requesting communication device owns a group signature key, the server performs the requested operation, and when the signed challenge value does not confirm that the requesting communication device owns a group signature key, the server does not perform the requested operation, and a method including this is provided.

[0006] According to the method of the first aspect, the server uses the group verification key to verify the signature generated by the communication device that makes a request using the group signature key. Since the key is a group key, the server can determine that the communication device that requests to perform an operation related to the group state is a member of the group, thereby preventing a communication device that is not a member of the group from changing the group state. However, the server cannot determine which group member is making the operation request. Therefore, the ID of the communication device is hidden from the server.

[0007] The common secret key can be derived from the group secret for the current epoch. The group verification key can be derived from the group secret for the current epoch of the group. The group signature key can be derived from the group secret for the current epoch of the group. The current epoch of the group can be determined based on the latest commit value stored in the server. The step of committing the function of zero or more proposals may include generating and storing a new group verification key for a new epoch in the server by the communication device that commits. According to such an embodiment, only the devices within the group that own the group secret can succeed in requesting an operation to change the group state. Because the group secret is necessary to derive the group signature key.

[0008] In some embodiments, the requesting communication device sends a request for an operation to the server, and in response to the request, the server sends a challenge value to the communication device. The requesting communication device receives the challenge value and signs the challenge value using the group signature key for that epoch to generate a signed challenge value.

[0009] In some other embodiments, the challenge value can be derived from at least one of the content of the proposal message sent to the server, the content of the commit message sent to the server, randomness, and other predetermined data. In some embodiments, the challenge value can be a pseudo-random value generated at the communication device and can be included in a message having a signature of the pseudo-random value under the group signature key.

[0010] In some embodiments, the group secret can be the joinerSecret. The common secret key can be the appSecret or a derivative thereof. The group secret can be obtained by the communication device joining the group from the welcome message downloaded from the server. In some embodiments, the committing communication device uploads one or more welcome messages to the server when committing to zero or more proposal functions. In such cases, the zero or more proposals can include proposals to add one or more group members to the group. The one or more welcome messages uploaded to the server correspond to one or more group members added to the group. In the case of a communication device that is already a member of the group, the group secret can be derived from the commit secret included in the commit stored on the server by the committing communication device.

[0011] A commit may include a commit secret. The commit secret may be used by a communicating device that downloads it to derive a group secret for an epoch associated with the commit. The group secret may be derived from the commit secret using a key derivation function.

[0012] In some embodiments, a server may process a commit received at the server from a communicating device that commits to generate one or more member-dependent commit portions. In other embodiments, a comment received at the server from a communicating device that commits may include one or more member-dependent commit portions.

[0013] A commit stored at the server may include a member-independent commit portion and a plurality of member-dependent commit portions associated with respective members of the group. The step of downloading the commit by one or more communicating devices that are members of the group other than the communicating device that commits may include each communicating device that downloads downloading a package that includes the member-independent commit portion and the member-dependent commit portion associated with the communicating device that downloads.

[0014] Each member-dependent commit part may have a respective position associated with the index or an index. Each communication device to download may use the corresponding index to download the corresponding member-dependent commit part. The index may be pseudo-randomly shuffled based on the shuffling key in each epoch to prevent tracking of the ID of the communication device that downloads the member-dependent commit part. The index may be pseudo-randomly shuffled using a shuffling algorithm that takes the shuffling key as an input. In other embodiments, a random value may be assigned to each index using a pseudo-random number generator that takes the shuffling key as an input, and then the index may be sorted. The index may be sorted using a forgetful sorting network. The shuffling key may be derived by each communication device from the group secret.

[0015] The member-dependent commit parts may be stored on the server by the communication device that commits using the respective positions and / or indexes determined by the communication device that commits using the shuffling key. The member-dependent commit parts may be downloaded from the server by one or more communication devices to download using the respective indexes determined by each communication device to download using the shuffling key.

[0016] The communication devices may communicate with the server by establishing respective client anonymized communication channels.

[0017] Downloading a commit by one or more communication devices to download that are members of a group other than the communication device that commits may include downloading from the server zero or more proposed functions associated with the commit. Each communication device to download may update the group state stored on the communication device to download based on the zero or more downloaded proposed functions.

[0018] Committing zero or more functions out of one or more proposals stored on a server by a communicating device that is part of a group may include sending a request to fetch the proposals stored on the server in relation to the current epoch and sending a request to store the commitment on the server. Sending a request to fetch the proposals may include sending a signed challenge value to the server in relation to the request to fetch the proposals. The signed challenge value may be generated by signing the challenge value with a group signature key. The server may check the signed challenge value using a group verification key stored on the server and the challenge value. If the signed challenge value indicates that the requesting communicating device owns the group signature key, the server may send the proposals stored in relation to the current epoch, and if the signed challenge value does not confirm that the requesting communicating device owns the group signature key, the server may not send the proposals stored in relation to the current epoch.

[0019] The signed challenge value sent in relation to the request to fetch the proposals and the signed challenge value sent in relation to the request to store the commitment on the server may be the same signed challenge value. In other embodiments, the communicating device that is committing may generate a separate signed challenge value for each request.

[0020] The group state stored in each communicating device within the group may include one or more of a group identifier, an identifier of the current group epoch, a list of group member identifiers, a list of signature verification keys corresponding to the list of group member identifiers, a group signature key for the current epoch, a group verification key for the current epoch, and a sorting key used to sort the index.

[0021] The group signature key and the group verification key may be a secret / public key pair in a public key signature scheme.

[0022] The group signature key and the group verification key can be the same key. In such embodiments, the signature can be a message authentication code.

[0023] According to a second aspect of the present invention, a communication device for use in a method for hiding the IDs of two or more communication devices within a group that communicates using continuous group key agreement, wherein the two or more communication devices can communicate with each other within the group via a server, the communication device is configured to execute a continuous group key agreement protocol, the continuous group key agreement protocol generates one or more proposals for updating the group state, stores the one or more proposals on the server, and commits zero or more functions of the one or more proposals stored on the server, committing zero or more functions of the proposals updates the group state stored in the communication device based on the committed functions of the zero or more proposals, and as a result of committing the functions of the zero or more proposals, transmits a commit regarding the functions of the zero or more proposals for storage on the server, and by committing the functions of the zero or more proposals, a new epoch is started in the group, including committing, downloading the commit, and updating the group state on the communication device based on the commit, and determining a group secret for the new epoch based on the downloaded commit, enabling the communication device to generate a common secret key for the epoch, the communication device is further configured to execute a method for hiding the IDs of two or more communication devices, the method transmits a signed challenge value to the server in relation to a request for an operation, the signed challenge value being generated by signing the challenge value with a group signature key, the requested operation including one of storing one or more proposals on the server, storing a commit regarding the functions of zero or more proposals on the server, and downloading the commit, whereby the server can check the signed challenge value using the group verification key stored on the server and the challenge value, and if the signed challenge value indicates that the communication device owns the group signature key, the requested operation can be executed, and if the signed challenge value does not confirm that the communication device owns the group signature key, the requested operation is not executed.A communication device is provided.,

[0024] According to a third aspect of the present invention, when executed by two or more communication devices and a server configured such that the two or more communication devices communicate with each other within a group via the server, one or more computer programs are provided that cause the communication devices and the server to execute the method according to the first aspect of the present invention.

[0025] According to a fourth aspect of the present invention, there is provided a communication device for hiding the IDs of two or more communication devices within a group that communicate using continuous group key agreement, wherein the two or more communication devices can communicate with each other within the group via a server, the communication device performs continuous group key agreement, and the continuous group key agreement generates one or more proposals for updating the group state and stores the one or more proposals on the server, and commits zero or more functions of the one or more proposals stored on the server, where committing zero or more functions of the proposals updates the group state stored in the communication device based on the committed proposals, and as a result of committing zero or more functions of the proposals, transmits a commit regarding the functions of zero or more proposals to be stored on the server, and by committing zero or more functions of the proposals, a new epoch is started from the group, and includes committing, downloading the commit, and updating the group state on the communication device based on the commit, and determining a group secret for the new epoch based on the downloaded commit, and enabling the communication device to generate a common secret key for the epoch, the communication device is further configured to execute a method for hiding the IDs of two or more communication devices, the method transmits a signed challenge value to the server in relation to a request for an operation, the signed challenge value being generated by signing the challenge value with a group signature key, and the requested operation includes one of storing one or more proposals on the server, storing a commit regarding the functions of zero or more proposals on the server, and downloading the commit, whereby the server can check the signed challenge value using the group verification key stored on the server and the challenge value, and if the signed challenge value indicates that the communication device owns the group signature key, the requested operation can be executed, and if the signed challenge value does not confirm that the communication device owns the group signature key, the requested operation is not executed, and a method executed by the communication device is provided.

[0026] According to a fifth aspect of the present invention, there is provided a method executed by a server for use by a group of communication devices using continuous key agreement, wherein two or more communication devices forming the group can communicate within the group via the server, and the continuous group key agreement comprises: the server storing one or more proposals generated by one or more of the group's communication devices for updating the group state in the communication devices; storing a commit regarding the functionality of zero or more proposals, the commit being generated by the committing communication device that commits the functionality of zero or more proposals stored on the server, and starting a new epoch for the group by committing the functionality of zero or more proposals; one or more downloading communication devices, which are members of the group other than the committing communication device, downloading the commit and enabling the one or more downloading communication devices to update their group state based on the commit. The server also executes a method for hiding the IDs of two or more communication devices, the method comprising receiving, from a communication device requesting a signed challenge value in relation to a request for an operation, the signed challenge value being generated by the requesting communication device signing the challenge value with a group signature key, the requested operation including one of storing one or more proposals in the server, storing a commit regarding the functionality of zero or more proposals in the server, and downloading the commit; checking the signed challenge value using the group verification key stored in the server and the challenge value; if the signed challenge value indicates that the requesting communication device owns the group signature key, executing the requested operation; and if the signed challenge value does not confirm that the requesting communication device owns the group signature key, not executing the requested operation.

[0027] In some embodiments, in response to a requesting communication device transmitting a request for an operation, the server transmits a challenge value to the communication device.

[0028] According to a sixth aspect of the present invention, there is provided a server for use by a group of communication devices that use continuous key agreement, wherein two or more communication devices forming the group can communicate within the group via the server, and the server is configured to perform continuous group key agreement, the continuous group key agreement comprising storing one or more proposals generated by one or more of the group's communication devices for updating the group state in the communication devices, and storing a commit regarding the functionality of zero or more of the proposals, the commit being generated by a committing communication device that commits the functionality of zero or more proposals stored on the server, and starting a new epoch for the group by committing the functionality of zero or more proposals, storing, and enabling one or more downloading communication devices, which are members of the group other than the committing communication device, to download the commit and update their group state based on the commit, and the server is also configured to perform a method for hiding the IDs of two or more communication devices, the method comprising receiving, in relation to a request for an operation, a signed challenge value from a communication device requesting the signed challenge value, the signed challenge value being generated by the requesting communication device signing the challenge value with the group signature key, the requested operation including storing one or more proposals in the server, storing a commit regarding the functionality of zero or more proposals in the server, or downloading the commit, receiving, checking the signed challenge value using the group verification key stored in the server and the challenge value, and performing the requested operation if the signed challenge value indicates that the requesting communication device owns the group signature key, and not performing the requested operation if the signed challenge value does not confirm that the requesting communication device owns the group signature key.

[0029] Next, embodiments of the present invention will be described by way of example only with reference to the accompanying drawings.

Brief Description of the Drawings

[0030]

Figure 1

Figure 2

Figure 3a

Figure 3b

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

[0031] In the following description, a method for hiding the IDs of two or more communication devices within a group that communicates using a continuous group key agreement protocol will be described. The two or more communication devices can communicate with each other within the group via a server. FIG. 1 is a schematic diagram showing two group members operating communication devices having IDs, id1 and id2, that communicate with each other via server 1. The group shown in FIG. 1 includes only two group members, but in general, a group can have any number of group members. Group members (hereinafter sometimes referred to as "parties") communicate by uploading messages to server 1 and downloading messages from server 1. The parties may use a secure group messaging protocol such as continuous group key agreement to encrypt the messages exchanged between group members. Continuous group key agreement can also provide a method for updating keys and a method for adding and removing group members from a group conversation.

[0032] Metadata and Metadata Leakage Within a secure group messaging protocol, confidential information can be split into three layers. First Layer - Group Secret Key and Messages Second Layer - Static and Explicit Metadata Third Layer - Dynamic and Implicit Metadata

[0033] The first layer contains data that is kept secret by some reasonable and secure group messaging protocol that functions as intended. The secret key(s) used to encrypt messages and message content are protected using a secure group messaging protocol to enable secure communication among group members.

[0034] The second and third layers can be identified as metadata. In traditional secure group messaging protocols, the data in the second and third layers can only be encrypted by transport layer encryption (e.g., TLS or Noise) between the server and participants. This is because the server needs to know some static metadata such as participant identifiers to facilitate the secure group messaging protocol.

[0035] The data in the second layer includes any static metadata. For example, the protocol may include the sender's ID in clear text, or the ID of the members added to the group. This example can be found in standard signaling and MLSPlaintext protocols. Static metadata may also include sender information and handshake messages in protocols such as the MLS draft specification (Ricard Barnes et al, "The Messginglayer Security (MLS) Protocol" 2022).

[0036] The data in the third layer includes dynamic metadata. Dynamic metadata includes any data that implicitly leaks from the access patterns between group members and the server. For example, when a group member connects to the server using a non-anonymous protocol (such as TLS), the server immediately learns the member's ID. Even when using an anonymous protocol to fetch information about the group, the exact subset of the accessed information can enable a correlation with the user's ID. This example is for a group messaging protocol that places group members in a complex data structure such as a tree.

[0037] Continuous Group Key Agreement With continuous group key agreement, the evolving group of users can agree on a continuous sequence of group secrets. Continuous group key agreement enables the sharing of group secrets and can implement the concepts of forward secrecy and post-compromise security. Forward secrecy is the feature that the session key is not put at risk even if the long-term secret used in the session key exchange is compromised. Similarly, post-compromise security means that future session keys are not put at risk even if the key for the current session is compromised.

[0038] Figure 2 is a schematic diagram showing an aspect of the continuous group key agreement protocol. The group shown in Figure 2 includes two group members with IDs, id1 and id2, but generally, as previously described in relation to Figure 1, any number of members can exist within a group with different IDs. The group members communicate via Server 1. Each member of the group stores a group identifier gid, the current epoch of the group, and the current group key. Additionally, each member stores a public key, and its associated secret key is known only to the individual. The member's secret / public key pair is referred to as key material.

[0039] Each group member also has a common agreed-upon key encapsulation mechanism formed from three components: a key generation function, an encapsulation function, and a decapsulation function. The key generation function for a given security parameter generates an encapsulation key and a decapsulation key. The encapsulation function, given an encapsulation key, generates a symmetric key and an encapsulation of the symmetric key under the encapsulation key. The decapsulation function, given a decapsulation key, outputs either a symmetric key or an error symbol.

[0040] Each group member can update its key using a successive group key agreement protocol by a) adding a new group member, b) removing a group member, and / or c) sending a proposal P. As shown in Figure 1, a group member with identifier id1 can send proposal P1 to server 1. The group member shown in Figure 1 as having id2 can receive proposals from the server

Number

Number

[0041] Subsequently, other group members can download and process commit c2 and update their group state to the next epoch according to the content of the committed proposals.

[0042] As described above, the group secret is updated during each proposal and commit cycle. Thus, if a group member's key material is compromised during that epoch, this process effectively "repairs" the group and provides post-compromise security.

[0043] Each proposal may consist of the following elements. i) A group ID, gid, that identifies the group, ii) An epoch counter that specifies the group state, iii) The ID, id, of the member creating the proposal P , iv) A string indicating the action to which the proposal pertains (e.g., as described above, adding a new group member, removing a group member, etc.), and v) Other information that may be required for authentication.

[0044] Each commit may consist of the following elements. i) A string gid that identifies the group, ii) An epoch counter that specifies the group state, iii) The ID, id, of the member executing the commitment c , iv) A commit secret ct used to update the group secret key A ciphertext encrypting it, v) A signature of at least a portion of the commitment by the member executing the commitment to enable detection of tampering, and vi) Other information that may be required for authentication.

[0045] In some embodiments (e.g., when using TreeKEM as a successive group key agreement), a single commit may be uploaded to the server. The single commit may include ciphertexts for each member of the group that encrypts the key used to update the group secret. In this case, the signature to be verified may be a signature of the contents of the single commit such that the group member verifies the signature of the commit contents before downloading the entire commit and processing the relevant portion of the commit. A potential drawback of this approach is that the size of the commit increases with the number of group members. Thus, for large groups, the commit can be expensive in terms of data transfer and bandwidth requirements.

[0046] In some tree-based continuous group key agreements, such as SAIK (Alwen et al, 2021, "Server-Aided Continuous Group Key Agreement") and CoCoA (Alwen et al, 2022, "CoCoA: Concurrent Continuous Group Key Agreement"), the uploaded commits are first processed by the server to generate a list of member-dependent commits.

[0047] In other embodiments, each uploaded commit is splittable into (c0,

Number

Number

Number

Number

Number

[0048] The above-described continuous group key agreement can be considered to have the following functions.

[0049] Group creation (Create). This function initializes a new group state with the party id as the only member.

[0050] Proposal (Propose, act) → P. This function outputs a proposal P for an action "act" that may take the values "add" - id t , "rem" - id t , or "upd". The first two actions instruct the addition or deletion of a party with the ID, id t . The last action updates the key material of the party id.

[0051] Commit (Commit,

number

number

number

number

number

number

number

Number

Number

Number

Number

[0052] Process(Process,c0,

Number

Number

Number

Number

[0053] Join,

Number

Number

[0054] Key → k. This function outputs the current group secret k.

[0055] Overview of Metadata Hiding Continuous Group Key Agreement In the following description, additional steps for metadata hiding continuous group key agreement are provided. The steps and methods described may be applicable to any continuous group key agreement protocol of the type described above.

[0056] Metadata hiding the continuous group key agreement protocol may have one or more of the following additional characteristics.

[0057] Group members with an anonymous upload - ID "id" can anonymously upload a proposal P or a commit (c0,

Number

[0058] Group members with an anonymous download - ID "id" can anonymously download a commit (c0,

Number

Number

[0059] Link impossibility - When a member performs multiple uploads and downloads, the server must not be able to link these uploads and downloads to track the member's activities.

[0060] Group authentication - Only members of the group can upload to and download from the server.

[0061] Figure 3a is a diagram showing the initial registration of a group by a group member having ID, id0. Figure 3b is a diagram showing the initial proposal being sent by a group member having ID, id0. In this embodiment, all parties except for the new member who is obtaining a welcome message from the server, as will be described in more detail below, set up a client anonymization authentication channel to communicate with server 1. Examples of client anonymization authentication channels include VPN and / or anonymization proxies (e.g., TOR).

[0062] During the initial registration shown in Figure 3a, party id0 wishes to create a group that includes three members (id0, id1, id2). Party id0 initializes a new group using the "Create" function with group identifier gid and group secret key, k0 (when epoch = 0). Party id0 uses the key generation function of the key encapsulation mechanism, KeyGen(1 k ;PRF(k mh , "auth"))→(gvk0, gsk0) to create a group-specific signature key. PRF is a pseudorandom function that takes a seed, an input secret derived from metaKey which will be further described below, and a label, and generates an output of arbitrary length. 1 k is a randomly selected binary value of length k bits that forms the seed. k mhis the input secret. "auth" is a label associated with an anonymized authentication channel established between the client and the server. The output of the key encapsulation mechanism forms a key pair including the group verification key gvk0 and the group signature key gsk0.

[0063] gvk0 is the group verification key. The group verification key gvk0 is referred to as the group state statement when epoch = 0. The party with id0 uploads the group identifier and the group verification key (gid, gvk0) to the server. The server creates a new database for the group with ID gid.

[0064] One or more of the communication devices of the group may generate one or more proposals for updating the group state, and one or more proposals may be stored on the server. Figure 3b is a schematic diagram showing that a group member with ID, id0, proposes to add two new members with IDs, id1 and id2, to the group. In this situation, only one group member can upload the proposal, but in the subsequent state of the group, there may be multiple group members, each of whom can upload a proposal to the server. The group member id0 calls the Propose function by the input (Propose, "add"-id i ) and generates each proposal P i (where i obtains a value of 1 or 2). To upload P i to the server, the group member id0 proves its membership in the group gid by executing a membership authentication protocol with the server.

[0065] The membership authentication protocol is used multiple times below. During the membership authentication protocol, the server sends a random challenge to the communication device to be authenticated (ch i ←{0,1} K)。In other words, the challenge is a random binary string of length K bits, but it could take other formats. The requesting communication device sends the signed challenge value, generated by signing the challenge value with the group signature key, along with the data for the requested operation to Server 1. This is, in this case, a request to store one or more proposals on the server. More specifically, group member id0 creates a signature (σ i ←Sign(gsk0,ch i )) using the group signature key gsk0 of the group described above. In other words, group member id0 signs the challenge value using the signing function under the group signature key gsk0. Group member id0 sends the signature and the proposal to the server. The server checks the signed challenge value using the stored group verification key and the challenge value. In this case, the server uses the group state statement (verification key) gvk0 at epoch = 0 to verify that σ i is a valid signature. The server executes the requested operation if the signed challenge value indicates that the requesting communication device owns the group signature key, and does not execute the requested operation if the signed challenge value does not confirm that the requesting communication device owns the group signature key. In this case, if the signature is valid, as shown in Figure 3b, the proposal P i is added to the proposal database. Due to the assumed unforgeability of the signature scheme, a party without the group signature key gsk0 cannot masquerade as a group member.

[0066] Figure 4 is a schematic diagram showing the commit operation and the initialization of a new epoch. According to the situation described in relation to Figure 3b, group member id0 uploads the proposed ([[]]

Number

Number

Number

Number

Number

Number

[0067] As described in the previous paragraph, the group member id0

Number

Number

Number

Number

[0068] When parties id1 and id2 become group members of group gid at epoch = 1, they share the same group secret key k1 of the current epoch = 1. Group members id0, id1, and id2 can exchange messages using the group secret key or use the group secret key as an input to the key management protocol to exchange messages. The key management protocol can manage keys by periodically rotating the symmetric communication key and synchronizing the communication key among group members. Group members can also upload proposals and commits to the database defined for group statement gvk1.

[0069] As briefly described above, when there are two or more members in a group, the size of the commit message changes. FIG. 5 is a diagram showing that a communication device that commits for a group commits zero or more functions among one or more proposals stored on a server, and as a result of committing zero or more proposals, commits regarding zero or more proposals are stored on the server. The communication device to commit updates the group state stored in the communication device to commit based on the committed proposal. When zero or more proposals are committed, a new epoch begins. FIG. 5 also shows that group members download the commit.

[0070] Generally, the communication device to commit may accept or reject the proposal stored on the server. For example, there may be duplicate proposals stored on the server that need to be resolved when committing a proposal. Further, there may be conflicting proposals such as a proposal to remove a member from the group and a proposal to add the same member to the group. Generally, the order of the proposals may also affect the change of the group state and may be considered by the communication device to commit. Therefore, by determining zero or more functions among the stored proposals, the communication device to commit may commit the functions of zero or more proposals and start a new epoch.

[0071] Specifically, when group member id2 submits proposal P3 to a server (not shown) and group member id1 wishes to commit this proposal (the situation shown on the left side of FIG. 5), the same procedure as described above for commit continues. Group member id1 calls the commit function (commit p3), and (c0,

Number

Number

[0072] If selective download where a group member downloads only a part of the commit is not executed, group member id1 simply uploads (c0, [Number] ) to the server. Then, the server starts a new column for epoch = 2.

[0073] This method also includes downloading a commit that updates the communication protocol used by the group by one or more communication devices that are members of the group other than the communication device that commits. That is, other group members can download the entire commit from the server as long as they can pass the membership authentication protocol described above. One or more downloading communication devices update their group states based on the commit.

[0074] Since the membership authentication protocol described above uses the group key to sign the challenge value, the server cannot identify the group members who access the server to obtain the commit. Therefore, embodiments enable anonymous upload and group authentication. Also, embodiments can enable anonymous download and link impossibility when the download of the commit does not depend on the member, that is, when each member downloads the same commit package.

[0075] Selective Download and Reordering As described above, in some embodiments, the commit may not be single, (c0, [Number] ) may be divided. Here, c0 is the member-independent commit part,

Number

Number

[0076] When selective download is executed, the group member sends an index to the server as shown in Figure 5 and receives the commit

Number

[0077] In a situation where the group secret key, and thus the group member list, has been compromised, it is desirable to repair the consecutive group key agreement. However, since the access pattern never changes, if selective download is executed by simply looking at the same index in each epoch, a server that has learned the member-index correspondence may permanently break anonymity.

[0078] To address this issue, pseudo-random permutation (PRP) can be used. Further embodiments based on the situation shown in FIG. 5 are described in the context of a commit scheme with selective download. Similar to the above, proposal P3 has been previously uploaded by group member id2 (not shown). Group member id1 generates a commit (c0,

Number

Number

Number

Number

Number

Number

[0079] When another group member (e.g., group member id2) performs a selective download to obtain a proposal and a commit from the server, it calculates the sorted index = PRP(permKey, 2). The calculation is performed such that group member id2 generates the same permKey as group member id1, thereby enabling the generation of the corresponding sorted index. Group member id2 executes an identification protocol using the group signature key gsk1 and sends the generated sorted index to the server to obtain the member-dependent commit (c0,

Number

Number

[0080] The above approach can, of course, be generalized to any epoch and any group member selectively obtaining a part of a proposal or a commit. The PRP key is permKey ← PRF(k mh , "perm"), where k mh is derived from the metaKey described later and "perm" takes on the value of each group member id. The group member id i performing the selective download calculates the sorted index = PRP(permKey, i). Here, i is the group member id.

[0081] According to the continuous group key agreement, each member of the group does not perform selective downloads more than twice per epoch. Therefore, the problem of repeated access using the same permuted index does not occur. When the group key is updated in each epoch, the PRP key is also updated. Thus, the continuous group key agreement protocol satisfies forward secrecy and post-compromise security. In this way, the access patterns of group members are randomized, and the server cannot derive information about the group members' IDs by monitoring the access patterns.

[0082] Example embodiments of the continuous group key agreement protocol The group members in the aforementioned protocol can be software applications on the communication devices used by the group members. There may be multiple communication devices that are functionally identical with respect to the continuous group key agreement protocol. Note that references to device IDs (e.g., id0) are only used to distinguish devices. FIG. 6 is a schematic diagram showing the components of a communication device. 600. Each communication device 600 may include a communication module 602 for wired or wireless communication with other communication devices in the group via one or more servers. The communication module 602 may include, for example, one or more antennas for communication via a core network and a wireless access network in the case of a mobile communication device such as a smartphone. The communication device further includes a user interface 604 for receiving input from the user of the communication device 600 and presenting information to the user. The user interface 604 may include any input / output device through which the user can compose messages to be sent to the group and view messages received from other communication devices in the group. The user interface may include, for example, a touch screen in the case of a smartphone.

[0083] The communication device 600 further includes a processing circuit 606 and a memory circuit 608. The processing circuit 606 may include the following: one or more processing units, such as a central processing unit (CPU), a specialist processing unit, such as a digital signal processor (DSP), a subscriber identity module (SIM), a hardware-integrated trusted execution environment (TEE), and / or one or more application-specific integrated circuits (ASICs) or application-specific standard products (ASSPs). The memory circuit 608 may include the following: volatile random access memory (RAM), particularly static random access memory (SRAM) and dynamic random access memory (DRAM), as well as non-volatile memory and storage devices, such as flash memory, an integrated solid-state drive (SSD), and an embedded hard disk drive (HDD), and / or one or more removable storage devices.

[0084] The memory circuit 608 also stores group state data including cryptographic material representing the current state of the group, and instructions for performing multi-recipient public-key encryption (mPKE) 610. The instructions can implement, for example, the multi-recipient variant of El Gamal's Kurosawa (Kurosawa. 2002. "Multi-recipient Public-Key Encryption with Shortened Ciphertext") by the transformation of Katsumata et al. (Katsumata et al, 2020 "Scalable Ciphertext Compression Techniques for Post-quantum KEMs and their Applications"). Due to its decomposability, the transformation is suitable for selective download. In another embodiment, for post-quantum security, the multi-party public-key encryption may include one of the mPKEs proposed in (Hashimoto et al. 2021. "A Concrete Treatment of Efficient Continuous Group Key Agreement via Multi-Recipient PKEs"). These mPKEs are mPKEs based on Ilum512, Bilbo640, or SIKEp434.

[0085] The memory circuit 608 also holds machine-readable instructions for performing the various functions described in the present disclosure. Code for executing the member authentication protocol 612 of the type described above is stored on the memory circuit 608. Further code for executing the selective download protocol 614 using the pseudo-random permutation using the permutation key permKey of the type described above is also stored on the memory circuit 608.

[0086] Memory circuit 608 may store a signature scheme 610 for performing signature and verification functions. Many different signature schemes can be used. In some embodiments, it may be preferable to select a signature scheme that complements a multi-party public key encryption scheme, either by having similar performance characteristics, being based on similar assumptions, or both. Examples of signature schemes that can be used are as follows.

[0087] -ECDSA standard. It is based on similar assumptions as El Gamal-based mPKE and has a similar performance profile. -NIST PQC finalist Falcon (Thomas Perst et al. 2020. "FALCON"). -NIST PQC finalist Dilithium (Lyubashevsky et al, 2020. "CRYSTALS-DILITHUM"). -SPHINCS + (Hulsing et al. 2020. "SPHINCS+") and Bilbo640 are both based on conservative assumptions (hash-based assumptions and unstructured learning with errors), and both have a higher communication cost than other schemes.

[0088] Note that the metadata hiding continuous group agreement method described above may have two signature steps. The signature is formed using a signature scheme as part of the commit package to enable detection of tampering by the device that downloads it. When using continuous group key agreement that allows selective downloading of commit values, the signature may be presented at c0 to enable the recipient of the commit value to verify the party that sent the commit value. Further, as described above, a second signature created using the group signature key is provided by the communication device when executing the membership authentication protocol. The signature schemes used in these two steps can be selected to be the same or different, depending on the embodiment.

[0089] As described above, when hiding group members who perform selective downloads, a pseudo-random permutation (PRP) can be performed to generate a permuted index for each of the sets of N group members. There are at least two approaches for performing this PRP.

[0090] - Shuffling: A shuffle algorithm can be provided by passing permKey (described below) to a pseudo-random function. A Fisher-Yates shuffle can be used. This can be a suitable choice when there is no concern about a cache attack on the communication device 500. When a cache attack is a concern, a forgetting shuffle algorithm can be used. - Sorting: According to this approach, each member with an ID, id, is assigned a pseudo-random value r id = H(PermKey, id). The pseudo-random values are then sorted according to the value r id . The sort step can be performed obliviously in time O(N log 2 N) using a sorting network. Assuming that the function for generating the pseudo-random value H is collision-resistant (does not generate two identical values), this provides a PRP across the set of N communication devices.

[0091] FIG. 7 is a schematic diagram showing the server 1. Similar to the communication device 600, the server 1 has a communication module 702 that enables communication with the communication device 600 using wired or wireless communication. The server 1 further includes a processing circuit 706 and a memory circuit 708. The processing circuit 706 can include one or more processing units, such as a central processing unit (CPU), a neural processing unit (NPU), a graphics processing unit (GPU), and the like.

[0092] Memory circuit 708 also holds machine-readable instructions for performing the various functions described in this disclosure. For example, the memory may store a proposal database 712 that stores proposals received from communication devices. The memory circuit may store a commit database 714 that stores the current epoch, a group state statement (group verification key), and one or more commits from communication device 600. Each commit closes the epoch and creates a new entry in commit database 712. A welcome database 716 may be provided to store one or more welcome messages for communication device 600 that are added during the commit process.

[0093] Further Details on the Function of Metadata-Hiding Successive Group Key Agreement In the foregoing description, an overview of the metadata-hiding technique for successive group key agreement was shown. To avoid obscuring the overall idea with further details that may vary between embodiments, further details of embodiments of the foregoing method are shown in this section. The following embodiments implement chained mPKE as described in the following literature [Hashimoto et al. 2021. "A Concrete Treatment of Efficient Continuous Group Key Agreement via Multi-Recipient PKEs"]. As described elsewhere in this specification, the metadata-hiding techniques described herein are applicable to other successive group key agreements.

[0094] In some embodiments of the continuous group key agreement, the parties can interact with an authentication service (AS) and a key service (KS). For example, the authentication service can register a new signature key for a party in response to a request from the party's communication device. As a result of this request, the authentication service generates a new key pair for the party and makes the public verification key from the key pair generally available. The new (secret) signature key can be provided to the party's device in response to the request. Thus, the authentication service can verify the ownership of the signature key (by providing the public key of the key pair). The party can register a new signature key pair in response to a request. In this way, the party can determine the public keys of other group members for encrypting content such as commit messages.

[0095] The key service can enable a party to upload a one-time key package to the key service for use when adding that party to the group while the party is offline. The key package can be registered in response to a request using the party's identifier (id), signature verification key (svk), and server signature key (ssk). In response to a request from the party registering the key package, the key package is encrypted by the key service, and the key service also outputs the corresponding decryption key (dk) to the registering party. The parties can also request each other's key packages from the key service. The request includes the id of the party for which the key package is to be obtained, and the key service returns the key package but not the corresponding decryption key.

[0096] Server 1 can maintain a history graph. The history graph is a labeled directed graph that functions as a symbolic representation of the evolution of a group. The history graph identifies proposal nodes identified by the pointer "prop-id" and commit nodes identified by the pointer "node-id". When a group is created, a root commit node called the main root is created by the pointer node-id = 0. Each party is uniquely assigned to a commit node, which indicates that the party is within the group of members who processed the commit assigned to that particular commit node. The label of a node tracks additional relevant information for defining security. A proposal node has a label that stores the proposed action, and a commit node has a label that stores the committed action. A commit node also has a label that stores the group verification key for the epoch.

[0097] All nodes in the history graph store the following values. -orig: The ID of the sender who created the node (i.e., the message sender) -par: The parent commit node representing the sender's current epoch

[0098] A proposal node further stores the following values. -actε ("upd"-svk, "add"-kp t , "rem"-id t}: These values indicate the proposed action. The proposed action "upd" updates the user's signature verification key svk. The proposed action "add" adds a new member to the group with ID, id t and key package kp t . The proposed action "rem" deletes the group member with ID, id t .

[0099] A commit node further stores the following values. -gid: Group identifier -epoch: The current epoch number -prop: Ordered list of committed proposals -mem: List of group member IDs and corresponding signature verification keys (svk) -key: Group secret

[0100] The pointer Ptr[id] is stored in the history graph for each party id. Ptr[id] identifies the current commit node associated with the party id. In other words, Ptr[id] identifies the current epoch of the party. If the party is not in the group (e.g., because it has been deleted), the pointer is set to have the error value Ptr[id] = ⊥.

[0101] Server 1 provides various interfaces to the parties related to the group. Through these interfaces, the parties can create a group, register a proposal, register a commit, and register a welcome message. The parties can also interact with Server 1 to obtain the group secret key. All interfaces except create and join are for group members only (i.e., parties for which Ptr[id] ≠ ⊥). These functions are considered in more detail below.

[0102] Each party to the protocol maintains a group state G. The group state G consists of variables including the group id, group epoch, group membership (G.mem), which is a list of group member identifiers and corresponding signature verification keys, the group signature key (gsk) and group verification key (gvk), a pseudo-random permutation key (permKey) used to reorder the indices of the members as described above, and a list of the indices of the group members related to the use of the permutation key.

[0103] The server maintains the following three databases: a Proposal Database PropDB (for proposals), a Commit Database ComDB (for storing commits and the group verification key gvk), and a Welcome Database WelDB (for welcome messages). The Proposal Database has separate entries for storing the proposals issued for each group in each epoch PropDB[gid,epock]. These proposals, when committed, are used to move any party in the epoch to epoch’ = epoch + 1 (i.e., to the next epoch), and the group state at each party is updated according to the proposal. The Commit Database stores the group verification key (also called the group statement) gvk. The group statement for each epoch is used by the server to verify that a message came from a member of the group. As described above, group members anonymously prove that they are actual group members using the corresponding group signature key gsk. When a commit is stored in an entry in the Commit Database ComDB[gid,epoch] for a particular epoch, no other commit can be stored for this epoch. The Welcome Database stores welcome messages. Each welcome message WelDB[id] can be sent to the group member with ID, id.

[0104] Depending on the status of the group, the Commit Database can take one of the following five values. -ComDB[gid,epoch]=⊥ This indicates that the epoch has not yet been initialized. -ComDB[gid,epoch]=(T,node-id) This indicates that the epoch has been initialized by the party located at the commit node identified by node-id in the history graph, and no commit has been issued for the epoch. -ComDB[gid,epoch]=((c0,

Number

Number

[0105] Key Chain (Commit) Multiple - Recipient Public - Key Encryption uses several keys and secrets shown in Figure 8. Towards the bottom of the figure, a set of nodes is shown. The root node is shown by vertical hashing. This root node corresponds to the commit secret comSecret. To the left and below the root node, a node representing the communication device that sent the commit ending the previous epoch is shown. This node (representing a group member) generated the commit secret. The other nodes shown within the group can receive the commit secret as part of the commit downloaded from Server 1 encrypted with the public key of each respective node. Thus, each of one or more downloading communication devices within the group can determine the group secret comSecret for the new epoch based on the downloaded commit, enabling one or more downloading communication devices and the committing communication device within the group to generate a common secret key for the epoch.

[0106] Each epoch has a set of keys as follows. - joinerSecret is the secret sent to the communication device joining the group. - appSecret is used to obtain the shared key of the epoch. Submitting appSecret to the server using the key function returns k, which is the shared key of the epoch. - confKey is used to verify the message access code associated with the commit and welcome packet. -membKey is used to verify the message access code associated with the proposed packet. -encSecret is used to encrypt the proposed and commit messages. -metaKey is used to hide the dynamic metadata as described above. -initSecret is the initial secret for the next epoch.

[0107] Each communication device executes a procedure to generate a group secret (joinerSecret), enabling two or more communication devices within the group to generate a common secret key (appSecret or the shared key k of the epoch). joinerSecret is included in the welcome message and signed by the public key of the participating party. Thus, a newly participating party can obtain joinerSecret and derive the other keys necessary to join the group in the current epoch. For other group members not participating in the group in this epoch, joinerSecret can be derived using the key derivation function from the initSecret of the previous epoch and the comSecret from the commit downloaded from the server. Thus, each existing member of the group can access their respective previous initSecret and also derive joinerSecret from comSecret.

[0108] appSecret is derived from joinerSecret using the key derivation function and the tag "app". appSecret is used with the key function at Server 1 to obtain the secret key k of the epoch. The secret key k of the epoch is used as the source key for a symmetric encryption scheme for exchanging messages between devices or in any other application among the parties within the group that requires a common secret key.

[0109] The confKey is derived from the joinerSecret using a key derivation function and the tag "conf". The confKey is used for message authentication codes (MACs) for commit messages and welcome messages. When using a MAC, a signature algorithm is used to sign the commit message or welcome message and generate a tag. The verification algorithm in the communication device that receives the commit message or welcome message can verify the authenticity of the message by considering the confKey and tag that the receiving communication device can also derive. That is, the receiving communication device can determine that the message and tag have not been tampered with or forged. If it is determined that the commit message or welcome message has been tampered with or forged, the receiving communication device rejects the message.

[0110] The membKey is derived from the joinerSecret using a key derivation function and the tag "memb". The membKey is used in the same way as the confKey. However, the MAC is used for proposal messages instead of commit messages and welcome messages.

[0111] The encSecret is derived from the joinerSecret using a key derivation function and the tag "enc". As described above, this key is used to encrypt and decrypt proposal messages and commit messages.

[0112] The metaKey is derived from the joinerSecret using a key derivation function and the tag "meta". The metaKey is used to derive a key mh which is then used in the key derivation function to generate the group signature key gsk and the group verification key gvk (used in the member authentication protocol). Also the value key mhIt is used to derive the aforementioned permKey, reorder the index values, and disguise the access by the communication device when downloading the commit. By using the key derived from the group secret joinerSecret, metaKey, for authentication, anonymous authentication on the server according to the embodiments of the present invention becomes possible.

[0113] initSecret is derived from joinerSecret using a key derivation function and the tag "init". As described above, initSecret is used to derive joinerSecret from ComSecret when changing between epochs.

[0114] The key derivation function used may vary depending on the embodiment. In some embodiments, the key derivation function may be a key derivation function based on HMAC.

[0115] Creation and registration of the group According to the above description, the party having the ID, id creator can create a group using the creation function (Create, svk). The main group initially has one party id creator As described in relation to Figure 3b, that party id creator can add additional members by issuing a proposal and committing to them. Then, the group creator can execute the helper function *init-states to initialize the group state. The *init-states function initializes values such as the group id gid←{0,1} k , and the epoch epoch←0.

[0116] *init-states can also generate metaKey using the group secret (joinerSecret), and generate the group reordering key permKey and the authentication key authKey. Then, id creatorregisters the group with the server. The group creator sends the group ID (gid), epoch counter (epoch), and group verification key (gvk) of the new group to Server 1 via the client anonymous authentication channel. When receiving the group creation message, the server checks that the gid, which is the group id, is not already registered. If the group has already been created, the process is interrupted and the message accept=false is returned. If the group does not yet exist, the server initializes the group by setting the epoch to zero and returns accept=true to the party. The server stores (gvk, ┴, ┴) as an entry in the commit database for epoch=0, comDB[gid,0], as shown in Figure 3a. Finally, the group creator checks the result of the protocol. If the creation of the group fails, the group creator rolls back all state changes at the group creator communication device and outputs ┴ indicating failure.

[0117] As described above, according to the continuous group key agreement, a party accesses the server via a communication device that communicates with the server via the client anonymous authentication channel. Therefore, the server does not output the ID of the accessing party.

[0118] Creation and Publication of Proposals A party with a group state having a group identifier and epoch values (gid, epoch) can create a proposal message P by calling the propose function (Propose, act). The proposing party and Server 1 execute a challenge-response type membership authentication protocol, whereby the party can anonymously prove valid group membership for (gid, epoch). More specifically, according to the above description, when receiving the proposal message, the server selects a random challenge message that is a binary value of k bits in length (ch←{0,1} k) Send it to the proposing party. The proposing party then signs the challenge with its group signature key gsk and sends the signature σ along with the information identifying the group (gid, epoch) and the proposal P. The proposal P, as described above, has the content (Propose, act) and enables adding a party to the group, removing a party from the group, or updating the key material of a party. The proposal is encrypted using the key encSecret. The server checks the entry in the commit database to confirm that ComDB[gid, epoch] = (gvk, ┴, ┴) and checks that the signature σ is valid with respect to gvk. If the check passes, the server stores the proposal P in the entry in the proposal database PropDB[gid, epoch]. The server rejects the proposal if the entry in the commit database ComDB[gid, epoch] contains a commit. This is because it indicates that a new epoch has already been created and no further proposals for that epoch can be received.

[0119] Creation and Publication of Commit and Welcome Messages First, to execute a commit, the committing party requests the download of a list of proposals created in relation to the group state with the value (gid, epoch) by one or more group members who submitted proposals as described above. The proposal request is satisfied by a challenge from the server using the membership authentication protocol in the same way as described in relation to the publication of proposals above. When the server verifies the signature σ of the random challenge message, the server sends the list of proposals stored in the proposal database PropDB[gid, epoch] related to the current epoch.

Number

[0120] The committing party has a vector of proposals

Number

Number

Number

Number

Number

Number

Number

Number

Number

Number

[0121] The second upload by the communicating device to commit is to publish a welcome message. The committer accesses the server via the client anonymization channel and uploads (id t ,

Number

Number

[0122] Processing of commit messages Members of the group gid whose communication protocol has not yet been updated to the next / latest epoch can process the commits associated with the next epoch for the current epoch of the member. This process is repeated until the group member reaches the commits associated with the epoch immediately preceding the current epoch of the group and the commits associated with the proposals, whereby the member can update its group state to the state of the current epoch. The parties and the server first execute the membership authentication protocol to show that the party is a member of the group. Along with the signature of the challenge value, the party sends an epoch-dependent permuted index derived using the permKey described above. As described above, since the index for each party is different for each epoch, the indexes between epochs cannot be linked. If the signature is a valid signature with respect to the group signature key, the server stores the proposals stored in the proposal database propDB[gid,epoch] [Number] , the party-independent commit c0, and the received index [Number] = [Number] returns a list of party-dependent commits for the party based on [index].

[0123] Following the receipt of the proposals and the list of commit values, the parties process them and update their internal state based on the commit secret comSecret included in the commit values.

[0124] Joining a Group A party can join a group by downloading a welcome message. The party that joins accesses the server using an authentication channel. In this case, the party discloses its ID to the server. The server uses the party's ID to find the relevant welcome message to provide to the joining party. The server returns either the welcome message associated with the party's id [Number] or indicates that there is no welcome message.

[0125] When a party receives a welcome message, the welcome message is processed and the joining party can obtain the joinerSecret included in the welcome message. The joining party can then derive the other keys necessary to join the group.

[0126] Note that the welcome message leaks the recipient's ID, the hash of the key package, and the group size. The recipient's ID is in plain text so that the server can distribute the welcome message. The recipient uses the key package hash to determine the decryption key for processing the welcome message.

[0127] Routines for Achieving the Above Functions Figures 9 to 15 show routines for achieving the above functions. One or more of these routines can be optionally used to implement the above-described embodiments. For each figure, a brief description is given below so that the relationship to the above-described method can be understood.

[0128] Figure 9 shows the RegisterGroup routine for registering a new group and initializing the group state for the current epoch. Message exchange includes the party id communicating via the client anonymization authentication channel and the server Sv.

[0129] The party id sends a RegisterGroup request containing the group id, gid, and the group verification key gvk to the server Sv via the client anonymization channel. The server checks the status of the commit database to see if a group with the id and gid exists. If the group does not yet exist, it creates an entry with the group id, gid, and the group verification key gvk in the commit database.

[0130] If the group registration is successful, the server Sv returns accept=true; otherwise, it returns accept=false.

[0131] Figure 10 shows the PublishProposal routine. As shown in Figure 10, the party id sends a PublishProposal request to the server Sv. The communication channel is also client anonymous in this case, and the message is addressed to the server Sv.

[0132] In response to the PublishProposal request, the server returns a challenge value ch, which is a binary string of length k bits.

[0133] Based on the group state stored at the party id, the party obtains the group id, gid, and the epoch associated with that group. The party id signs the challenge value under the group signature key gsk to generate a signed challenge value. Then, the party id sends the signature, group id, epoch, and the proposal p to the server.

[0134] The server checks the group id and the epoch to determine whether the database entry for that group is still open (i.e., not committed) in the commit database. The server then checks the received signature using the signature verification key gvk stored in the commit database. Assuming this check passes, the proposal p is stored in the proposal database.

[0135] If the proposal is accepted and stored, the server returns "accept" = true. Otherwise, the server returns "accept" = false.

[0136] Figure 11 shows the routine related to the FetchProposals request. In this routine, the party id sends the FetchProposals request to the server Sv. As before, the channel is anonymous ("anon") and the message is addressed to the server Sv.

[0137] The server returns a challenge value ch which is a binary string of length k bits. The party id signs the challenge value under the group signature key gsk to generate a signed challenge value. The party responds to the challenge by sending the signature, the group id, and the epoch.

[0138] Upon receiving the signature, the group id, and the epoch, the server checks that the epoch is still open (i.e., not committed) in the commit database. The server then checks the signature using the signature verification key gvk stored in the commit database. If the check passes, the server returns the stored proposal vector associated with the group id and the current epoch, and "accept value" = true. Otherwise, the server returns "accept" = false.

[0139] Figure 12 shows a routine for publishing a commit message. As shown in Figure 12, the party id sends a PublishCommit request to server Sv. As described above, the channel is anonymous ("anon") and the message is addressed to server Sv.

[0140] In response to the PublishCommit request, the server returns a challenge value ch, which is a binary string of length k bits. Based on the group state stored at the party id, the party obtains the group id, gid, and the value of the epoch. The party id signs the challenge value under the group signature key gsk to generate a signed challenge value.

[0141] The party id generates the group state statement for the next epoch as follows. i) Generate a metadata hiding key kmh' for the next epoch. ii) Use a pseudorandom function (PRF), the metadata hiding key, and the tag "auth" to generate an authentication key (authkey') for the next epoch. iii) Use a key generation function with the input authkey' to generate a group signature and group verification key pair for the next epoch.

[0142] In response to the challenge, the party id sends a vector of the signature, group id, epoch, group verification key for the next epoch, member-independent commit, and member-dependent commit values to the server.

[0143] The server checks that the epoch for its group id is still open (i.e., not committed) in the commit database. Then, it checks the signature using the signature verification key gvk. Assuming the checks pass, the server updates the commit database with the member-independent commit value and the member-dependent commit value. The server creates a new entry in ComDB for the new epoch.

[0144] If the commit is successful, the server returns "accept" = true. Otherwise, the server returns "accept" = false.

[0145] Figure 13 shows a routine for fetching a commit message from the server. The party id sends a FetchCommit request to the server. As described above, the channel is anonymous ("anon") and the message is addressed to server Sv.

[0146] The server returns a challenge value ch which is a binary string of length k bits. The party id signs the challenge value under the group signature key gsk to generate a signed challenge value. The party responds to the challenge by sending a signature, group id, epoch, and the value "index". The value "index" is created using the metadata hiding key (k mh ) described above. The permutation key is generated using the pseudorandom function k mh and the tag "perm" (permKey ← PRF(k mh , "perm")). The index is generated using the pseudorandom function, permKey, and the party's IDi (index = PRP(permKey, i)).

[0147] The server checks if the epoch has been committed by checking the status of the group in the commit database. The signature is then checked using the signature verification key gvk. Assuming the check passes, the server returns the stored proposal vector associated with the group id and the acceptance value. The server also returns the member-independent commit and member-dependent commit corresponding to the received index.

[0148] Figure 14 shows a routine for publishing a welcome message. As shown in Figure 14, the party id sends a PublishWelcome request to server Sv. The channel is anonymous ("anon") and the message is addressed to server Sv. The request for publication by the party id includes the party identifier idt of the receiving party and the welcome message to be published.

[0149] The server stores the welcome message in the welcome database in relation to the identifier idt. The server returns the value "accept". Figure 15 shows a routine for fetching a welcome message. The party id sends a FetchWelcome request to server Sv. In this routine, the communication channel is not client - anonymous and the message is addressed to server Sv. The request by the party id includes the party identifier id.

[0150] The server searches for the welcome message stored in the welcome database in relation to the party identifier id. If the message is not found, the server returns "accept" = false. If the welcome message is found, the server returns "accept" = true and the retrieved welcome message.

[0151] Alternative embodiments The foregoing embodiments should be understood as exemplary examples of the present invention. Further embodiments of the present invention are conceivable.

[0152] In the foregoing example, when a commit is executed, a two-step process is carried out. The communication device fetches a proposal from the server (this requires the completion of the membership authentication protocol, i.e., the first challenge value is sent by the server and the signature of the first challenge value is returned by the communication device), and publishes the commit (this requires the completion of the second step of the membership authentication protocol, i.e., the reception of the second challenge value and the signature of the second challenge value). In a variation, the fetching of the proposal and the publishing of the commit can be carried out based on a single membership authentication protocol by using the first challenge value and the signature for both the fetching of the proposal and the publishing of the commit.

[0153] In the foregoing embodiments, the publication of the proposal and the commit message is conditional on the group member passing the member authentication protocol. As described above, this includes the server sending a challenge value and the group member signing the challenge value with the group signature key gsk. This procedure can be made non-interactive (i.e., the separate step of the server sending the challenge value can be omitted) by the group member signing a message to the server or a value derived from the message (e.g., a hash). For example, in the case of a proposal request, the group member can sign the group identifier, the epoch value, and the proposal content (gid, epoch, P). The server can check the received signed message against the message content. Similarly, in the case of a commit, the group member can sign the group identifier, the epoch value, and the commit (gid, epoch, c0,

Number

[0154] The above-described changes to make commit and proposal messages non-interactive do not function for messages from parties that request a list of proposals or request a download of a commit. The reason is that these messages do not have message content suitable for signing. However, content suitable for signing can be derived and included in the message. For example, the output of a pseudo-random number generator can be recorded and signed as additional message content in the above-described request message, and the server can verify the signature and verify that the group member owns the group signature key. The server can be modified to store a list of challenge values used in a given epoch and prevent receiving previously used non-interactive signed challenge values to prevent replay attacks.

[0155] In the above-described embodiments, the group authentication protocol uses a signature on a challenge value from a communication device generated using a group signature key (private key). The signature is verified by the server using a group verification key (public key). In other embodiments, this mechanism can be replaced by a message authentication code (MAC). As will be appreciated by those skilled in the art, the MAC uses only the private key. Thus, in such embodiments, a single secret MAC key is generated from the aforementioned metaKey and provided to the server with each commit message instead of the group verification key gvk'. During the membership authentication protocol, a tag for the challenge value is generated at the communication device using the MAC key, and the tag is added to the relevant message instead of the signature of the challenge value. The tag can then be verified in the normal manner using the same MAC key provided to the server.

[0156] The advantages of using MAC as described in the previous paragraph are generally that it is faster and the tag is usually more compact than a signature. However, as a trade-off, the security guarantee may be weakened. For example, if the MAC key leaks from the server, an adversary who owns the MAC key can insert garbage messages because they can pass the group member authentication protocol, which, of course, is not possible with the secret / public key pair described in the embodiments.

[0157] The method described above has been explained focusing on unchained mKEM as continuous group key agreement (Hashimoto et al, 2021, "A concrete treatment of efficient continuous group key agreement via multi-recipient PKEs"). In other embodiments, TreeKEM (Barnes et al, 2022, "The Messaging Layer Security (MLS) Protocol", in progress at IETF) can be used instead of unchained mKEM. In some continuous group key agreements, the server preprocesses the commit message before sending it to the user, such as SAIK (Alwen et al, 2021, "Server-Aided Continuous Group Key Agreement") and CoCoA (Alwen et al, 2022, "CoCoA: Concurrent Continuous Group Key Agreement"). The inventors expect that it is possible to apply the above-described concept to these continuous group key agreements using the above-described concept, but modifications are made to consider the necessary processing on the server.

[0158] Any feature described in connection with any one embodiment may be used alone or in combination with any other feature described, and may also be used in combination with one or more features of any other embodiment, or any combination of any other embodiments. Further, equivalents and modifications not described above may also be used without departing from the scope of the invention as defined in the appended claims.

Claims

1. A method for hiding the IDs of two or more communication devices within a group that communicates using a continuous group key agreement, wherein the two or more communication devices can communicate with each other within the group via a server, and the protocol of the continuous group key agreement is generating, by one or more of the communication devices of the group, one or more proposals for updating the group state and storing the one or more proposals on the server; committing, by the committing communication device of the group, zero or more functions of the one or more proposals stored on the server, wherein the committing communication device updates the group state stored in the committing communication device based on the committed functions of the zero or more proposals, and as a result of committing the functions of the zero or more proposals, a commit regarding the functions of the zero or more proposals is stored on the server, and by committing the functions of the zero or more proposals, a new epoch for the group is started, the committing; downloading, by one or more downloading communication devices that are members of the group other than the committing communication device, the commit and updating the group state in each of the one or more downloading communication devices based on the commit; determining, by each of the one or more downloading communication devices, a group secret for the new epoch based on the downloaded commit and enabling the one or more downloading communication devices and the committing communication device within the group to generate a common secret key for the epoch, including; the method for hiding the IDs of the two or more communication devices is the requesting communication device transmitting a signed challenge value to the server in relation to a request for an operation, wherein the signed challenge value is generated by signing a challenge value with a group signature key, and the requested operation includes one of storing one or more proposals on the server, storing a commit regarding the functions of zero or more proposals on the server, and downloading the commit, the transmitting. The server checks the signed challenge value using the group verification key stored in the server and the challenge value. If the signed challenge value indicates that the requesting communication device owns the group signature key, the server executes the requested operation. If the signed challenge value does not confirm that the requesting communication device owns the group signature key, the server does not execute the requested operation. The method includes the above. **Claim 2** The requesting communication device sends a request for the operation to the server. In response to the request, the server sends a challenge value to the communication device. The requesting communication device receives the challenge value and signs the challenge value using the group signature key for its epoch to generate a signed challenge value. The method according to claim 1. **Claim 3** The challenge value is derived from at least one of the content of the proposal message sent to the server, the content of the commit message sent to the server, randomness, and other predetermined data. The method according to claim 1. **Claim 4** The group signature key and the group verification key are derived from the group secret for the current epoch of the group. The method according to any one of claims 1 to 3. **Claim 5** The commit includes a member-independent commit part and a plurality of member-dependent commit parts associated with each member of the group. By one or more downloading communication devices that are members of the group other than the committing communication device, the step of downloading the commit includes each downloading communication device downloading a package including the member-independent commit part and the member-dependent commit part associated with the downloading communication device. The method according to any one of claims 1 to 4. **Claim 6** Each of the member-dependent commit portions has a respective position associated with an index, or an index associated with different group members, and each communicating device to download uses the corresponding index associated with the group member to download the corresponding member-dependent commit portion, and the index is pseudo-randomly shuffled based on a shuffling key in each epoch to prevent tracking of the ID of the communicating device that downloads the member-dependent commit portion, the method according to claim 5.

7. The index is pseudo-randomly shuffled using a shuffling algorithm that takes the shuffling key as an input, the method according to claim 6.

8. A random value is assigned to each index using a pseudo-random number generator that takes the shuffling key as an input, and then the index is sorted, the method according to claim 6.

9. The shuffling key is derived from the group secret, the method according to claims 7 and 8.

10. The communicating device communicates with the server by establishing respective client anonymized communication channels, the method according to any one of claims 1 to 9.

11. Downloading the commit by one or more communicating devices that are members of the group other than the communicating device that commits includes downloading the functions of zero or more proposals associated with the commit from the server, the method according to any one of claims 1 to 10.

12. The group signature key and the group verification key are a private / public key pair in a public key signature scheme, the method according to any one of claims 1 to 11.

13. The group signature key and the group verification key are the same key, and the signature is a message authentication code, the method according to any one of claims 1 to 11.

14. A communicating device for use in a method for hiding the IDs of two or more communicating devices within a group that communicates using continuous group key agreement, wherein the two or more communicating devices are They can communicate with each other within the group via a server, the communication device is configured to execute a continuous group key agreement protocol, and the continuous group key agreement protocol generates one or more proposals for updating the group state and stores the one or more proposals on the server; committing zero or more functions of the one or more proposals stored on the server, where committing zero or more functions of the proposals updates the group state stored in the communication device based on the committed functions of the zero or more proposals, and as a result of committing zero or more functions of the proposals, sending a commit regarding the functions of the zero or more proposals to the server for storage, and by committing zero or more functions of the proposals, a new epoch for the group is started, the committing; downloading a commit and updating the group state based on the commit; determining a group secret for the new epoch based on the downloaded commit and enabling the communication device to generate a common secret key for the epoch. The communication device is further configured to execute a method for hiding the IDs of the two or more communication devices, and the method sends a signed challenge value to the server in relation to a request for an operation, the signed challenge value being generated by signing a challenge value with a group signature key, and the requested operation includes one of storing one or more proposals on the server, storing a commit regarding the functions of zero or more proposals on the server, and downloading the commit, whereby the server can check the signed challenge value using a group verification key stored on the server and the challenge value, and if the signed challenge value indicates that the communication device owns the group signature key, the server can execute the requested operation, and if the signed challenge value does not confirm that the communication device owns the group signature key, the server does not execute the requested operation, the communication device. **Claim 15** One or more computer programs which, when executed by two or more communication devices and a server configured such that the two or more communication devices communicate with each other within a group via the server, cause the communication devices and the server to execute the method according to any one of claims 1 to 13.

Images